Zugschlusbeobachtungen

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