On Mon, Oct 14, 2002 at 04:10:21PM +0100, Davidson, Stuart wrote:
> The checksum on the wire is actually correct but ethereal is reporting
> it incorrect on the outgoing side?
If Ethereal (or any other sniffing program that checks TCP checksums,
e.g. tcpdump) is run on a network interface where the interface
generates the TCP checksum and on an OS that uses that feature (and thus
doesn't bother generating the checksum itself), and where the interface
doesn't see its own packets and thus outgoing packets are seen by
sniffers as handed to the interface rather than as put onto the wire
(which is the case for most if not all Ethernet interfaces), the sniffer
will report incorrect TCP checksums but the checksum on the wire will be
correct.
I.e., what he described is exactly what you'd see in that case (and what
I've seen on Solaris gigabit interfaces); that's why there's an option
to disable TCP checksum checking in Ethereal.
> But...
>
> On the incoming side ethereal reports the checksum incorrect until the
> last frame which it reports with correct checksum.
>
> The correct checksum on only the last packet on the incoming side and
> the immediate resumption of the tcp dialog lead me to think that the
> preceeding packets really do have incorrect checksums.
>
> However, I can not reconcile this with the last frame reported with
> incorrect checksum outgoing and correct checksum incoming.
Why not? Are you incorrectly assuming that there's only one possible
reason for an incorrect TCP checksum to be reported by Ethereal, whether
it's "the checksum really is bad" or "Ethereal is being handed the
packet before the checksum field in the TCP header is set"?
You can get, in a single capture, packets that have bad TCP checksums
for *both* reasons.
The last of the frame with a bad checksum in the server capture appears
to have been sent from the server to the client; if the network
interface on the server is doing TCP checksum offloading, that would
explain why the capture on the servers shows frame 18830 with an
incorrect checksum (as the frame was handed to Ethereal by the host OS
before the checksum field was set in the TCP header). The checksum
would be correct in the capture on the other machine because that packet
was captured from the wire, and the packet was presumably put on the
wire with the correct TCP checksum.
In the client capture, the frames with incorrect TCP checksums are
frames 17910 through 17917. Those are all the same TCP segment, so, in
that case, the checksum may really have been bad, for some reason. They
are all transmitted from the server to the client, so presumably that
means a bad checksum reported by Ethereal truly is a bad checksum. Why
that was happening I don't know.
Those frames also have incorrect TCP checksums in the server capture -
but if checksum offloading is being done on the interface, that'd be
expected.
As frame 18830 also has an incorrect checksum in the server capture, but
corresponds to frame 17918 in the client capture, which is a frame with
a *correct* TCP checksum, that suggests that offloading is being done
*but* being done incorrectly for some but *not* all packets, or that
it's being done correctly but that the packet is being trashed in flight
in some cases.
I.e., in the server capture, if offloading is being done, *no* packets
sent from the server to the client will have valid TCP checksums (except
by sheer luck, i.e. if whatever is in the TCP checksum field before the
packet is handed to the network interface happens to be correct, the
checksum will happen to be OK), regardless of whether the packet went
onto the wire with a valid checksum or not.
In the client capture, packets that had a valid checksum when received
by the machine doing the sniffing will have valid TCP checksums as
reported by Ethereal, and packets that didn't have a valid checksum when
received will not have valid TCP checksums as reported by Ethereal.
