Just upgraded a machine over the weekend from Slackware 12.2 to 13.0. Everything went fine except for a strange new behavior with the dhcp client.

Prior to the upgrade, everything was just dandy. After the upgrade, it seems that the MAC address that is reported to the dhcp server is incorrect.

ifconfig still shows me the correct MAC address...
eth0 Link encap:Ethernet HWaddr 00:0c:29:da:71:b9
That's the same MAC it's always had.

But now, on the dhcp server side, the MAC that it receives is this crazy string 657468300001000112897d63000c29da71b9

This is on a Windows Server 2003 dhcp service. I use a dhcp reservation which no longer works because the MAC has gone whack. I can't create a new reservation because it doesn't like the address. The server DOES assign an address, it just doesn't obey the reservation so it's no good to me.


So far the only solution I could come up with is changing it to a static ip.

That's nowhere close to a valid MAC. Is 13 using the correct driver for your nic? Check if you have to correct module loaded. Does your gateway list connected devices? You can check if the correct MAC is captured by your gateway when you connect statically.

You could try setting HWADDR[0] in /etc/rc.d/rc.inet1.conf to the correct Mac address. This shouldn't be neccesary but it may help. Althouigh ideally it's best to try to get to the bottom of this if possible rather than work around it.

I think I've got a little better understanding about what is going on.

The issue here is something called "DUID" that the dhcp client now uses, but the dhcp server in Windows Server 2003 doesn't cope with. Essentially it prefixes some numbers to the hardware address to use as the clientid... I guess there is some benefit to this new method.

I'm been digging through the Slackware changelog trying to make sense of the chain of events. Slackware 13 includes dhcpcd-3.2.3, dhcpcd-2.0.8 was the previous version. It looks like this new DUID stuff was introduced somewhere around dhcpcd 3.1.x back in 2007 - I found some discussion about these problems.

Anyway, the easiest solution I found was to run the client with the -I flag which is supposed to disable DUID support. I'll give this a test after business hours and post again if it works.

Ok, I just tested it with adding -I "" to the dhcpcd command that is run in /etc/rc.d/rc.inet1 and now it's working again.