Erroneous DHCPDECLINE after MAC address changes

[faulesocke]

trafficstars

I have the following network setup inside a VM:

• "Hardware" ethernet interface eth0 has MAC 52:..
• couple of veth interfaces into containers, one of them has MAC '0e:..`
• a bridge br0 across all of them
• dhcpcd running on br0

Now, when the system boots, the br0 is created wth only one slave, eth0. Therefore (and according to superuser.com) the br0 inherits the MAC address of eth0. Then dhcpcd is started on br0. Later in the boot process, the containers are brought up and their veth interfaces are added to the bridge. The bridge will now change it's MAC to the lowest MAC of all enslaved interfaces, which is 0e:...

This will cause trouble inside dhcpcd: Everytime I send an ARP request with the hosts current IP, the host will correctly respond (on the bridge) with the bridges current MAC address. dhcpcd will see this response, will think something else has the same IP and will send a DHCPDECLINE and request a new IP from the DHCP server.

I think this bug comes from dhcpcd caching the current MAC address during startup, but I haven't checked the source. I have a couple ways of working around that bug, but I think the only real solution is to fix it inside dhcpcd.

# dhcpcd --version
dhcpcd 10.1.0
Copyright (c) 2006-2024 Roy Marples
Compiled in features: INET ARP ARPing IPv4LL INET6 DHCPv6 AUTH

The buggy behaviour was introduced with an update of the underlying NixOS, but that does not mean that it did not exist in dhcpcd before. It could also mean, that the MAC of the underlying veth interface was different before and the bug never appeared.

[rsmarples]

I think this bug comes from dhcpcd caching the current MAC address during startup, but I haven't checked the source. I have a couple ways of working around that bug, but I think the only real solution is to fix it inside dhcpcd.

Recent Linux changes allows supporting interfaces to change MAC address without the interface being brought down. I think dhcpcd only allows the interface to be down for this. I guess this is what you are seeing? Hard to guess though without any logs to see what dhcpcd is doing.