From nobody Mon Sep 15 17:28:51 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 4cQX815KKFz67g40 for ; Mon, 15 Sep 2025 17:29:05 +0000 (UTC) (envelope-from michael.tuexen@lurchi.franken.de) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.franken.de", Issuer "Certum Domain Validation CA SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cQX811t4Yz3tC7 for ; Mon, 15 Sep 2025 17:29:05 +0000 (UTC) (envelope-from michael.tuexen@lurchi.franken.de) Authentication-Results: mx1.freebsd.org; none Received: from smtpclient.apple (unknown [IPv6:2a02:8109:1101:be00:a17f:b5da:da9c:c18a]) (Authenticated sender: lurchi) by drew.franken.de (Postfix) with ESMTPSA id 31B1D721E281C; Mon, 15 Sep 2025 19:28:52 +0200 (CEST) Content-Type: text/plain; charset=us-ascii 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 (Mac OS X Mail 16.0 \(3826.700.81\)) Subject: Re: IPv6 networking problems in 14.3 From: Michael Tuexen In-Reply-To: Date: Mon, 15 Sep 2025 19:28:51 +0200 Cc: freebsd-net@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <85063FCE-0FCE-4E4D-B03D-2B67FCCC21B7@lurchi.franken.de> 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> <75B331C2-856A-4977-ADCD-D7FA6854AA03@FreeBSD.org> To: Karl Denninger X-Mailer: Apple Mail (2.3826.700.81) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=disabled version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail-n.franken.de X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:680, ipnet:193.174.0.0/15, country:DE] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4cQX811t4Yz3tC7 > On 15. Sep 2025, at 19:16, Karl Denninger wrote: >=20 > On 9/15/2025 13:00, Michael Tuexen wrote: >>> On 15. Sep 2025, at 14:59, Karl Denninger = wrote: >>>=20 >>> Hmmmmm.... just came in via git pull: >>> commit ffd956a3918cd5e64c8850eb77247428a29f7221 >>> Author: Michael Tuexen >>> Date: Wed Sep 10 17:13:35 2025 +0200 >>>=20 >>> dhclient: improve UDP checksum handling >>>=20 >>> When sending UDP packets: >>> * compute the checksum in the correct order. This only has an impact >>> if the length of the payload is odd. >>> * don't send packet with a checksum of zero, use 0xffff instead as >>> required. >>> When receiving UDP packets: >>> * don't do any computations when the checksum is zero. >>> * compute the checksum in the correct order. This only has an impact >>> if the length of the payload is odd. >>> * when computing the checksum, store the pseudo header checksum >>> * if the checksum is computed as zero, use 0xffff instead. >>> * also accept packets, when the checksum in the packet is the pseudo >>> header checksum. >>> The last point fixes a problem when the DHCP client runs in a VM, >>> the DHCP server runs on the host serving the VM and the network >>> interface supports transmit checksum offloading. Since dhclient >>> doesn't use UDP sockets but bpf devices to read the packets, the >>> checksum will be incorrect and only contain the checksum of the >>> pseudo header. >>>=20 >>> This could potentially apply to other bpf-using things -- which = includes dhcpcd. And you have tso/lro turned on. >>>=20 >> Hi Karl, >>=20 >> this is true. Do we have an dhcpd in-tree? Or are you aware of other = in-tree >> programs which use UDP via bpf and not via the socket interface? >>=20 >> Best regards >> Michael > dhclient uses it in base but dhcp6c is, I believe, out of = packages/ports (as is dhcpcd which replaces both dhclient and dhcp6c in = terms of functionality.) OK. But this is not something I can easily investigate and possibly fix, = since that software is not in the tree I can make changes to. I think fixes to = ports should go upstream. Best regards Michael > One of dhcp6c or dhcpcd is necessary to get a delegation from an ISP; = you can get a SLACC address without either simply by enabling it such = as: > ifconfig_mce0_ipv6=3D"inet6 accept_rtadv" > rtsold_enable=3D"YES" > That is sufficient on a client machine if your gateway hands out = addresses based on SLACC, but the gateway then has to get the upstream = delegation (and run rtadvd in order to send the routing data out on the = local side so your SLACC client can pick it up) so unless you have that = delegation hard-coded in your edge device on the outside interface one = of the above has to be running on the gateway, presuming its a FreeBSD = gateway of course. > --=20 > Karl Denninger > karl@denninger.net > The Market Ticker > [S/MIME encrypted email preferred]