Date: Sun, 14 Sep 2025 12:19:22 -0400 From: Chris Ross <cross+freebsd@distal.com> To: Karl Denninger <karl@denninger.net> Cc: freebsd-net@freebsd.org Subject: Re: IPv6 networking problems in 14.3 Message-ID: <E06E4F40-0E2C-4C4E-9C27-3BCF086347FA@distal.com> In-Reply-To: <dfa7af0c-334f-4b36-86dc-b2d75d1477d3@denninger.net> References: <4C00D174-21FE-47C4-A30A-A382138571A5@keehole.org> <A9EBD993-D77D-49F9-9FFB-0E42EA0BEE6E@keehole.org> <DC84D8EC-B084-4AF1-B3F4-413323DA613A@distal.com> <dfa7af0c-334f-4b36-86dc-b2d75d1477d3@denninger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Sep 14, 2025, at 08:27, Karl Denninger <karl@denninger.net> wrote:
> That gateway isn't by any chance running out of RAM such as on nanobsd =
(e.g. /var is volatile) is it?
No. Full fledged machine here.
% df -h /var
Filesystem Size Used Avail Capacity Mounted on
zroot/ROOT/default 1.4T 7.3G 1.4T 1% /
% top | head
last pid: 41577; load averages: 0.00, 0.01, 0.00 up 37+03:40:12 =
12:11:35
44 processes: 1 running, 43 sleeping
CPU: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle
Mem: 30M Active, 639M Inact, 5741M Wired, 136K Buf, 118G Free
ARC: 2464M Total, 1139M MFU, 708M MRU, 723K Anon, 25M Header, 588M Other
1442M Compressed, 3493M Uncompressed, 2.42:1 Ratio
Swap: 8192M Total, 8192M Free
> If so the duid is non-fixed and some ISPs will have a hiss-fit in that =
they "marry" the MAC on your end to the MAC on the ONT along with the =
duid and use that internally. If the duid changes but the MAC does not =
it will not arp and you're hosed as their end has no internal map back =
to your gateway thus you don't get the advertisements (and in some cases =
no delegation either!) and it doesn't come up.
> I also have "noarp" in my config which otherwise made the ISP's gear =
upset. In addition I have made sure the duid doesn't change (try "duid =
ll" which will generate one that won't so long as the interface it is =
applied to doesn't) and/or move /var/db/dhcpcd to something that can be =
sync'd (e.g. symlink it to /usr/local/etc/db/dhcpcd and then after the =
first boot sync that) so the duid file gets restored on a restart.
> I ran into this with my fiber here; the former cable company did not =
care if all this was volatile on a restart however the fiber firm did it =
was a load of fun to get someone on the phone who actually could figure =
out *why* their system got mad and wouldn't reconnect. In my case their =
end would return an IPv4 address and function but would not come back up =
on IPv6 unless they cleared their internal tables manually.
Thanks for the ideas. I=E2=80=99m 95% sure my duid/MAC are static. =
And, unless that would=E2=80=99ve changed between 14.1 and 14.3, I =
wouldn=E2=80=99t expect that to be a problem. I certainly can tell with =
every reboot that I have the same address. Let me see if my dhcpcd.log =
tells me what it used to be...
No, looks like I can confirm the same /56 was delegated before as now, =
which suggests it=E2=80=99s the same, but doesn=E2=80=99t literally =
record my IPv6 LL, DUID, or MAC.=20
So I think that=E2=80=99s not my problem. It=E2=80=99s not the ISP. I =
can try to switch back to 14.1, I=E2=80=99ll research whether I can do =
that via ZFS snapshots without it being an act of no return. Google =
will tell me. Otherwise, I may try booting a 14.1 kernel and see what =
that does. Might break things with a 14.3 user land, but easy to try.
- Chris
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E06E4F40-0E2C-4C4E-9C27-3BCF086347FA>