Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 15 Sep 2025 19:00:23 +0200
From:      Michael Tuexen <tuexen@FreeBSD.org>
To:        Karl Denninger <karl@denninger.net>
Cc:        freebsd-net@freebsd.org
Subject:   Re: IPv6 networking problems in 14.3
Message-ID:  <75B331C2-856A-4977-ADCD-D7FA6854AA03@FreeBSD.org>
In-Reply-To: <092f8b7a-9b98-4e2a-b6c5-361b40549cce@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>

next in thread | previous in thread | raw e-mail | index | archive | help
> On 15. Sep 2025, at 14:59, Karl Denninger <karl@denninger.net> wrote:
>=20
> Hmmmmm.... just came in via git pull:
> commit ffd956a3918cd5e64c8850eb77247428a29f7221
> Author: Michael Tuexen <tuexen@FreeBSD.org>
> 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 <karl@denninger.net> =
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<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric =
0 mtu 1500
>>> =
options=3D4600703<RXCSUM,TXCSUM,TSO4,TSO6,LRO,RXCSUM_IPV6,TXCSUM_IPV6,MEXT=
PG>
>>> 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 <full-duplex>)
>>> status: active
>>> nd6 options=3D1<PERFORMNUD>
>>>=20
>>> ix0: flags=3D1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> =
metric 0 mtu 1500
>>> =
options=3D4e53fbb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWC=
SUM,TSO4,TSO6,LRO,WOL_UCAST,WOL_MCAST,WOL_MAGIC,VLAN_HWFILTER,VLAN_HWTSO,R=
XCSUM_IPV6,TXCSUM_IPV6,HWSTATS,MEXTPG>
>>> ether a4:53:0e:79:b9:82
>>> media: Ethernet autoselect (1000baseT <full-duplex>)
>>> status: active
>>> nd6 options=3D29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
>>>=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]




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?75B331C2-856A-4977-ADCD-D7FA6854AA03>