 | 1 | initial version |
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?
