Date: Sat, 20 Sep 2025 10:58:41 -0400 From: Tom Pusateri <pusateri@keehole.org> To: Chris Ross <cross+freebsd@distal.com> Cc: freebsd-net@freebsd.org Subject: Re: IPv6 networking problems in 14.3 Message-ID: <E8362AFD-E17E-47C2-91CC-C367C9F47F53@keehole.org> In-Reply-To: <A0767377-BFDE-4885-91C0-A0879A8400E5@distal.com> References: <910737314.4002.1757962919189@localhost> <55365E3D-B7EA-4F95-BC1E-92910A2944EA@distal.com> <90A490DE-6BF0-4EBB-97CE-ECA690E2359C@distal.com> <5D82826E-8C0F-45CF-B9FF-093FD014E73F@distal.com> <611820c2-05f8-40bc-9b07-bef012183e30@denninger.net> <408DE851-47FF-476E-B7F6-C7920A93DD43@distal.com> <1BF72AB3-69B6-4BC6-BA5B-6517BD35E41D@distal.com> <A0767377-BFDE-4885-91C0-A0879A8400E5@distal.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Have you considered simplifying everything to the most basic setup = first. It=E2=80=99s hard to keep up with what you=E2=80=99re 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=E2=80=99t work, = then try a new install of the release version of 14.2. If that doesn=E2=80= =99t 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. Tom > On Sep 20, 2025, at 10:39=E2=80=AFAM, Chris Ross = <cross+freebsd@distal.com> wrote: >=20 >=20 >=20 >> On Sep 18, 2025, at 16:36, Chris Ross <cross+freebsd@distal.com> = wrote: >>=20 >>> 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. [=E2=80=A6] >>=20 >> [...] I=E2=80=99ve set bootfs to the older 14.1 system and gotten = that running. >>=20 >> It [...] out SOLICIT6 messages and [..] if I waited long enough (2ish >> hours in my case), it eventually did get an answer! >=20 > 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=E2=80=99t 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. >=20 > 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=E2=80=99t 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. >=20 > So, it certainly could be the ISP, but the fact that I=E2=80=99m = getting RA=E2=80=99s > (and dhcp6 responses) which dhcpcd is processing, but then the MAC for > the routers LL isn=E2=80=99t available to the system, makes me think = it=E2=80=99s _not_ > the ISP. I can=E2=80=99t imagine why a working rootfs and kernel = could > show a system level problem intermittently, though. >=20 > Thoughts again invited. Not able to reproduce success now, I don=E2=80=99= t > know that I can actually _test_ anything, but I=E2=80=99d love to hear = thoughts > about any options/possibilities. >=20 > - Chris >=20 >=20 >=20 >=20 > [1] Sadly there is something wrong with /boot/kernel in that fs. When > I boot it I get a number of: >=20 > 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 >=20 > 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. >=20 > Current output log of dhcpcd: note "fe80::3e8a:b0ff:fe3e:4dce is = unreachable=E2=80=9D. > That=E2=80=99s a kernel routing issue, and I think the primary = problem. >=20 > 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 >=20 >=20 >=20
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E8362AFD-E17E-47C2-91CC-C367C9F47F53>