My notebook’s DHCP setup seems to be a challenge for DHCP servers around the world. Looks like almost no server
implements the standard in a decently complete way.
My notebook has a wired Fast Ethernet, and a wireless 802.11bg network interface. Of course, both interfaces have their
own MAC address. I want the thing to work at least at home, regardless of whether wired or wireless is in use, with
preferably the same static IP address, and on the office wired network, again, with the static IP address allocated to
me there.
Configuring this is considerably harder than I expected.
At home, I am using a Linksys WRT54G router with OpenWRT, which has dnsmasq as DHCP server. Unfortunately, dnsmasq does
not support the case where multiple MAC addresses are statically assigned to the same IP address: Only the first
dhcp-host statement in the configuration file is honored, all others are ignored.
So we need to resort to using a dhcp client-identifier. In DHCP request option number 61, the client can send an
identifier, which the Server can then use to determine the client’s identity and assign a static IP address. The
client identifier, according to
RFC2132, is to be treated as an
opaque string by the DHCP server.
This works fine with dnsmasq, solving the issue at home. But it causes more grief in the office network.
My office is the kind of place where a non-Microsoft solution is rarely considered. Thus, our network is fully buzzword
compliant and the network infrastructure, including DNS and DHCP servers, is based on Windows Server System. I am the
only one using a non-MS operating system in my work environment. When I plugged my notebook into the network this
morning, I noticed that I didn’t receive my static IP address but a different one from the dynamic pool.
After verifying that the Windows guys didn’t touch the DHCP server in the last days, I began to think what I
changed locally and naturally remembered configuring the DHCP client identifier. Removed it for testing, got my normal
static IP address, so the client identifier was quickly pinned down as the culprit.
After my Windows colleagues decided that it must be a client issue, I began investigating how to configure the Windows
DHCP server to honor a client identifier.
MS Knowledge Base
article #172408, “Custom DHCP Client Identifiers for Windows NT”, is a high hit on Google, but is like
three years old and shows that somebody at MS has badly misunderstood the DHCP standard - they think that the Client
Identifier is a 4 byte number in little endian order.
I couldn’t believe that and investigated further. But it looks like the Windows DHCP server really cannot handle
free-form client identifiers at all. I tried coding my free-form identifier in ASCII and entering it as MAC address,
big endian, little endian, to no avail. So, I have come to the conclusion that MS has - again - only partly
implemented a very important protocol for their network software. “Embrace and extend”, my
<censored>, DHCP wasn’t extended at all. Looks like they stopped developing after the first developer box
had successfully received an IP address, and shipped the resulting code. Woah.
If somebody can tell me how to configure the Windows DHCP server to properly handle a free-form string DHCP client
identfier, I’ll be most graceful for that information.
I finally resorted to setting the DHCP client identifier of my notebook to the MAC address of the wired ethernet
interface, which has at least brought my static IP address at the office back. I hope that the dnsmasq at home will
successfully grok this or I am - again - back to square one.
All software sucks