On 9/14/2025 12:19, Chris Ross wrote:
On Sep 14, 2025, at 08:27, Karl Denninger<k...@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 FreeIf 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
Rolling this around in my head some more..... what is the underlying interface?
I ask because I saw this happen with "re" driver interfaces (both IPv4 and 6) where it would not get an ARP map and thus couldn't see anything at all on the outside - there were enough other screwball things going on with the "re" driver (timeouts and similar) that I tossed that and now run on ix and a couple of SFP+ transceivers which has been entirely-stable (although igb also appears to work as I've gotten my hands on a box with a couple of those and tested that too.)
Given that arp issue I have to wonder if both are connected -- incidentally when I was testing that unit I also tried the "native" split IPv4/IPv6 requester for dhcp rather than dhcpcd and had the same results, so I tend to think dhcpcd is probably not the cause.
-- Karl Denninger k...@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/
smime.p7s
Description: S/MIME Cryptographic Signature
