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

[Glenn Satchell]

Perhaps forcing the client to release the IP when shutting down might 
work for you? I am not sure wha happens if you suspend, or just pickup 
the laptop and move it while running.

There are options that you can set for the Microsoft DHCP client to do 
release on shutdown.

#
#  Config the MS specific extensions, see:
#  Microsoft Knowledge Base Article #313314
#  it's not 8 bit ints, it's 32.
#
option space windows;
option windows.release code 2 = unsigned integer 32;
#
if substring (option vendor-class-identifier, 0, 4) = "MSFT" {
          # 1 = send DHCPRELEASE on shutdown
          option windows.release 1;
          vendor-option-space windows;
}

For Linux systems you could set up a K-script to run dhclient -r when 
the system is shutdown, eg something like /etc/rc0.d/K20dhclient. Your 
current script could be modified to do this. It's not as nice as a dhcp 
server setting, but I don't know of any other way,


A few other minor notes about your posted dhcpd.conf:

This will never match, the substring is 11 chars long, but you're 
testing for equality with a 16 char string. Cut and paste error in the 
email perhaps? The 11 should be replaced by the length of the string, 16 
in this example.

   substring(option dhcp-client-identifier,1,11) = "marcslaptopLinux"

And this might be a little pedantic, but you can re-write this:

   (ucase(binary-to-ascii(16, 8, ":", substring (hardware, 1, 6))) = 
ucase("0:1a:73:55:7d:f")

in a much simpler form:

   ((substring (hardware, 1, 6)) = 0:1a:73:55:7d:f )

Admittedly, with the processing capability of today's CPUs it probably 
won't make that much difference.

You can directly compare with a hex digit string. See this section of 
the dhcp-eval man page:

$ man dhcp-eval
...
      colon-separated hexadecimal list

        A list of hexadecimal octet values, separated  by  colons,
        may be specified as a data expression.

regards,
-glenn

On 01/16/11 08:51, Marc Chamberlin wrote:
> Hello - I am going to pick up on a thread that I started last summer so
> as to give anyone who wants the context an opportunity to review and
> refresh themselves on the issues I am facing. Basically, I am trying to
> support dual and triple boot laptops with multiple OS's and multiple
> network interface capabilities (wireless v.s. wired), and I need to be
> able to assign these laptops a fixed IP address that is based on the OS
> that is currently running on them, regardless of what network interface
> is being used by the laptop. (the purpose behind this is so that our
> backup server can identify how to back up a laptop and reach that laptop
> via a known IP address) After a lot of discussion on this mail list, we
> reached a possible working solution and I will recap it (reshow what I
> summarized previously) below to show how the dhcpd.conf file was
> configured to manage one of these laptops (mine).
>
> OK now for the problem, which was an unforeseen wrinkle, but users being
> users will discover em, and of course complain... If a user switches the
> network interface from one to another, while remaining with the same OS,
> then the dhcpd server will refuse to assign (actually reassign) the
> appropriate IP address to that laptop. (This happens a lot when a user
> takes his/her laptop to another building, out of range of our wireless
> AP) Since the dhcpd server thinks that the IP address for that laptop as
> already been assigned, to the wireless interface, and the user is now
> trying reboot and get an IP address assign via the wired interface,
> (which we want to be the SAME IP address) the dhcpd server fails to
> reassign the IP address until it's old lease expires.
>
> So, anyone got any ideas on how to solve this new wrinkle? Thanks in
> advance for any and all offers of help, much appreciated?
>
> Marc Chamberlin...
>
>
> ---
>>
>> 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");
>> }
>>
>> class "marcslaptop_Linux_Class" {
>> match if ((substring(option dhcp-client-identifier,1,11) =
>> "marcslaptopLinux") 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_Linux_Class matched");
>> }
>>
>> 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 {
>>     deny members of "marcslaptop_Linux_Class";
>>     deny members of "marcslaptop_Vista_Class";
>>     deny known-clients;
>>     allow all clients;
>>     range 192.168.2.101 192.168.2.199;}
>> }
>>