When initially getting IPv6 working a year or more ago, I tried multiple clients and was first able to get dhcpcd working, with Roy’s help. I do have dhcp6 installed, and have a config file for it, but I presume not one that works.
I’ll ping you off-list and share that, then later when the internet can be down for a while give it a try again to see. I’m happy to give an alternate client a try for helping narrow down the problem. Thanks. -Chris > On 4 Nov 2025, at 15:14, Tom Pusateri <[email protected]> wrote: > > 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. >> >> >> >> > >
