NetworkConfiguration
dhcpcd doesn't provide much info if it fails to listen on the link local ipv6 address
dhcpcd 9.4.1 doesn't provide much info if it fails to listen on the link local ipv6 address. It just seems to sit there doing nothing. The only info it provides is if debug mode is enabled it outputs "delaying Router Solicitation for LL address" and "delaying DHCPv6 for LL address" .
This occurred when I was restarting dhcpcd a few times while getting the config the way I wanted it and for some reason the link local ip address disappeared on my wan interface and then even when restarting the interface to re-add the link local address, dhcpcd didn't seem to listen on it properly even though it was saying "net1: adding address <my_link_local_address>". I eventually decided to reboot Linux to get it working again.
Well, that's really all the information dhcpcd has. It needs a LL address to work. If there is none present during startup then it will add one. But it still needs to wait for it to become useable which takes a few seconds.
I notice in your other issue you are using the release directive - try removing that and see if it helps. Unlikely but it's all I've got.
I have run into this bug again after an hour long outage and after adding some more debugging to src/ipv6.c dhcpcd 9.5.1 , it looks like it thinks the fe80 on my internet interface (net1) isn't link local even though ip addr show dev net1 says scope link for the address.
dhcpcd logged that it deleted the fe80 address when carrier was lost. I'm wondering if that's what caused the problem. I might do a cable unplug later to see if that is causing the problem.
Oh I also found https://medium.com/opsops/how-to-restore-link-local-ipv6-address-in-linux-737666a505f3 which says how to regenerate the link local ip address.
Actually looking a bit more that didn't make sense as it is fe80 that determines a link local address. It looks like addr_flags is 0x44 for that address which on Linux apparently means it is in the TENTATIVE state.
Removing (!revflags || !(ap->addr_flags & revflags)) from if (IN6_IS_ADDR_LINKLOCAL(&ap->addr) in function: ipv6_iffindaddr has allowed IPv6 to work again on my server even though it still thinks ap->addr_flags is set to 0x44
Actually it looks like it only allowed accepting of the router advertisement to work. DHCPv6 still isn't working and my ISP uses both to provide IPv6.
I realise it's not the proper way to do it, but removing (ctx->options & (DHCPCD_MANAGER|DHCPCD_PRIVSEP)) == DHCPCD_MANAGER from the if test in dhcp6_start1 got dhcpcd to listen on the network interface for DHCPv6.
This might be resolved by this commit: 45e441ada6d3ea4355d623cf12d9a559a5c2afde
Actually looking a bit more that didn't make sense as it is fe80 that determines a link local address. It looks like addr_flags is 0x44 for that address which on Linux apparently means it is in the TENTATIVE state.
Right, so when the address comes out of the tentative state dhcpcd will start using it. It needs to wait for that to happen. The above commit solves this problem with PPP interfaces and maybe some others. Can you test it please?
I just updated from dhcpcd 9.5.1 (latest stable in Gentoo) to dhcpcd 10.0.1 without applying commit: 45e441a patch and it looks like 10.0.1 doesn't have the problem.