How can I configure a DHCP server to assign addresses based on the OS that is running Solved maybe!

[Simon Hobson]

Marc Chamberlin wrote:

>Thanks everyone for all your help, it gave me a lot to explore and 
>was a big help. I have spent quite a few days on this, and though I 
>hate throwing stones at a project, with as much invested in it as 
>this one apparently has, and been around as long as it has, I am 
>quite surprised at how difficult it is/was to work with and 
>configure this server. I think a redesign, with particular attention 
>paid to the model and configuration language should be seriously 
>considered, but that is just IMHO.... Also, a number of (ok maybe I 
>should say possible) bugs have surfaced during the course of my 
>investigations, which made it far more difficult to find a solution, 
>than it should have been. I will go through these and then present 
>what I think is a solution and ask for opinions, since much of the 
>underlying model is undocumented, (as far as I could find) in 
>particular the precedence that is used by the server as it builds 
>it's database and decision tree for IP address assignments.

To a certain extent you are right, but you have to remember that 
there is a certain amount of "we wouldn't start from here" ! The 
latest versions have a new feature that may be useful (reserved 
leases), and there is another feature on the wish list (redefine the 
primary key) that is as yet unimplemented but would solve (or at 
least help) quite a few usage cases like yours.

Bear in mind that AFAIK, the ISC server is waaaay more adaptable than 
most. And you are in fact asking for functionality that it wasn't 
designed to do (and is arguably not in accordance with the 
standards). You may have found it difficult, but you achieved it - no 
other server that I have any experience with would do anything even 
remotely close. Back when this server was started, people were still 
using BOOTP and reverse ARP to configure clients - DHCP was a real 
leap forward !

