From nobody Mon Sep 15 17:00:23 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 4cQWVx3Z41z67dCC for ; Mon, 15 Sep 2025 17:00:25 +0000 (UTC) (envelope-from tuexen@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cQWVx369tz3nCn; Mon, 15 Sep 2025 17:00:25 +0000 (UTC) (envelope-from tuexen@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1757955625; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=vbRsGeScy+9UE64DKSiaKLIjKKQbSibtHNz4fMSl52Q=; b=BRxRcPsYtTDCv7vP8w8Z5fNG3bQjZ88Oi9re077d/mZhh0JYi8nPiGHryavLoa7szMZCv2 5tdJdaNHETipaNDWBm5yZxJmap3CTbignxoCcD8v0cBv633lZAF3Vskfc+Yff9aIkhL5Zd yVMHN95N3dzj291h4iAaMo/nSnS2gCmqS+U9z8qR1cxJRgmVPQQQgUab+DfyByTqlesArx USlkMpgh4uLPvU5sOsZDJaIEVSqyTflM5VqWGYBDoUKfWShbTPJ6VDfIW+sVUp0QmzSzP2 TQPoWoMb5KnMmGtlkiYOFJJp0811UY6kNFiZc/hRjGwGyQL3peNqq8q7UgKjiw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1757955625; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=vbRsGeScy+9UE64DKSiaKLIjKKQbSibtHNz4fMSl52Q=; b=D/ytpX9AHaz4cKD5BkgsuAWWxwwv0myv29DrGnzngBDtNLLNDQLan7yj6qDH5/DLZF5/MK knAsPft/O/lemjf395NbABcRGI3YCIqmOHbuwh7hlObfJJuDd+dznvz539sZauf++VmSLJ APH4BIcfDErXXfQwiXoc9cFeyck7glpkTx7QiKZ+SImRFYySUC7RASp9qpD89fGM1/giDg cbEuNQq0l+Z8E+mPOSadAAjg2KhUW3Nfj4QLrf0pm+Y0wRgwKjkYCtv8YRXkicg6ATLv5D doUnrQ0kcpE4NAerHs3Si5/I7/1H0M8INisWZWPqo+9hnM2ZoeZMQtHF9dGOOg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1757955625; a=rsa-sha256; cv=none; b=ZzsMkORDTVDE2IGUHrmNDdfxWcYmXEdWuTJf87UW1ueKsjRCUBvCWET0P4iMg3L61XdIQh HFNShoq3UGjzKMozq+DslcRfZI4P3CBSCDdPyvUkXAv2JmdUzMIXPtTOS697g5Mf1hh9Ae OIH90C4xjNPJXDGiT1f0fw1FkA5fbCNcd6z52Dr7mkHA9Nzvb/NPG3JAkr5V8guj3ZRxaB MRNTGbFHL7h9RMDhM+Mn13HWs1VloO0WxCzbV9dbuM1qRNIAZESxtUveDiqc61bZvQaBwO On4eT2l+5pQDgbk5kiQkx58NpSbIACib/VGH+jIVZyrJmiuILWwKMX20S+X4dQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from smtpclient.apple (unknown [IPv6:2a02:8109:1101:be00:a17f:b5da:da9c:c18a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: tuexen) by smtp.freebsd.org (Postfix) with ESMTPSA id 4cQWVx087nz19LS; Mon, 15 Sep 2025 17:00:24 +0000 (UTC) (envelope-from tuexen@FreeBSD.org) Content-Type: text/plain; charset=utf-8 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: <092f8b7a-9b98-4e2a-b6c5-361b40549cce@denninger.net> Date: Mon, 15 Sep 2025 19:00:23 +0200 Cc: freebsd-net@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <75B331C2-856A-4977-ADCD-D7FA6854AA03@FreeBSD.org> 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> To: Karl Denninger X-Mailer: Apple Mail (2.3826.700.81) > 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. Hi Karl, 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? Best regards Michael > It is a patch to dhclient, not dhcpcd but does the same issue = potentially apply? > On 9/14/2025 13:00, Karl Denninger wrote: >> On 9/14/2025 12:38, Chris Ross wrote: >>>=20 >>>> On Sep 14, 2025, at 12:29, Karl Denninger = wrote: >>>> 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.) >>>>=20 >>> In my case it=E2=80=99s an ix. Connected to a 1gbps switch = interface, but an ix interface. And, the same hardware that was doing = this fine a few months ago. >>>=20 >>> vlan0: = flags=3D1008843 metric = 0 mtu 1500 >>> = options=3D4600703 >>> ether a4:53:0e:79:b9:82 >>> inet A.B.C.D netmask 0xffffff00 broadcast A.B.C.255 >>> inet6 fe80::6e8:e675:f359:3465%vlan0 prefixlen 64 scopeid 0x4 >>> groups: vlan >>> vlan: 6 vlanproto: 802.1q vlanpcp: 0 parent interface: ix0 >>> media: Ethernet autoselect (1000baseT ) >>> status: active >>> nd6 options=3D1 >>>=20 >>> ix0: flags=3D1008843 = metric 0 mtu 1500 >>> = options=3D4e53fbb >>> ether a4:53:0e:79:b9:82 >>> media: Ethernet autoselect (1000baseT ) >>> status: active >>> nd6 options=3D29 >>>=20 >>>=20 >> If you find anything a note back here would be greatly excellent. I = do note that per the various notes from long ago I have both tso and lro = turned off (but I use ipfw, which is where that apparently comes from) = on the outside interface -- but I doubt that is involved as I did try = with it on and it didn't change anything. >>=20 >> --=20 >> Karl Denninger >> karl@denninger.net >> The Market Ticker >> [S/MIME encrypted email preferred] > --=20 > Karl Denninger > karl@denninger.net > The Market Ticker > [S/MIME encrypted email preferred]