Re: IPv6 networking problems in 14.3

> On Sep 20, 2025, at 10:58, Tom Pusateri <[email protected]> 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 <[email protected]> wrote:
>> 
>> 
>> 
>>> On Sep 18, 2025, at 16:36, Chris Ross <[email protected]> wrote:
>>> 
>>>> On 17 Sep 2025, at 14:20, Chris Ross <[email protected]> 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
>> 
>> 
>> 
>