Wireshark · Ethereal-users: RE: [Ethereal-users] incorrect tcp checksums

[Richard Urwin <RUrwin@xxxxxxxxxxxxxx>]

> 2. how can last frame have incorrect tcp checksum on server VLAN
> but correct tcp checksum on client VLAN?

I have found (W2000sp3) that, when capturing, the out-going checksums
were always incorrect. I assumed this was due to some lower level
software adding the correct checksums after Ethereal has grabbed the
packet.

> 1. why is the tcp checksum for a 1460 byte frame always incorrect?
> 3. any ideas how to debug this further?

Try looking for the upgraded drivers. If the driver is supposed to add
the checksum, maybe it's doing it wrongly.

-- 
Richard Urwin, Software Design Engineer
Schenck Test Automation
Braemar Court, 1311b Melton Road, Syston, UK.
rurwin@xxxxxxxxxxxxx




-----Original Message-----
From: Davidson, Stuart [mailto:Stuart.Davidson@xxxxxx]
Sent: 11 October 2002 18:45
To: ethereal-users@xxxxxxxxxxxx
Subject: [Ethereal-users] incorrect tcp checksums


We are seeing apparent tcp checksum corruption which results in
retransmits and hence slow network performance.

The network configuration is:

Sun-Fire-280R (10.10.2.52)
|
100 M/bit enet
|
Cisco Catalyst 3500 Series XL
|
100 M/bit enet
|
Sun-Blade-100 (10.150.0.108)

The Sun Blade is being jumpstarted from the Sun Fire hence the Sun Fire
is the server and main tranmitter of tcp packets.

To investigate the problem we have ethereal running on the Sun Fire and
on another Sun Blade in the same VLAN as the Sun Blade. Since it's a
switched network a span port is configured from the jumpstart Blade to
the monitor Blade. 

On the server VLAN tcp checksums always appear incorrect e.g. for a 1460
byte packet the value is always 0x1caa.

On the client VLAN any packets with incorrect tcp checksum results in a
retransmit as expected.

The following traces show a retransmit sequence.

- on the server VLAN, frames 18822 - 18830 correspond to frames 17910 -
17918 on client VLAN
- all frames on the server VLAN appear to have incorrect tcp checksums
- note, the last frame 18830 appears to have incorrect tcp checksum on
server VLAN. However, the corresponding frame 17918 on the client VLAN
has the correct tcp checksum

Questions:

1. why is the tcp checksum for a 1460 byte frame always incorrect?
2. how can last frame have incorrect tcp checksum on server VLAN but
correct tcp checksum on client VLAN?
3. any ideas how to debug this further?

Thanks,
	Stuart

Environment: Solaris 5.8, ethereal 0.8.19 compiled GTK+ 1.2.10, Glib
1.2.10, libpcap 0.6, libz 1.1.3, UCD SNMP 4.2.1

Note, although time is not sync'd between the client and server, the
delta time between the packets is the same indicating that frames 18822
- 18830 and 17910 - 17918 do correspond.

 <<js_cli.txt>>  <<js_srv.txt>> 


________________________________________________________________________
This email has been scanned for all viruses by the MessageLabs SkyScan
service. For more information on a proactive anti-virus service working
around the clock, around the globe, visit http://www.messagelabs.com
________________________________________________________________________

________________________________________________________________________
This email has been scanned for all viruses by the MessageLabs SkyScan
service. For more information on a proactive anti-virus service working
around the clock, around the globe, visit http://www.messagelabs.com
________________________________________________________________________