>
> A user has reported a problem with GPLPV with large packets, having looked
> at a tcpdump I can see that a large packet (10k) is being sent, but the
> resulting packets received at the other end have incorrect TCP checksums.
> The checksums of the received packets are all different to each other, so
> something is making an attempt to calculate a checksum, which I assume is
> the hardware. In theory, the windows
>
> It all works fine on my systems - I get line speed on gigabit hardware with
no
> bad checksums, so I can''t think what is going on, unless the way
windows
> calculates the pseudoheader checksum isn''t compatible with what
Linux
> wants...
>
I just noticed the checksums for the generated packets are all out by exactly
10240, which is the total IP payload size (TCP header + TCP payload):
Total frame size: 10274 bytes
Ethernet header length: 14 bytes
IP header length: 20 bytes
TCP header length: 20 bytes
TCP data length: 10220 bytes
The MS literature on the "TCP Length" component for the psuedoheader
for an LSO packet says:
(http://msdn.microsoft.com/en-us/library/windows/hardware/ff568840%28v=vs.85%29.aspx)
Note that RFC 793 stipulates that the pseudo-header checksum is calculated over
the Source IP Address, Destination IP Address, Protocol, and TCP Length. (The
TCP Length is the length of the TCP header plus the length of the TCP payload.
The TCP Length does not include the length of the pseudo-header.) However,
because the underlying miniport driver and NIC generate TCP segments from the
large packet that is passed down by the TCP/IP transport, the transport does not
know the size of the TCP payload for each TCP segment and therefore cannot
include the TCP Length in the pseudo-header. Instead, as described below, the
NIC extends the pseudo-header checksum that was supplied by the TCP/IP transport
to cover the TCP Length of each generated TCP segment.
I don''t know where to go next though.
Thanks
James