Re: IPv6 networking problems in 14.3

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

commit ffd956a3918cd5e64c8850eb77247428a29f7221
Author: Michael Tuexen <tuexen@FreeBSD.org>
Date:   Wed Sep 10 17:13:35 2025 +0200

     dhclient: improve UDP checksum handling

     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.*

This could potentially apply to other bpf-using things -- which includes 
dhcpcd.  And you have tso/lro turned on.

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:
>>> 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.)
>> In my case it’s 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.
>>
>> vlan0: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
>>          options=4600703<RXCSUM,TXCSUM,TSO4,TSO6,LRO,RXCSUM_IPV6,TXCSUM_IPV6,MEXTPG>
>>          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=1<PERFORMNUD>
>>
>> ix0: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
>> 	options=4e53fbb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,WOL_UCAST,WOL_MCAST,WOL_MAGIC,VLAN_HWFILTER,VLAN_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6,HWSTATS,MEXTPG>
>>          ether a4:53:0e:79:b9:82
>>          media: Ethernet autoselect (1000baseT <full-duplex>)
>>          status: active
>>          nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
>>
> 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.
>
>
> -- 
> Karl Denninger
> karl@denninger.net
> /The Market Ticker/
> /[S/MIME encrypted email preferred]/
-- 
Karl Denninger
karl@denninger.net
/The Market Ticker/
/[S/MIME encrypted email preferred]/