13

Debian Buster dhclient randomly uses its MAC address or a generated DUID-LLT as its DHCP client ID.

Can I force it to always use MAC address instead of the generated DUID-LLT?

I know the option send dhcp-client-identifier = xx:xx:xx:xx:xx:xx;, but it forces me to configure every interface manually with its own MAC address, something I prefer to avoid if possible.

As I said before, it is doing it already, but randomly.

Can it be forced to do it always?

Improve this question
6
  • Doing it "randomly" is a bit unusual, and it's actually the first time I've heard of dhclient sending a DUID on its own... Are you sure the system doesn't actually have two DHCP clients running at the same time? (e.g. dhclient and dhcpcd or systemd-networkd running alongside it?)
    – u1686_grawity
    May 19, 2020 at 7:36
  • @user1686 Its a badly configured network with a badly configured Windows DHCP server. This is most likely the cause of the problem, but solving it is another issue. The thing is that Debian Buster dhclient sometimes use the MAC address as client ID so it seems that it should be possible to do it always... or so I think.
    – massa
    May 19, 2020 at 8:50
  • @user1686 My Debian machines only uses dhclient; systemd DHCP client is disabled as it comes by default. It isn't an issue of two competing DHCP clients.
    – massa
    May 19, 2020 at 8:54
  • Does the issue remain if you delete stored leases under /var/lib/dhclient (and maybe from the DHCP server as well)?
    – u1686_grawity
    May 19, 2020 at 8:59
  • @user1686 It generates a new DUID-LLT.
    – massa
    May 19, 2020 at 9:16

2 Answers 2

Reset to default
25

The solution is simple, but not documented (not on the manpage of dhclient.conf at least). You can set the option send dhcp-client-identifier = hardware instead of hardcoding a specific MAC address.

Complete example:

$ echo "send dhcp-client-identifier = hardware;" >>/etc/dhcp/dhclient.conf
$ rm /var/lib/dhcp/*
$ systemctl restart networking

It configures dhclient to send hardware address as client identifier, removes previous leases and restart interfaces with new settings. After this change it will use the MAC address as the client ID of each interface, automatically.

Improve this answer
2
  • 1
    A total life-saver because as massa says it is not documented. I was having this problem with Debian 10 buster as DHCP client and Windows 2012 Server as DHCP server. I cannot get rid of the 2012, so this has really made my day. Thanks!
    – Luis Antolín Cano
    Oct 7, 2020 at 8:56
  • What's really odd is that it still generates the DUID with this option on, it just doesn't appear to use it. We were having a bunch of problems with our DHCP server issuing new IPs for no reason, so hopefully this fixes it.
    – Compholio
    Oct 23 at 17:16
3

Since this change https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906894 ifupdown had been adding the -i parameter to dhclient.

-i     Use a DUID with DHCPv4 clients.

But here is a fix: this change https://salsa.debian.org/debian/ifupdown/-/commit/40eb51499fe71e4fb20c27beea23045c62e9ba07 went to ifupdown 0.8.36 and makes the -i option optional. This is kind of documented in the (new enough) manpage for /etc/network/interfaces: man interfaces / INET ADDRESS FAMILY / "The dhcp Method" / Options / client

client client_id
    Client identifier (dhcpcd), or "no" (dhclient)

So, for my case the practical solution was to add "client no" to my /etc/network/interfaces, like

.....
iface eno1 inet dhcp
    client no

which brings the old behaviour, which is: ifup calls dhclient without "-i", as seen here: https://salsa.debian.org/debian/ifupdown/-/blob/40eb51499fe71e4fb20c27beea23045c62e9ba07/inet.defn#L101 For the record, I look at the command line parameters for confirmation: ps aux | grep dhclient

(By the way, to see the logs one can go like: sudo journalctl | grep -i dhcp | less)

This way it can talk to a DHCP server that is scared of RFC 4361.

This comes with a bit of fine print: for Debian 10, I had to backport the ifupdown package. I have followed https://unix.stackexchange.com/a/112160/203082 to obtain locally a ifupdown_0.8.36~bpo10+1_amd64.deb package. After installation, I wasn't able to cleanly restart my networking (probably due to some systemd-related complexities).

So I had to reboot, unfortunately. Then it was able to obtain the IP address as expected.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .