Date: Mon, 15 Sep 2025 19:15:03 +0100 From: Roy Marples <roy@marples.name> To: "Karl Denninger" <karl@denninger.net> Cc: "Freebsd net" <freebsd-net@freebsd.org> Subject: Re: IPv6 networking problems in 14.3 Message-ID: <1994e966819.20444a00373298.5175621979752895403@marples.name> In-Reply-To: <dda91d8e-2a27-4af6-8c3b-06c84a60fc7f@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> <E06E4F40-0E2C-4C4E-9C27-3BCF086347FA@distal.com> <6fce77fb-9ba8-4c7b-bb9b-0e337d91f278@denninger.net> <1780EFAC-DA9C-4593-BE37-28E7FFCE4388@distal.com> <6e7a8fc6-12c8-4097-ad70-bcb1e4967ade@denninger.net> <092f8b7a-9b98-4e2a-b6c5-361b40549cce@denninger.net> <A8F67A5F-70B1-4336-B6AA-FBAC48F7000C@distal.com> <dda91d8e-2a27-4af6-8c3b-06c84a60fc7f@denninger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
------=_Part_3129823_2117311198.1757960103961
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
dhcpcd already has this behaviour.
Good luck!
Roy
=20
=20
=20
---- On Mon, 15 Sep 2025 18:59:15 +0100 Karl Denninger<karl@denninger.net=
> wrote ----
=20
=20
=20
=20
On 9/15/2025 13:20, Chris Ross wrote:
=20
=20
=20
=20
=20
=20
=20
On Sep 15, 2025, at 08:59, Karl Denninger=20
mailto:karl@denninger.net wrote:
=20
=20
=20
=20
=20
=20
=20
Hmmmmm.... just came in via git pull:
=20
=C2=A0 =C2=A0 dhclient: improve UDP checksum handling
=20
=20
=20
This could potentially apply to other bpf-using things=20
-- which includes dhcpcd.=C2=A0 And you have tso/lro turned=
=20
on.
=20
It is a patch to dhclient, not dhcpcd but does the same=20
issue potentially apply?
=20
=20
=20
=20
=20
=20
=20
=20
=20
=20
=20
I don=E2=80=99t know, but I think that isn=E2=80=99t my problem. =
=C2=A0It seems like=20
the NS that
=20
dhcpcd is sending is alright, and tcpdump doesn=E2=80=99t see an NA=
=20
coming
=20
back in at all.
=20
=20
=20
=20
=20
- Chris
=20
=20
=20
=20
=20
=20
=20
Unfortunately without being able to snoop on the ONT's glass side=20
that's hard to diagnose; are they sending it at all, are they=20
sending it to the wrong place, does the ONT have a map that's=20
wrong between its fiber interface and the MAC connected to it,=20
etc.
=20
Fortunately the ISP I'm connected to when this sort of thing=20
happened to me had people who actually knew what they were doing=20
and were able to snoop the packets coming and going on their side=20
when I was on the phone with them.=C2=A0 Good luck getting a large IS=
P=20
like Verizon to connect you to someone with the appropriate level=20
of access into their gear to be able to do that.=C2=A0 It took me a=
=20
couple of rounds with KUB here before they went beyond "we cleared=20
our ARP table entry for your ONT but we don't know why it did=20
that" to getting someone on the line that actually was willing and=20
able to snoop the traffic and determine WHY it happened.
=20
The interesting part in this case (but probably the fortunate=20
part!) was that their infrastructure for delegating an IPv4=20
(single address, you do the NAT) and /56 IPv6 is apparently=20
entirely distinct thus that one had a hissy fit didn't prevent the=20
other from coming up and functioning.
=20
--=20
=20
Karl Denninger
=20
mailto:karl@denninger.net=20
=20
The Market Ticker
=20
[S/MIME encrypted email preferred]
------=_Part_3129823_2117311198.1757960103961
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"><html><head>=
<meta content=3D"text/html;charset=3DUTF-8" http-equiv=3D"Content-Type"></h=
ead><body ><div style=3D'font-size:10pt;font-family:Verdana,Arial,Helvetica=
,sans-serif;color:#000000;'><div ><div>dhcpcd already has this behaviour.</=
div><div><br></div><div>Good luck!</div><div><br></div><div><div>Roy</div><=
/div> <br> </div><div class=3D"zmail_extra_hr" style=3D"border-top-width: 1=
px; border-top-style: solid; border-top-color: rgb(204, 204, 204); height: =
0px; margin-top: 10px; margin-bottom: 10px; line-height: 0px;"></div> <br> =
<div class=3D"replyHeader">---- On Mon, 15 Sep 2025 18:59:15 +0100 Karl De=
nninger<karl@denninger.net> wrote ----</div><div><br></div><blockquot=
e style=3D"border-left: 0px; padding-left: 0px; margin-left: 0px;"> <meta c=
ontent=3D"text/html; charset=3DUTF-8">=20
=20
<div>=20
<div class=3D"x_630959011moz-cite-prefix">On 9/15/2025 13:20, Chris Ros=
s wrote:<br>=20
</div>=20
<blockquote><br>=20
<div>=20
<blockquote>=20
<div>On Sep 15, 2025, at 08:59, Karl Denninger=20
<a class=3D"x_630959011moz-txt-link-rfc2396E" href=3D"mailto:ka=
rl@denninger.net" target=3D"_blank"><karl@denninger.net></a> wrote:</=
div>=20
<br class=3D"x_630959011Apple-interchange-newline">=20
<div>=20
<meta content=3D"text/html; charset=3DUTF-8">=20
<div>=20
<p>Hmmmmm.... just came in via git pull:</p>=20
<p> dhclient: improve UDP checksum handling<br>=
=20
<br>=20
This could potentially apply to other bpf-using things=20
-- which includes dhcpcd. And you have tso/lro turned=
=20
on.</p>=20
<p>It is a patch to dhclient, not dhcpcd but does the same=20
issue potentially apply?</p>=20
</div>=20
</div>=20
</blockquote>=20
<div><br>=20
</div>=20
I don=E2=80=99t know, but I think that isn=E2=80=99t my problem. &n=
bsp;It seems like=20
the NS that</div>=20
<div>dhcpcd is sending is alright, and tcpdump doesn=E2=80=99t see an=
NA=20
coming</div>=20
<div>back in at all.</div>=20
<div><br>=20
</div>=20
<div>- Chris</div>=20
<div><br>=20
</div>=20
</blockquote>=20
<p>Unfortunately without being able to snoop on the ONT's glass side=20
that's hard to diagnose; are they sending it at all, are they=20
sending it to the wrong place, does the ONT have a map that's=20
wrong between its fiber interface and the MAC connected to it,=20
etc.</p>=20
<p>Fortunately the ISP I'm connected to when this sort of thing=20
happened to me had people who actually knew what they were doing=20
and were able to snoop the packets coming and going on their side=20
when I was on the phone with them. Good luck getting a large IS=
P=20
like Verizon to connect you to someone with the appropriate level=20
of access into their gear to be able to do that. It took me a=
=20
couple of rounds with KUB here before they went beyond "we cleared=20
our ARP table entry for your ONT but we don't know why it did=20
that" to getting someone on the line that actually was willing and=20
able to snoop the traffic and determine WHY it happened.</p>=20
<p>The interesting part in this case (but probably the fortunate=20
part!) was that their infrastructure for delegating an IPv4=20
(single address, you do the NAT) and /56 IPv6 is apparently=20
entirely distinct thus that one had a hissy fit didn't prevent the=20
other from coming up and functioning.</p>=20
<div class=3D"x_630959011moz-signature">-- <br>=20
Karl Denninger<br>=20
<a href=3D"mailto:karl@denninger.net" class=3D"x_630959011moz-txt-lin=
k-freetext" target=3D"_blank">karl@denninger.net</a><br>=20
<i>The Market Ticker</i><br>=20
<font size=3D"-2"><i>[S/MIME encrypted email preferred]</i></font></d=
iv>=20
</div> </blockquote></div><br></body></html>
------=_Part_3129823_2117311198.1757960103961--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1994e966819.20444a00373298.5175621979752895403>