dhcpcd-discuss

On 02/08/2020 22:55, Nathan O'Meara wrote:
> I disabled LAG/LACP, so there's only a real physical lan0 - I'm still seeing the 
> same behavior regarding routes.... but now I do see advertisements in that 
> tcpdump (and the dhcpcd log), but still no default route added by dhcpcd.
>
> However, that matches my earlier logs.. perhaps something else changed when I 
> added the bonding option to my kernel.  Since my old logs don't show dhcpcd 
> setting a default ipv6 route, my guess is that I was relying on the 
> kernel-native accept_ra setting.  I noticed that for some reason 
> net.ipv6.conf.wan0.accept_ra = 2.  2 seems to be 'always accept router 
> advertisements', but I tried setting it to 1 'accept if forwarding is not 
> enabled', and basically immediately the default route was populated.
>
> As for not seeing the advertisement packets at all when LAG/LACP was enabled, 
> that looks like a firmware bug in my modem.  If the modem side has LAG/LACP 
> enabled, but the router side doesn't, ipv4 was working fine, but I still didn't 
> see the advertisement packets.  Once I disabled LAG/LACP on the modem, the 
> packets started showing up.

Ok .....

> If accept_ra is set to 1 or 2, does dhcpcd not handle the default route to avoid 
> two processes handling the same task?

https://roy.marples.name/cgit/dhcpcd.git/tree/src/if-linux.c#n2037
So when dhcpcd starts IPv6 on an interface, it sets accept_ra to 0 - ie disable 
the kernel from handling the RA.

You only want one thing handling the RA - either the kernel, dhcpcd or something 
else.

> Aug 02 17:40:43 [6056]: br-3b5335941052: libudev: add
> Aug 02 17:40:43 [6056]: br-535d72c4732e: libudev: add
> Aug 02 17:40:43 [6056]: br-185afdecc360: libudev: add
> Aug 02 17:40:43 [6056]: docker0: libudev: add
> Aug 02 17:40:43 [6056]: vethd55b05c: libudev: add
> Aug 02 17:40:43 [6056]: veth262c1b7: libudev: add
> Aug 02 17:40:43 [6056]: veth9fa4842: libudev: add
> Aug 02 17:40:43 [6056]: veth70b84de: libudev: add
> Aug 02 17:40:43 [6056]: veth3bfd070: libudev: add
> Aug 02 17:40:43 [6056]: veth987f89f: libudev: add

Those are some crazy names!
Unrelated, just amused me :)

> Aug 02 17:40:46 [6056]: wan0: REPLY6 received from fe80::201:5cff:fe66:fe46
> Aug 02 17:40:46 [6056]: wan0: renew in 302400, rebind in 483840, expire in 
> 604800 seconds
> Aug 02 17:40:46 [6056]: lo: adding reject route to 2607:fcc8:9320:1400::/56
> Aug 02 17:40:46 [6056]: wan0: writing lease `/var/lib/dhcpcd/wan0.lease6'
> Aug 02 17:40:46 [6056]: wan0: delegated prefix 2607:fcc8:9320:1400::/56
> Aug 02 17:40:46 [6056]: lan0: adding address 2607:fcc8:9320:1400::1/64
> Aug 02 17:40:46 [6056]: lan0: pltime 604800 seconds, vltime 604800 seconds
> Aug 02 17:40:46 [6056]: lan0: waiting for DHCPv6 DAD to complete
> Aug 02 17:40:46 [6056]: lan0: adding route to 2607:fcc8:9320:1400::/64
> Aug 02 17:40:46 [6056]: wan0: executing `/lib/dhcpcd/dhcpcd-run-hooks' REBIND6
> Aug 02 17:40:46 [6056]: waiting for an IP address
> Aug 02 17:40:46 [6056]: wan0: ARP probing 104.230.3.34 (3 of 3), next in 2.0 seconds
> Aug 02 17:40:47 [6056]: wan0: Router Advertisement from fe80::201:5cff:fe66:fe46
> Aug 02 17:40:47 [6056]: wan0: no global addresses for default route
> Aug 02 17:40:47 [6056]: wan0: executing `/lib/dhcpcd/dhcpcd-run-hooks' ROUTERADVERT
> Aug 02 17:40:47 [6056]: lan0: DHCPv6 DAD completed
> Aug 02 17:40:47 [6056]: lan0: executing `/lib/dhcpcd/dhcpcd-run-hooks' DELEGATED6

I trimmed your log to just wan0 and lan0.
It seems that the test for global addresses is not taking into account delegated 
addresses and this is causing the default route from the RA not being added.
This looks most definitely like a dhcpcd bug, I'll try and look into it later today.

Roy