dhcpcd 10.0.5 needs restart when MAC changes

[juhaj]

trafficstars

The behaviour of dhcpcd when the interface MAC changes is odd. It seems that dhcpcd tries to use whatever MAC the interface had when dhcpcd started even if it has been changed since e.g. by iwd when changing to a different wifi AP. Sometimes dhcpcd just simply stops sending requests at all and neither dhcpcd --rebind nor dhcpcd --renew causes it to send a new one.

My expectation would be that this sequence (both dhcpcd and iwd are running) gets me a new IP on the new wifi:

dhcpcd --release # I need to do this because I have "persistent" turned on in the config file
iwctl station wlan0 disconnect
iwctl station wlan0 connect some_other_AP_different_from_current
dhcpcd --renew

but instead I only get the IPv6 RA stateless addresses (if the network of the new AP has any). If I instead restart the whole daemon, things work:

dhcpcd --release
dhcpcd --exit
iwctl station wlan0 disconnect
iwctl station wlan0 connect some_other_AP_different_from_current
dhcpcd -b

It looks to me as if dhcpcd reads the LL address once at startup and if that changes (as it will on most modern systems when changing networks), it does not notice and reread the new value.

The config file is the default supplied (comments removed), though I tried quite a few different options, too:

duid
persistent
vendorclassid
option domain_name_servers, domain_name, domain_search
option classless_static_routes
option interface_mtu
option host_name
option rapid_commit
require dhcp_server_identifier
slaac private

Another oddity is that the RA-derived addresses of the old network are not deleted - I would have expected them to be deleted, but maybe that is iwd's job when it disconnects the AP?

[rsmarples]

You should not need to do anything with dhcpcd, it listens to carrier changes. It also listens to hardware (MAC) address changes just fine which IIRC can only be made when the interface is in the down state. You've not said what dhcpcd version you're running? I do recall changing how carrier works on Linux wireless recently and that latest version reflects that.

[maskmovdqu]

Bumping this issue because I'm running into the same problem. I'm also using iwd with the network option AlwaysRandomizeAddress set to true (randomizes the MAC address on every new connection) and I'm unable to get a DHCP lease at all. Only way to "fix" this is restarting dhcpcd after iwd has connected to the AP. IPv6 RAs/SLAAC still work as usual however.

I'm using dhcpcd 10.1.0 (latest as of today) if that helps.

IIRC can only be made when the interface is in the down state

@rsmarples I don't think that this is actually the case anymore. Looks like the kernel added support for live changing the hardware address of the interface while it's up. I'm pretty sure that iwd is making use of this feature because I never see the interface actually going down. See here: https://github.com/torvalds/linux/commit/a36c421690b3e5dee38fc12abfcabda742f00064 https://github.com/torvalds/linux/commit/bb35f67195fcdbe79faa7a15ce148a67c9ab923d

Please note that this isn't exclusive to wireless devices. I can reproduce the same issue manually on any eth* wired interface just by running macchanger -r without taking the interface down first. ip link shows the new random MAC correctly but DHCP stops working as described above.