["Anders Broman (AL/EAB)" <anders.broman@xxxxxxxxxxxx>]

Hi,
See FAQ http://www.ethereal.com/faq.html#q11.1

Brg
Anders 

-----Original Message-----
From: ethereal-users-bounces@xxxxxxxxxxxx
[mailto:ethereal-users-bounces@xxxxxxxxxxxx] On Behalf Of Andreas Fink
Sent: den 27 januari 2006 10:05
To: ethereal-users@xxxxxxxxxxxx
Subject: [Ethereal-users] packet capturing question / TCP checksum
errors

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


_______________________________________________
Ethereal-users mailing list
Ethereal-users@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-users