Does the same problem occur with KAME DHCP client and if so, does the same delay fix the problem at boot? I use the KAME dhcp6 client still (dhcp6-20080615) and it doesn’t seem to have this problem for me but I am using a different upstream provider.
It sounds like dhcpcd is not handling dynamic interfaces correctly. Tom > On Nov 4, 2025, at 2:48 PM, Chris Ross <[email protected]> wrote: > > Apologies for top-post, but the earlier retained below is little more than > trimmed history. I wanted to come back to this for advice. What I have done > to solve (aka work around) this problem for myself is two changes in > /usr/local/etc/rc.d/dhcpcd: > > ——8<——8<——8<——8<——8<—— > --- dhcpcd.orig 2024-10-13 12:22:44.181922000 -0400 > +++ dhcpcd 2025-10-06 13:41:14.523012000 -0400 > @@ -1,6 +1,7 @@ > #!/bin/sh > # PROVIDE: dhclient dhcpcd > +# REQUIRE: netif > # KEYWORD: nojailvnet > # > @@ -29,6 +30,23 @@ > { > # dhcpcd may need local binaries > export PATH=${PATH}:/usr/local/sbin:/usr/local/bin > +} > + > +start_postcmd="dhcpcd_pause" > +dhcpcd_pause() > +{ > + boottime=`sysctl -n kern.boottime | sed -e 's/.*sec = \([0-9]*\),.*/\1/'` > + now=`date +%s` > + # When running at boot, it'll take a while to initially set up the > + # interfaces such that the addresses et al can be bound, I don't > + # know why, but in the normal case if I don't wait here, local_unbound > + # cannot bind port 53 on one or more of the addresses. > + if [ `expr $now - $boottime` -lt 90 ]; then > + stdbuf -o 0 echo "${name} waiting for addresses to stabilize ... " > + sleep 2 > + echo "done" > + fi > + > } > load_rc_config $name > ——8<——8<——8<——8<—— > > Part 1 is what avoids the problem I was originally seeing. If I delay > dhcpcd starting until after the interfaces are all online, it is able > to successfully talk with the next-hop router. I still do not know why > it is failing to reach the IPv6 next-hop when it is, and why starting > dhcpcd later avoids the problem. Any thoughts welcome. > Part 2 above is for the problem I mentioned in a second email about > interface renaming. It turns out that if local_unbound tries to bind > to the address that dhcpcd has _just_ shoved onto the interface, it > will fail. The above delay avoids this problem. > > The problem, of course, is that I’ve changed dhcpcd to run _after_ netif, > which is not a general solution. For anyone using dhcpcd to do it’s normal > job of obtaining addresses, it needs to run before or as part of netif. > So, so that I don’t need to maintain my own separate version of this > that is unusable upstream, what can I do to figure out why starting > dhcpcd later (after IPv4 is fully operational or something else in netif), > is required to avoid the problem? > > Thanks. > > - Chris > >> On 6 Oct 2025, at 13:59, Chris Ross <[email protected]> wrote: >> >> […] What I am _not_ seeing in tcpdump is >> neighbor advertisements in response to my NS’s. At least, when >> the problem is occurring. I can wait for hours, and I never get >> an NA for the router I’m NS’ing for. >> >> I see now that in my test where I delayed dhcpcd startup, I do get >> NS back, so that makes sense. But I can’t imagine how when I start >> dhcpcd affects whether or not Verizon responds to my NS. >> >>> Does this act the same with another DHCPv6 client like KAME dhcp6c instead >>> of using dhcpcd? >> >> I have not tested others. Again, I don’t think it’s a DHCP thing, >> The DHCP part is actually working. It’s that something else is >> happening at an addressing level. > > > >
