Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Ethereal-users: [Ethereal-users] packet capturing question / TCP checksum errors

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Andreas Fink <andreas@xxxxxxxx>
Date: Fri, 27 Jan 2006 10:05:20 +0100
Hello users,

I'm using ethereal to find the source of a problem I'm having on a ethernet link but I'm getting a very confusing result I am unable to explain.

Situation: HTTP Server ----ethernet switch ------ fiber link ----- ethernet switch ----- HTTP client

The client requests a file from the server and stops working after about 500k. The problem is reproduceable with different clients, with different servers and even with swapped switches. With VLAN tagging or without. With going through a router in addition or not. We really suspect the fiber link (provided by third party including some switching/ratelimiting equipment there) to be the problem but for now this is not really the issue I want to raise here. The problem is that the log I get doesn't make sense.

What I did to spot this issue is I did run "tcpdump -s0 -w logfile" on the server and on the client at the same time while doing the reproduceable problem to capture a file to analyze with ethereal (I could have run ethereal directly with same results but I didnt wanted to have all the X11 remote traffic showing up in the log). What I see in the client's log doesn't make sense to me.

I see a TCP packet going from the client to the server being logged ON THE CLIENT this way:

Transmission Control Protocol, Src Port: 64844 (64844), Dst Port: http (80), Seq: 0, Ack:
 0, Len: 0
Source port: 64844 (64844)
Destination port: http (80)
Sequence number: 0    (relative sequence number)
Header length: 40 bytes
Flags: 0x0002 (SYN)
0... .... = Congestion Window Reduced (CWR): Not set
.0.. .... = ECN-Echo: Not set
..0. .... = Urgent: Not set
...0 .... = Acknowledgment: Not set
.... 0... = Push: Not set
.... .0.. = Reset: Not set
.... ..1. = Syn: Set
.... ...0 = Fin: Not set
Window size: 65535
Checksum: 0x8372 [incorrect, should be 0xbb7c] <<<*******************
Options: (20 bytes)
Maximum segment size: 1460 bytes
NOP
Window scale: 0 (multiply by 1)
NOP
NOP
Time stamp: tsval 817701289, tsecr 0


On the SERVER the following is logged for that packet:

Transmission Control Protocol, Src Port: 64844 (64844), Dst Port: http (80), Seq: 0, Ack:
 0, Len: 0
Source port: 64844 (64844)
Destination port: http (80)
Sequence number: 0    (relative sequence number)
Header length: 40 bytes
Flags: 0x0002 (SYN)
0... .... = Congestion Window Reduced (CWR): Not set
.0.. .... = ECN-Echo: Not set
..0. .... = Urgent: Not set
...0 .... = Acknowledgment: Not set
.... 0... = Push: Not set
.... .0.. = Reset: Not set
.... ..1. = Syn: Set
.... ...0 = Fin: Not set
Window size: 65535
Checksum: 0xbb7c [correct] <<<*******************
Options: (20 bytes)
Maximum segment size: 1460 bytes
NOP
Window scale: 0 (multiply by 1)
NOP
NOP
Time stamp: tsval 817701289, tsecr 0


So as you can see, the CLIENT is saying its sending out a packet with an invalid checksum but the server tells us it has received it with the correct checksum. How can this be? Do we have a freaky client and a autocorrecting device in the middle? Both items where on the same subnet. The client is running "wget" and the server is an apache webserver. Both machines run since a long time unmodified and only have this problem since 2 weeks (since the fiber operator did some ugprade to their infrastructure). I can guess there are errors on the link to some extent (but no ethernet CRC errors ever) but why would the client log something into the dump file which is not what it is really sending out?

Does that make sense to anyone?


Andreas Fink
Fink Consulting GmbH

---------------------------------------------------------------
Tel: +41-61-6666332 Fax: +41-61-6666331  Mobile: +41-79-2457333
Address: Clarastrasse 3, 4058 Basel, Switzerland
E-Mail:  afink@xxxxxxxxxxxxxxxxxx
Homepage: http://www.finkconsulting.com
---------------------------------------------------------------

ICQ: 101946485 MSN: msn1@xxxxxx AIM: smsrelay Skype: andreasfink
Yahoo: finkconsulting SMS: +41792457333
PGP9: 0714 DF2B A189 A760 6201  5CBD D040 3E71 4DAF 68BB