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

[Michael Tuexen <Michael.Tuexen@xxxxxxxxxxxxxxxxx>]

Dear all,

I'm not using W2000 but I would like to bring the following to
your attention.

I'm using Mac OS X and when sniffing ALL TCP checksum of
outgoing packets are wrong. It is because this calculation
is done by the NIC. If I disable this feature, I see also
the outgoing packets with correct checksums. Maybe Windows
does a similiar optimization.

The only way to decide what is really on the wire is to use
a third machine and compare the data to the one from the
sender and the receiver.


Best regards
Michael

On Monday, Oct 14, 2002, at 17:19 Europe/Berlin, Richard Urwin wrote:

> I don't have experience of fragmentation. But I see bad IP and TCP
> checksums on all outgoing packets, which are  immediately ack'd by the
> remote end.
>
> I suggest that you assume that all checksums on all outgoing packets  
> are
> going to be reported wrongly.
>
> (albeit that Mads and myself are both running Win2000, and you are not.
> So you may very well see a somewhat different behavior.)
>
> Alternatively can you run the Sun-Fire Ethereal on a seperate machine?
>
> --  
> 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: 14 October 2002 16:10
> To: Richard Urwin; ethereal-users@xxxxxxxxxxxx
> Subject: RE: [Ethereal-users] incorrect tcp checksums
>
>
> 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
> _______________________________________________________________________ 
> _
>
> _______________________________________________________________________ 
> _
> 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
> _______________________________________________________________________ 
> _
> _______________________________________________
> Ethereal-users mailing list
> Ethereal-users@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-users