[Solved] DHCPcd says it gets a lease and then uses an IPv4LL

[ManDay]

I start `dhcpcd`, which depends on in `iwd` with OpenRC, and there a ca. 50-50 chance that it either works flawlessly or uses a linklocal address for the next minutes until it spontaneously reconfigures. /var/log/messages says:

[turtles]

Turn off IP4LL I think yo just lines at the end of /etc/dhcpcd.conf

[UberLord]

[ManDay]

turtles: Thanks, I'll try that.
UberLord: I've updated to 9.4.0::gentoo and it still happens. (I've also removed ntpd but that didn't seem to matter):

[UberLord]

That log looks ok to me - the key part is that the older version was deleting it's own default route here

[ManDay]

Oh I see. I misinterpreted the log pessimistically, although it only took a couple of seconds for setup to complete successfully. Thanks very much!

[UberLord]

As turtles said, if you cannot use IPv4LL then disable it in dhcpcd.conf and dhcpcd will then only fork once it gets a DHCP lease.
_________________
Use dhcpcd for all your automated network configuration needs
Use dhcpcd-ui (GTK+/Qt) as your System Tray Network tool

[ManDay]

I still occasionally have this problem. Less often now, I think, but the logs still look like it get a lease which doesn't supersede IPv4LL (this time, I think, I'm not misinterpreting it). The version of dhcpcd is 9.3.4:

[turtles]

post your dhcpcd.conf
_________________
Donate to Gentoo

[ManDay]

[turtles]

Add
noipv4ll
to the end of the file
_________________
Donate to Gentoo

[ManDay]

Sorry, I should have been clearer: I understand that would "solve" my problem, but it should also work with IPv4LL enabled, no?

[UberLord]

Because the DHCP lease expires, getting a new one is a 4 step process

client sends discover -> server replies with an address - > client requests address - > server acknowledges the address
Unless you have `noarp` in your config, dhcpcd will then spent several seconds ensuring the address is not in use by someone else.

Because your DHCP server is slow, dhcpcd is also handling IPv4LL at the same time.
It's not superceeding DHCP at all, but working alongside.

Once dhcpcd binds the address, it will remove the IPv4LL address. But it needs to go through all the above steps which could take upto 11 seconds or so on a bad day with high randomisation values.

For reference here are the two lines where the DHCP process above starts and stops.

[Tony0945]

Ah! I see from Uberlord's response that the DHCP server seems to be at fault. Are you using your router for DHCP? I'm using DNSmasq on a separate computer but you can use it on your computer or indeed establish a fixed ip address.
What is your router model? I went to DNSmasq because my ISP's DNS, in a word, sucked. I went the further step to using DNSMasq for DHCP because it gave me more flexibility over the router.

[ManDay]

Thanks. Just to be clear: The IPv4LL address did not stay around for mere seconds (in the above case with log), but I did not get a LAN address for several minutes, after which point I got tired of waiting and restarted.

So, from what you say I understand the server sent the offer (step 2), my requesting the address (step 3) happend but does not actually show up in the log, and the server for some reason never got around to acknowledge the address (step 4), so dhcpcd stuck with the LL address. Is that about right?

I will try (knowing that nothing's wrong on my end), but I suspect in that case desactivating IPv4LL will not help, if the server does not comply with step 4.

(no idea what the router is and I don't have access to it either; it's some ISP provided box and it's not my network, either)

[UberLord]

[turtles]

Agreed
having dealt with many crappy internet connections,
I keep IP4LL disabled unless I am trying to use it, that forces me to dig into the other issues.

It never forwards anything to the internet and gives you system a false sense of connection.
https://tools.ietf.org/html/rfc3927#section-2.7

Run some tcpdump commands and we'll see whats going on.
Probably on the edge of WIFI range?
Or if its wired could be a bad cable or NIC.
_________________
Donate to Gentoo

[ManDay]

I will try what you said. Since the update to >=dhcpcd-9 the problem occurs rarely, though, so it's kind of difficult to analyze (with tcpdump or changing settings).