Re: IPv6 routing, Verizon FiOS, dhcpcd

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.
> 
> 
> 
>