> On Sep 14, 2025, at 08:27, Karl Denninger <[email protected]> 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’m 95% sure my duid/MAC are static. And, unless that
would’ve changed between 14.1 and 14.3, I wouldn’t 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’s the same, but doesn’t literally record my IPv6 LL, DUID, or MAC.
So I think that’s not my problem. It’s not the ISP. I can try to switch back
to 14.1, I’ll 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
