Hi
Thank you for full answer.
Actually it is not academic question.
I found this in many sites and it looks to be similar problem.
My interest is this specific problem, because despite of the other kind of
retransmissions
I can't be sure in the reason of wrong TCP checksum. Also the problem is
that if frame was damaged,
as you said, CRC will found it and will not pass the frame to the next hop.
the problem with TCP is that I'm not sure that even routers checks TCP check
sum
It heard reasonable that they just fix the TCP check sum according to
incremental recalculation.
probably you know is it true and for what kind of devices.
Actually my goal is find a couple of questions that could point to the fault
machine,
i.e. bound the range of the suspect devices by simple analyzing.
Something like it couldn't be my firewall because I have Cisco switch
between that checks TCP checksum and not
just recalculate it.
Also I have additional question according to your answer.
Is damaged frame with inappropriate CRC heard by sniffer implemented on
Solaris DLPI or device driver throw it ?
In the other words should I see damaged frames using regular snoop ?
Just before several minutes I found bug in Win 2000 ( it is not sounds
strange :-) )
"Host May Send Packet with an Incorrect TCP Checksum"
http://support.microsoft.com/support/kb/articles/Q271/7/08.ASP
according to their problem description it happens in TIME_WAIT TCP state.
Actually it is not a problem because if TCP in TIME_WATE all data was
successfully sent
But a most of "my TCP wrong packets" are in the middle of the link.
In HTTP traffic there is several in the frame contains request line
but there is a part in the middle of the data transfer - a simple ACK from
client
Thank you in advance
toly
-----Original Message-----
From: Priscilla Oppenheimer [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, August 22, 2001 7:45 PM
To: [EMAIL PROTECTED]
Subject: Re: incorrect TCP checksum [7:16776]
Is this an academic question or are you actually seeing TCP checksum
errors? I have never seen a TCP checksum error, so I wondered. Well, I have
seen them when people change the data in Sniffer traces without
recalculating the checksum, but that's not "real world."
In answer to your question, TCP checksum errors would have to be a software
bug, or possibly firmware bug if TCP were implemented in firmware.
If the frame gets damaged in transit, it gets trashed by the recipient
because the data-link-layer CRC isn't right. If the routing process or IP
implementation trashes the frame, then the IP checksum won't be right and
TCP trashes the frame.
If the frame gets all the way to TCP and ends up with a checksum error,
then software at the TCP layer damaged it.
I think your real question might be what is causing TCP retransmissions?
TCP transmissions can result from errors at any layer that caused a frame
or an acknowledgement to not reach the intended recipient. TCP
retransmissions are much more likely to result from the following potential
errors than from a TCP checksum error:
Frames getting damaged in transit and getting trashed
Issue a show int and check reliability and CRC error rates
If Ethernet, check for excessive collisions, duplex mismatch
problems
Routers or switches dropping frames due to buffer overflows
Issue a show int and check for dropped frames
Issue a show buffer and check for problems
Frames getting dropped by service provider
If frame relay, check that you aren't going above your CIR
There's probably a bunch of other reasons. I recommend the various Cisco
Internetwork Troubleshooting books. The Cisco Press one is very good.
One other thought: a few retransmissions are normal. You might want to
check the percentage. I hesitate to give a threshold, but if it's just a
few percent of your frames getting retransmitted, don't worry about it. Are
users noticing a problem? That's the bottom line.
Priscilla
At 03:30 AM 8/22/01, Anatoly Shein wrote:
>Hi
>According to my knowledge incorrect TCP check sum cause to TCP
>retransmissions.
>What could be reason for incorrect TCP checksum?
>As I understand it could be problem in one of the router/proxy probably
>switch.
>And intuitively I think that problem should be wherever in OS.
>Can you give me any suggestion about detection of the fault machine or
>source to find more info about this problem.
>
>Suggestions I mean something more constructive than putting sniffers on
each
>leg of the device and look for TCP checksum errors.
________________________
Priscilla Oppenheimer
http://www.priscilla.com
Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=16883&t=16776
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
