Just to be sure... do you mean?
The checksum on the wire is actually correct but ethereal is reporting it incorrect on the outgoing side?
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.
BTW. It's the same version of ethereal used on both sides on the switch, both running on Solaris 8.
Any thoughts?
Stuart
From
-----Original Message-----
From: Richard Urwin [mailto:RUrwin@xxxxxxxxxxxxxx]
Sent: Monday, October 14, 2002 8:47 AM
To: Davidson, Stuart; ethereal-users@xxxxxxxxxxxx
Subject: RE: [Ethereal-users] incorrect tcp checksums
> 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
________________________________________________________________________