Without looking, I can't say how far back the project goes, but I can 
recall starting with version 3 when it was in a late RC version and 
that was over a decade ago ! Previous versions go a lot further back 
than that. Back when I started with it, I don't think we had **ANY** 
wireless devices in the company.
As an aside, I was coming to the ISC server as I wasn't happy with 
the way the SCO Openserver one worked (or in my case didn't) - it was 
a lot harder to set up, and lacked virtually every tool you've used 
in your setup. It also had a *serious* bug that AFAIK they never 
fixed.

>2. The hardware "object" while it may be convenient in some cases, I 
>submit it is confusing and difficult to work with. The underlying 
>data structure for this object is actually two fields, a hardware 
>type identifier and a numeric encoded mac address. I don't 
>understand the need to bond the hardware type with the mac address 
>so tightly, and not provide any easier objects for users to work 
>with and manipulate instead. It took me quite awhile to figure out 
>how to use this object effectively, given my  goal of using the mac 
>address of the client's interface in conditional expressions! See 
>below..

I'm not with you here. What is hard about "hardware ethernet 
aa:bb:c:d:ee:ff ;" ? You don't need all those binary-to-ascii and 
substring constructs you are using (I think). While you may think 
it's complicated to have a hardware type element, it is required as 
different hardware types have different identification constructs - 
and there was no way of knowing what new types may come along in the 
future.

>5. In order to handle clients with more than one interface, and 
>allow clients to dynamically switch between different interfaces, I 
>included the following two statements in my dhcpd.conf file -
>
>deny duplicates;
>ping-check on;
>
>My goal was to force a static IP address assignment to a particular 
>client,  by using the class and pool declarations shown below, in 
>conjunction with these declarations. I noted instead, that if a 
>client booted up and initialized one of two interfaces (wired or 
>wireless) then switched interfaces (disabling the first initialized 
>interface in the process) that the dhcp server was unable to 
>transfer the IP address assigned to the first interface to the 
>second one based on a simple DHCPREQUEST. Instead the transfer only 
>occurred if the client reinitialize his interface and forcing a 
>DHCPDISCOVER instead.
>
>Perhaps this is correct dhcp behavior, but I would think that doing 
>a ping check and discovering that the client is no longer responding 
>to it, would have been sufficient to prevent the user unfriendly 
>requirement of having to reinitialize an interface just because it 
>was hot-plugged and/or the user turned the other off. So I am 
>confused!

Again, you are hitting a situation that was never envisaged when the 
DHCP standards were written. The "problem" is that the way you want 
it to work is explicitly not in accordance with the standards. It is 
a known problem, that's why the deny-duplicates was introduced to try 
and mitigate it to a certain extent. Ping-check has nothing 
whatsoever to do with what you are trying to achieve, and is in fact 
merely a "safety net" to try and avoid problems from some common 
network misconfigurations.

>---
>
>That said, I set up a test network of a variety of clients, and 
>after lots of experimentation I arrived at the following 
>configuration segment, using classes and pools, to assign static IP 
>addresses to clients based on their operating system and interfaces. 
>This has the advantage of showing up in the logs, and if I am 
>correct, gets around the limitations of using host declarations to 
>assign static IP addresses. I won't show my entire dhcpd.conf file 
>as most of it is pretty standard stuff, except for the two 
>declarations I mentioned above. Sorry this is a bit long still, but 
>I limited my test to just 5 systems on a small network.....
>
>class "marcslaptop_Vista_Class" {
>    match if ((substring(option vendor-class-identifier, 0, 4) = "MSFT") and
>             ((ucase(binary-to-ascii(16, 8, ":", substring (hardware, 
>1, 6))) = ucase("0:1a:73:55:7d:f")) or
>              (ucase(binary-to-ascii(16, 8, ":", substring (hardware, 
>1, 6))) = ucase("0:16:36:c2:65:a4"))));
>    log (info, "marcslaptop_Vista_Class matched");
>}

I think
class "marcslaptop_Vista_Class" {
    match if ((substring(option vendor-class-identifier, 0, 4) = "MSFT") and
             (hardware=1:0:1a:73:55:7d:f or
              hardware=1:0:16:36:c2:65:a4));
would work.

>subnet 192.168.2.0 netmask 255.255.255.0 {
>   default-lease-time 14400;
>   max-lease-time 172800;
>   pool {allow members of "marcslaptop_Linux_Class"; range  192.168.2.10;}
>   pool {allow members of "marcslaptop_Vista_Class"; range  192.168.2.15;}
>   pool {allow members of "nova_Linux_Class"; range  192.168.2.20;}
>   pool {allow members of "nova_XP_Class"; range  192.168.2.25;}
>   pool {allow members of "darkstar_2000_Class"; range  192.168.2.35;}
>   pool {allow members of "stephslaptop_Vista_Class"; range  192.168.2.45;}
>   pool {allow members of "teraserver_Class"; range  192.168.2.50;}
>   pool {
>         deny members of "marcslaptop_Linux_Class";
>         deny members of "marcslaptop_Vista_Class";
>         deny members of "nova_Linux_Class";
>         deny members of "nova_XP_Class";
>         deny members of "darkstar_2000_Class";
>         deny members of "stephslaptop_Vista_Class";
>         deny members of "teraserver_Class";
>         deny known-clients;
>         allow all clients;
>         range 192.168.2.101 192.168.2.199;}
>}
>
>There are a few things of note in the pool declaration for the final 
>pool segment that assigns IP addresses to unknown clients.
>
>1. I added the deny members of "class" statements to prevent an IP 
>address assignment to a client which activates a second interface. 
>This requirement surprised me, but it seems to work.

Why surprised ? Unless you specify that a client should not be 
allowed to use a pool, then it can use a pool. It is deliberate that 
allowing it in one pool doesn't exclude it from others as that would 
create just as many complaints.

>3. The allow all clients statement is a guess on my part, as nothing 
>is said about precedence of configuration statements in the 
>documentation. But my guess is that this will allow assignment of an 
>IP address to all unknown clients without my having to specify all 
>clients on my network with host statements. If this won't work, and 
>I have to use the allow unknown clients statement instead, then I 
>would be right back to where I started from, having to specify hosts 
>declarations, which I am trying to get around due to their 
>inadequate capabilities. I have not yet fully tested this to my 
>satisfaction, but initial trials seem to indicate it works....

That is an area that could do with improvement, and it comes up 
fairly frequently. Mixing allow and deny is generally advised against 
as it does NOT give the results most people expect - specifically the 
allow and deny statements are NOT processed linearly.

-- 
Simon Hobson

Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed
author Gladys Hobson. Novels - poetry - short stories - ideal as
Christmas stocking fillers. Some available as e-books.