Re: IPv6 networking problems in 14.3
- Reply: Chris Ross : "Re: IPv6 networking problems in 14.3"
- In reply to: Chris Ross : "Re: IPv6 networking problems in 14.3"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
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]/