On 9/15/2025 13:20, Chris Ross wrote:
Unfortunately without being able to snoop on the ONT's glass side that's hard to diagnose; are they sending it at all, are they sending it to the wrong place, does the ONT have a map that's wrong between its fiber interface and the MAC connected to it, etc.On Sep 15, 2025, at 08:59, Karl Denninger <[email protected]> wrote: Hmmmmm.... just came in via git pull: dhclient: improve UDP checksum handlingThis could potentially apply to other bpf-using things -- which includes dhcpcd. And you have tso/lro turned on.It is a patch to dhclient, not dhcpcd but does the same issue potentially apply?I don’t know, but I think that isn’t my problem. It seems like the NS thatdhcpcd is sending is alright, and tcpdump doesn’t see an NA coming back in at all. - Chris
Fortunately the ISP I'm connected to when this sort of thing happened to me had people who actually knew what they were doing and were able to snoop the packets coming and going on their side when I was on the phone with them. Good luck getting a large ISP like Verizon to connect you to someone with the appropriate level of access into their gear to be able to do that. It took me a couple of rounds with KUB here before they went beyond "we cleared our ARP table entry for your ONT but we don't know why it did that" to getting someone on the line that actually was willing and able to snoop the traffic and determine WHY it happened.
The interesting part in this case (but probably the fortunate part!) was that their infrastructure for delegating an IPv4 (single address, you do the NAT) and /56 IPv6 is apparently entirely distinct thus that one had a hissy fit didn't prevent the other from coming up and functioning.
-- Karl Denninger [email protected] /The Market Ticker/ /[S/MIME encrypted email preferred]/
smime.p7s
Description: S/MIME Cryptographic Signature
