Regarding device running with the dhcpcd client failed to get a valid IP address and ended up with an auto IP [link local IP address 169.254.x.x]

[Sateesh-Patil]

HI All,

We have below a few issues where the device running the dhcpcd client failed to get a valid IP address and ended up with an auto IP [link local IP address 169.254.x.x] for the below scenarios.

Issue 1: When the AP/STA is enabled with MBO [multi-band operation], switching between AP/channel/band [2.4 GHz and 5 GHz vice versa] for better connectivity, we have observed the device going to the link local address, and we have checked the device sending a 'discover' packet, but there is no response from the AP/STA to which the device is connected.

—In this case, if the device reboots, we get a valid IP address.

Issue 2: The device goes to a link-local address for some specific routers and checks the device actually sending a 'discover' packet but gets no response from the router.

Just wanted to check from the dhcpcd perspective what all the lists of possible cases are when the device will get a link-local address.?

[rsmarples]

dhcpcd will use a link-local address if ipv4ll is enabled and there is no DHCP address obtained after the timeout internal from the DHCP discovery process starting.

dhcpcd initiates DHCP on carrier down/up or dormant/not dormant notifications from the kernel. What is the frequency of these happening?

[Phani-Sreenivasa-Prasad]

dhcpcd will use a link-local address if ipv4ll is enabled and there is no DHCP address obtained after the timeout internal from the DHCP discovery process starting.

dhcpcd initiates DHCP on carrier down/up or dormant/not dormant notifications from the kernel. What is the frequency of these happening? Can you please respond to below queries.

One of the routers in our network environment, is dropping DHCP unicast responses and client is not getting IP address.

1. how are the retries implemented in dhcpcd 8.1 and 10.0? Is there any difference in retry logic mechanism between these versions?
2. If dhcpcd doesnt get response with bootp_flag set to unicast in the Discover/Request packet, does it retry with flag set to broadcast again? and for how long it would continue doing retries ?
3. Will it giveup doing retries after some time once it acquires link-local address ?
4. will it do retries indefinitely if set "persistence" in the /etc/dhcpcd.cnf ?

[rsmarples]

1. There should be no real difference in the retry logic
2. Unsure what you mean? DISCOVER is always unicast. REQUEST is unicast if RENEWING and broadcast if REBINDING. If renew fails then we start to rebind, if that fails then we start ipv4ll and start DISCOVER. DHCP never gives up and is rate limited to a request a minute in the worst case
3. No, dhcpcd never gives up
4. persistence means dhcpcd will not remove the configuration when it stops. It doesn't do anything else.

[Phani-Sreenivasa-Prasad]

regarding (2),

BOOTP flag( Broadcast flag bit) : This flag in the DHCP Discover message indicates whether the client is requesting a unicast or broadcast reply from the DHCP server.

We see currently this flag is set to 0 by default in the DHCP DISCOVER and REQUEST which means expecting a unitcast response from server. But since the router is dropping unicast responses, we want to know if dhcpcd does automatically fallback and set this flag to 1 on subsequent retries ? which means expecting a broadcast response from server in reply to DISCOVER or REQUEST .

Hence asking about retries in dhcpcd how it has been implemented today.

[perkelix]

@Phani-Sreenivasa-Prasad Since 10.2.3, dhcpcd minor changes were made to ensure that the IPv4LL (169.254.x.x) fallback never fails. Does this solve your issue?