Re: IPv6 networking problems in 14.3

From: Karl Denninger <karl_at_denninger.net>
Date: Wed, 17 Sep 2025 10:56:26 UTC
On 9/17/2025 00:07, Chris Ross wrote:
>> On Sep 16, 2025, at 23:24, Chris Ross<cross+freebsd@distal.com> wrote:
>>>> On Sep 15, 2025, at 15:05, Tom Pusateri<pusateri@keehole.org> wrote:
>>>>
>>>> I would try running the 14.3p2 system without the VLAN configuration and a direct connection to the upstream provider hardware (no switch) and see if the problem persists. That will determine if it’s a VLAN issue.
>>> That would be a bit of work.  I have an available ix port, so I can run a line to the machine
>>> without vlan. It would still be a VLAN in the switch, because running a direct line is not
>>> possible without much rewiring and very long cables.
>> So this is my next attempt.
> So, reconfiguring this wasn’t as hard as I feared.  But, it’s not working.  I’m getting
> an IPv4 address as before, surprisingly even the same one, on my ix1 interface.  I’ve
> changed interface names in rc.conf, pf.conf, and dhcpcd.conf.  However, dhcpcd is now
> doing something different.  Only changing the interface name in the config, I’m not sure
> why.
>
> Sep 16 23:47:34 [98787]: ix1: soliciting an IPv6 router
> Sep 16 23:47:34 [98787]: ix1: sending Router Solicitation
> Sep 16 23:47:34 [98787]: ix1: Router Advertisement from fe80::3e8a:b0ff:fe3e:4dce
> Sep 16 23:47:34 [98787]: ix1: no global addresses for default route
> Sep 16 23:47:34 [98787]: ix1: executing: /usr/local/libexec/dhcpcd-run-hooks ROUTERADVERT
> Sep 16 23:47:34 [98787]: ix1: multicasting SOLICIT6 (xid 0x1e9737), next in 1.1 seconds
> Sep 16 23:47:36 [98787]: ix1: multicasting SOLICIT6 (xid 0x1e9737), next in 2.0 seconds
> Sep 16 23:47:38 [98787]: ix1: multicasting SOLICIT6 (xid 0x1e9737), next in 4.2 seconds
> Sep 16 23:47:42 [98787]: ix1: multicasting SOLICIT6 (xid 0x1e9737), next in 8.9 seconds
> Sep 16 23:47:51 [98787]: ix1: multicasting SOLICIT6 (xid 0x1e9737), next in 17.8 seconds
> Sep 16 23:48:03 [98787]: timed out
> Sep 16 23:48:03 [98492]: forked to background
> Sep 16 23:48:09 [98787]: ix1: multicasting SOLICIT6 (xid 0x1e9737), next in 37.9 seconds
> Sep 16 23:48:47 [98787]: ix1: multicasting SOLICIT6 (xid 0x1e9737), next in 71.2 seconds
> Sep 16 23:49:58 [98787]: ix1: multicasting SOLICIT6 (xid 0x1e9737), next in 142.0 seconds
> Sep 16 23:52:20 [98787]: ix1: multicasting SOLICIT6 (xid 0x1e9737), next in 274.4 seconds
>
> Where as before, when it was not getting the answer to NS, it was simply doing:
>
> Sep 15 14:00:58 [10047]: vlan0: soliciting an IPv6 router
> Sep 15 14:00:58 [10047]: vlan0: sending Router Solicitation
> Sep 15 14:00:58 [10047]: vlan0: Router Advertisement from fe80::3e8a:b0ff:fe3e:4dce
> Sep 15 14:00:58 [10047]: vlan0: no global addresses for default route
> Sep 15 14:00:58 [10047]: lo0: adding reject route to 2600:4040:2c9d:5200::/56 via ::1
> Sep 15 14:00:58 [10047]: vlan0: executing: /usr/local/libexec/dhcpcd-run-hooks ROUTERADVERT
> Sep 15 14:00:58 [10047]: vlan0: multicasting REBIND6 (xid 0x0a7d83), next in 1.0 seconds
> Sep 15 14:00:58 [10047]: vlan0: REPLY6 received from fe80::3e8a:b0ff:fe3e:4dce
> Sep 15 14:00:58 [10047]: vlan0: renew in 3600, rebind in 5760, expire in 7200 seconds
> Sep 15 14:00:58 [10047]: vlan0: writing lease: /var/db/dhcpcd/vlan0.lease6
> Sep 15 14:00:58 [10047]: vlan0: delegated prefix 2600:4040:aaaa:bb00::/56
> Sep 15 14:00:58 [10047]: int1: adding address 2600:4040:aaaa:bb12::1/64
> Sep 15 14:00:58 [10047]: int1: pltime 7200 seconds, vltime 7200 seconds
> Sep 15 14:00:58 [10047]: int1: waiting for DHCPv6 DAD to complete
>
> Oh.  So with a new interface, dhcpcd isn’t trying to REBIND, so it’s a different
> process. I’m not seeing any response to the SOLICIT messages, but I admit that I
> wasn’t watching the DHCPv6 ports earlier, only the ICMP6, so this may not be
> new.
>
> This is all for tonight.  I’ll try more tomorrow.  Thanks all for your time.
>
> - Chris

That is precisely what it was doing here when my ISP had a hissy-fit due 
to cached (on their end) association between the ONT/MAC/duid.

They said it would eventually clear (after their pltime expired -- about 
2 weeks!) but obviously that's not really an answer; as soon as they 
"kicked it" on their end it came up immediately.

-- 
Karl Denninger
karl@denninger.net
/The Market Ticker/
/[S/MIME encrypted email preferred]/