Lots (but not all) of TCP CHECKSUM INCORRECT on Windows

asked 2025-03-28 01:47:05 +0000

mjs
3 ●2

I'm using a Windows PC as a TCP client to debug a TCP server. The server could be problematic even in the TCP checksum calculation. Wireshark on the PC does the traffic capture.

In the Wireshark capture, 192.168.1.9 is the TCP server, and 192.168.1.20 is the Windows PC as a TCP client. Lots of TCP segments sent by the TCP client are marked as TCP CHECKSUM INCORRECT (can be shown by tcp.checksum_bad.expert). I've read https://wiki.wireshark.org/TCP_Checksum_Verification and learned of offloading. I don't think the TCP CHECKSUM INCORRECT is caused by offloading because there are also lots of TCP segments that are marked as Checksum: 0xXXXX [correct] (matches paritial checksum ...), which is more likely the result of offloading. I don't think Windows' TCP stack is problematic since the PC browser works fine. Why are there so many TCP CHECKSUM INCORRECT from PC? Thanks very much!

capture file

Comments

Can you make a capture on the server?
The packets marked with bad checksum all have a length of 2102 which means they are split (and checksum calculated) before they go on the wire.

Chuckc ( 2025-03-28 03:05:06 +0000 )edit

Sorry I can't. The server is an embedded device.

mjs ( 2025-03-28 04:38:21 +0000 )edit

Can you capture on the wire, rather than the PC? Then you really see what these packets look like.

Jaap ( 2025-03-28 06:29:37 +0000 )edit

Windows PC as a TCP client
Can you adjust the client to send smaller data chunks? (currently 2048)

Chuckc ( 2025-03-28 13:25:28 +0000 )edit

Another option is to temporary disable TCP checksum offload and LSO offload in the NIC driver via: Device Manager / Network / Ethernet Controller properties / Advanced tab.

André ( 2025-03-28 19:20:37 +0000 )edit

see more comments

answered 2025-03-31 18:07:39 +0000

SYN-bit

18585 ●9 ●353 ●255 https://SYN-b.it

It looks like all checksum error messages are indeed caused by checksum offloading.The partial checksum calculation is dependent on the TCP segment length, but all messages having a bad checksum (and thus an invalid partial checksum) are TCP segments that need to be split up at the NIC as they are too large to be sent in 1 IP packet (over ethernet). It seems the partial checksum check is not equipped to deal with segments that will be segmented on the NIC.

Troubleshooting checksum behavior and/or errors on a host itself is not the way to go, as you don't see the real packets as they are on the network. Get yourself a TAP to see the real packets between the Windows client and the embedded device. If that is not an option, please disable all offloading features of the NIC while doing your tests.

I noticed the 400 bad request response on the last chunk. It seems all chunks are 2048 bytes long and the last chunk is 2050 bytes long, including two bytes that seem to be used as a checksum at the application layer. The two bytes are a6 b4 and the HTTP response included a message Wrong crc 5990!=b4a6. So it seems the checksum at the application layer is incorrect and causing a failure. If there were any TCP checksum errors, the data would not have been forwarded to the application. So all-in-all, I think there are no checksum errors at the TCP layer, only at the application layer.

Are you sure your application layer checksum calculation on the client is correct?

edit flag offensive delete link

Comments

Another thing I noticed is that the embedded device is sending a window size of 2048 bytes max. The client is sending http chunks of 2048 bytes, but these are of course prepended with the http header, which makes each POST send more data than the embedded device can receive in one TCP buffer. If the size of the chunks is chosen because of the size of the TCP buffer on the embedded device, It probably will help to send objects of 1024 bytes instead of 2048 bytes.

SYN-bit ( 2025-03-31 18:24:32 +0000 )edit

Based on the Microsoft documentation here regarding Large Send Offload and its partial checksum calculation, I tested doing the partial calculation with the reported length zero; it measures as a partial checksum for all the maximum segment size packets.

We could, I suppose, add that as another possible result. (Linux doesn't do it this way; instead, the large packet length is still used in the partial checksum, and the drivers back it out,)

johnthacker ( 2025-04-03 01:01:58 +0000 )edit

add a comment

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Lots (but not all) of TCP CHECKSUM INCORRECT on Windows

Comments

1 Answer

Comments

Your Answer

Question Tools

Stats

Related questions

Lots (but not all) of TCP CHECKSUM INCORRECT on Windows edit

Comments

1 Answer

Comments

Your Answer

Question Tools

Stats

Related questions

Lots (but not all) of TCP CHECKSUM INCORRECT on Windows