Re: IPv6 networking problems in 14.3
- In reply to: Tom Pusateri : "Re: IPv6 networking problems in 14.3"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Sat, 20 Sep 2025 15:32:30 UTC
> On Sep 20, 2025, at 10:58, Tom Pusateri <pusateri@keehole.org> wrote: > > Have you considered simplifying everything to the most basic setup first. It’s hard to keep up with what you’re doing. If it were me, I would use a different box with a new install of a release version of 14.3 and test a direct connection to the ONT (no switch, just a cable). Knowing whether that works will dictate your next steps. Surely you can find an old piece of hardware to put a clean install on that you can locate right next to the ONT. If it doesn’t work, then try a new install of the release version of 14.2. If that doesn’t work, try 14.1. Get a standard and simple setup working and then work your way backwards. > > Simplifying is key. Removing as many unknowns is key. Thank you. That’s a good suggestion. I do have a tendency both to make things to complicated, and also to change as few variables as possible. But, there are too many variables here already, I now see. I don’t know that removing the switches is possible, but everything else should be. I’ll try to prep a system for that so that I can experiment when I am able to next deny internet to the house. ;-) - Chris >> On Sep 20, 2025, at 10:39 AM, Chris Ross <cross+freebsd@distal.com> wrote: >> >> >> >>> On Sep 18, 2025, at 16:36, Chris Ross <cross+freebsd@distal.com> wrote: >>> >>>> On 17 Sep 2025, at 14:20, Chris Ross <cross+freebsd@distal.com> wrote: >>>> So, on the idea of trying to back-date the whole machine, I have ZFS >>>> snapshots of the whole root from just before the first upgrade, >>>> Aug 7/8. […] >>> >>> [...] I’ve set bootfs to the older 14.1 system and gotten that running. >>> >>> It [...] out SOLICIT6 messages and [..] if I waited long enough (2ish >>> hours in my case), it eventually did get an answer! >> >> And, this is where things went odd again. The above attempt in older >> filesystem, I had during boot menu chosen my ROUTER custom kernel. Just >> a config I traditionally use that has fewer devices in it occupying memory. >> So, thinking it shouldn’t make a difference I rebooted into the default, >> GENERIC, kernel on the system. The default kernel had problems [1], so I >> chose the boot/kernel.generic on the fs. >> >> Sadly, it did not work. I get the same state where the router LL is >> unroutable, ndp -an shows no MAC for it, and I have no IPv6. So, >> despite thinking the kernel config wasn’t key detail, I booted back >> into kernel.router. Now I have no IPv6 there either. I tried just >> shutting down dhcpcd overnight to see if it ISP was confused, but no help. >> >> So, it certainly could be the ISP, but the fact that I’m getting RA’s >> (and dhcp6 responses) which dhcpcd is processing, but then the MAC for >> the routers LL isn’t available to the system, makes me think it’s _not_ >> the ISP. I can’t imagine why a working rootfs and kernel could >> show a system level problem intermittently, though. >> >> Thoughts again invited. Not able to reproduce success now, I don’t >> know that I can actually _test_ anything, but I’d love to hear thoughts >> about any options/possibilities. >> >> - Chris >> >> >> >> >> [1] Sadly there is something wrong with /boot/kernel in that fs. When >> I boot it I get a number of: >> >> KLD uhid.ko: depends on kernel - not available or version mismatch >> KLD ums.ko: depends on kernel - not available or version mismatch >> KLD usbhid.ko: depends on kernel - not available or version mismatch >> KLD uhid.ko: depends on kernel - not available or version mismatch >> >> errors late in boot. That kernel is 14.1-RELEASE-p7 (despite the fs >> freebsd-update made named zroot/ROOT/14.1-RELEASE-p8_2025-08-08_074410). >> The rest of the kernels I have on the fs are 14.1p5. something must be >> off with that one. So I booted /boot/kernel.generic, 14.1p5, and it >> boots fine. >> >> Current output log of dhcpcd: note "fe80::3e8a:b0ff:fe3e:4dce is unreachable”. >> That’s a kernel routing issue, and I think the primary problem. >> >> Sep 20 10:20:32 [30273]: vlan0: REPLY6 received from fe80::3e8a:b0ff:fe3e:4dce >> Sep 20 10:20:32 [30273]: vlan0: renew in 3600, rebind in 5760, expire in 7200 seconds >> Sep 20 10:20:32 [30273]: lo0: adding reject route to 2600:4040:2c9c:2d00::/56 via ::1 >> Sep 20 10:20:32 [30273]: vlan0: writing lease: /var/db/dhcpcd/vlan0.lease6 >> Sep 20 10:20:32 [30273]: vlan0: delegated prefix 2600:4040:2c9c:2d00::/56 >> Sep 20 10:20:32 [30273]: vlan0: executing: /usr/local/libexec/dhcpcd-run-hooks BOUND6 >> Sep 20 10:29:08 [30273]: vlan0: Router Advertisement from fe80::3e8a:b0ff:fe3e:4dce >> Sep 20 10:29:08 [30273]: vlan0: no global addresses for default route >> Sep 20 10:29:08 [30273]: vlan0: executing: /usr/local/libexec/dhcpcd-run-hooks ROUTERADVERT >> Sep 20 10:30:15 [30273]: vlan0: fe80::3e8a:b0ff:fe3e:4dce is unreachable >> Sep 20 10:30:15 [30273]: vlan0: delaying IPv6 router solicitation for 0.7 seconds >> Sep 20 10:30:16 [30273]: vlan0: soliciting an IPv6 router >> Sep 20 10:30:16 [30273]: vlan0: sending Router Solicitation >> Sep 20 10:30:16 [30273]: vlan0: Router Advertisement from fe80::3e8a:b0ff:fe3e:4dce >> Sep 20 10:30:16 [30273]: vlan0: executing: /usr/local/libexec/dhcpcd-run-hooks ROUTERADVERT >> >> >> >