From nobody Mon Sep 15 18:15:03 2025 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cQY9916Qgz67kbN for ; Mon, 15 Sep 2025 18:15:09 +0000 (UTC) (envelope-from roy@marples.name) Received: from sender-of-o51.zoho.eu (sender-of-o51.zoho.eu [136.143.169.51]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4cQY984qj8z41nh for ; Mon, 15 Sep 2025 18:15:08 +0000 (UTC) (envelope-from roy@marples.name) Authentication-Results: mx1.freebsd.org; none ARC-Seal: i=1; a=rsa-sha256; t=1757960106; cv=none; d=zohomail.eu; s=zohoarc; b=Q8pXOn0rJJ6WkEPo41hRtCY1jBqik3Z2B0iQav1UZhUKws9EgCgS+oyY5xxNipU9Leytnq2Yx9PB7c2XPiNpdscdUo8L4uIH2ccD3zBdNmk6xXhTtdk8sqXJxbKsiBTUU9mw6jJmuKwAb4ttUY2DknBebVLuUMUkSJrGQGMcXwU= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.eu; s=zohoarc; t=1757960106; h=Content-Type:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; bh=D8bNpImur2U8Fp3HgSmi8cTShsly+nobmfA1ZeoHinc=; b=G1lIRGEqzdWQ1va3Y1vq5sJGRQFmswVR0Yqru3rjNQT/SRXJ8dU7osswF/SwURF0nWFpNAe20ZJYpLWvBVBz+5rCplQcC76NmNF5/ww2QesgH5Mm2Xr9RiCCjNJ/wLtQ7Ypxmou2chLtDX2deKwxvjKDe7ao2HANGn9ODtBdSSs= ARC-Authentication-Results: i=1; mx.zohomail.eu; dkim=pass header.i=marples.name; spf=pass smtp.mailfrom=roy@marples.name; dmarc=pass header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1757960106; s=zmail; d=marples.name; i=roy@marples.name; h=Date:Date:From:From:To:To:Cc:Cc:Message-Id:Message-Id:In-Reply-To:References:Subject:Subject:MIME-Version:Content-Type:Reply-To; bh=D8bNpImur2U8Fp3HgSmi8cTShsly+nobmfA1ZeoHinc=; b=TP6jcVlFsGwEdSZzGZlFKhFlkvMVCqMhqObKbNr2AwUdlh7c9jx97xuz8Pl3OYkH 5Q5t0+D0xiTTsRBw/R4EWRG4kVU8L5oOLxL7kPkZvnAuoxhPkWb6Ktxw3REEYYcDFHb wTPSidEEIv41Z9HA0yJZfNWx+6MD3Mpfl4SiWC6g= Received: from mail.zoho.eu by mx.zoho.eu with SMTP id 1757960103962982.5875150480769; Mon, 15 Sep 2025 20:15:03 +0200 (CEST) Date: Mon, 15 Sep 2025 19:15:03 +0100 From: Roy Marples To: "Karl Denninger" Cc: "Freebsd net" Message-Id: <1994e966819.20444a00373298.5175621979752895403@marples.name> In-Reply-To: References: <4C00D174-21FE-47C4-A30A-A382138571A5@keehole.org> <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> Subject: Re: IPv6 networking problems in 14.3 List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@FreeBSD.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3129823_2117311198.1757960103961" User-Agent: Zoho Mail X-Mailer: Zoho Mail X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:41913, ipnet:136.143.168.0/23, country:CH] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4cQY984qj8z41nh ------=_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 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 =
dhcpcd already has this behaviour.

Good luck!

Roy
<= /div>

=
---- On Mon, 15 Sep 2025 18:59:15 +0100 Karl De= nninger<karl@denninger.net> wrote ----

=20 =20
=20
On 9/15/2025 13:20, Chris Ros= s wrote:
=20
=20

=20
=20
=20
On Sep 15, 2025, at 08:59, Karl Denninger=20 <karl@denninger.net> wrote:=20
=20
=20 =20
=20

Hmmmmm.... just came in via git pull:

=20

    dhclient: improve UDP checksum handling
= =20
=20 This could potentially apply to other bpf-using things=20 -- which includes dhcpcd.  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 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
=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
- Chris
=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.  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.

=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 Karl Denninger
=20 karl@denninger.net
=20 The Market Ticker
=20 [S/MIME encrypted email preferred]=20

------=_Part_3129823_2117311198.1757960103961--