Hi. I'm working on a program that uses sendfile() to copy a file to a TCP
socket. I did some testing where the server and client processes were on
the same machine. While watching ethereal's packet dumps, I noticed the
packets that sendfile() creates are reported to have incorrect checksums.
Other packets from the same program (ie created by write() or writev() )
have the correct checksum.
I tried another program that doesn't use sendfile(), but write() from a
mmap()'ed file. The checksums are reported to be correct for that
program's packets.
I also tried executing my program across a LAN with only an ethernet
switch between the two machines. The checksums were reported correct for
this situation as well.
This leads me to the conclusion that using sendfile() on a loopback
interface over a TCP connection generates packets with incorrect checksums
in the TCP headers.
I do not know if ethereal is falsely reporting that the checksums are
incorrect, but it's a very limited scope of the source of packets with
incorrect checksums (only sendfile-generated to loopback).
Is this something that even needs to be addressed, since the receiver
would discard the packet if the checksum is incorrect, but since it's over
loopback, there's no chance of receiving data corrupted by the transport
medium and loopback ignores the checksum?
System information: 2.4.20 on both machines, ia32 CPUs, ethereal 0.9.10
with libpcap 0.7.
Please reply directly, as I am not subscribed to the list. Thanks.
Rob Ekl <[email protected]> writes:
> Is this something that even needs to be addressed, since the receiver
> would discard the packet if the checksum is incorrect, but since it's over
> loopback, there's no chance of receiving data corrupted by the transport
> medium and loopback ignores the checksum?
This is an intentional optimization. Loopback doesn't need checksums,
so it doesn't generate or check them.
-Andi
On Thu, Mar 13, 2003 at 03:32:58PM -0600, Rob Ekl wrote:
> Hi. I'm working on a program that uses sendfile() to copy a file to a TCP
> socket. I did some testing where the server and client processes were on
> the same machine. While watching ethereal's packet dumps, I noticed the
> packets that sendfile() creates are reported to have incorrect checksums.
> Other packets from the same program (ie created by write() or writev() )
> have the correct checksum.
copy(-and-checksum) is needed for write*(), and during copying,
the checksumming can be thrown in essentially for free.
For sendfile(), the system does not need to do such copying,
and these days devices can be reported as capable to handle
e.g. tcp checksumming built in.
Loopback device does not bother with checksums -- it is coming
from within the box, no point in checking such things.
( see: drivers/net/loopback.c -- there are most curious set
of initialized dev->features flags. )
...
> This leads me to the conclusion that using sendfile() on a loopback
> interface over a TCP connection generates packets with incorrect checksums
> in the TCP headers.
>
> I do not know if ethereal is falsely reporting that the checksums are
> incorrect, but it's a very limited scope of the source of packets with
> incorrect checksums (only sendfile-generated to loopback).
It may well be correct report, but to calculate those would be
wasted effort.
> Is this something that even needs to be addressed, since the receiver
> would discard the packet if the checksum is incorrect, but since it's over
> loopback, there's no chance of receiving data corrupted by the transport
> medium and loopback ignores the checksum?
Quite so.
> System information: 2.4.20 on both machines, ia32 CPUs, ethereal 0.9.10
> with libpcap 0.7.
/Matti Aarnio