invalid csum error, server stops about cyw43439 HOT 9 CLOSED

I have a pcap file captured on the client side I'll attach.

from cyw43439.

test.zip

from cyw43439.

So it seems like packet number 3651 is the problematic packet. Will add a test later this week and see if I catch anything. Leaving the packet here as a hexdump:

0000   28 cd c1 01 13 7c 88 ae dd 0a 70 92 08 00 45 00
0010   00 2d b0 3a 40 00 40 06 75 59 0a 00 00 be 0a 00
0020   00 7a c7 ce 04 d2 2a 67 58 17 00 00 0d 53 50 18
0030   fa 4b ff ff 00 00 68 65 6c 6c 6f

from cyw43439.

I've added a failing test for this in seqs: https://github.com/soypat/seqs/blob/42f969a224f4707ac986bc4882fac74509a7f0fb/stacks/stacks_test.go#L366

from cyw43439.

@scottfeldman It seems like the mistake is on the client's side, not seqs according to all online packet analyzers I've tried and wireshark.

from cyw43439.

I don't think the client is making a mistake. Wireshark can't see the final csum because the tcp csum is offloaded to the hw NIC on the client side at 10.0.0.190.

sfeldma@nuc:~$ ip a show dev eno1
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 88:ae:dd:0a:70:92 brd ff:ff:ff:ff:ff:ff
    altname enp2s0
    inet 10.0.0.190/24 brd 10.0.0.255 scope global dynamic noprefixroute eno1
       valid_lft 4578sec preferred_lft 4578sec
    inet6 fe80::59c6:7ccb:127b:5b75/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
sfeldma@nuc:~$ sudo ethtool -k eno1 | head -n20
Features for eno1:
rx-checksumming: on
tx-checksumming: on
        tx-checksum-ipv4: on                         <<<<<<<<<<<<<<<<< right here
        tx-checksum-ip-generic: off [fixed]
        tx-checksum-ipv6: on
        tx-checksum-fcoe-crc: off [fixed]
        tx-checksum-sctp: off [fixed]
scatter-gather: off
        tx-scatter-gather: off
        tx-scatter-gather-fraglist: off [fixed]
tcp-segmentation-offload: off
        tx-tcp-segmentation: off
        tx-tcp-ecn-segmentation: off [fixed]
        tx-tcp-mangleid-segmentation: off
        tx-tcp6-segmentation: off
generic-segmentation-offload: off [requested on]
generic-receive-offload: on
large-receive-offload: off [fixed]
rx-vlan-offload: on

from cyw43439.

OK, so taking a closer look the first TCP checksum error occurs at timestamp=10:31.560Z, which occurs 10 minutes 24 seconds after the DHCP exchange (624s) which corresponds to wireshark timestamp 624-20=604s- there's not much happening at that point- connection proceeds normally up to the 644s wireshark timestamp, where the client's messages stop being acknowledged by the server.

Interestingly, up to this point all previous checksums are correct as marked by Wireshark- which seems to indicate the TCP checksum is not being offloaded. The packet which fails to be acked by the seqs server has the checksum=0xffff. Wireshark tells us that the correct checksum is 0.

I've added a test for this package in seqs which does yield the correct checksum.

If the issue is seqs for the program above then it would seem I'm looking at an incorrect packet in the stream- but I can't seem to find any other anomaly in between packets other than the mentioned packet.

also, tx-checksum-ipv4: on sounds like it may pertain to the IP header checksum, not the TCP checksum.

from cyw43439.

Oh, interesting. I'm not sure what's going on then.

Let's keep this one open for awhile in case it pops up again.

from cyw43439.

Final period for comments before closing!

from cyw43439.