Hi
I found article regarding this topic.
It is not very useful to know how to solve the problem
but "puts a led on" -- the problem exists and is not easy
to be solved and even to be investigated.
Any way, it was very interesting reading.
http://www.acm.org/sigcomm/sigcomm2000/conf/abstract/9-1.htm
toly
-----Original Message-----
From: Priscilla Oppenheimer [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, August 22, 2001 10:28 PM
To: [EMAIL PROTECTED]
Subject: RE: incorrect TCP checksum [7:16776]
What is reporting the TCP checksum error? I'm just wondering. Is it an OS
error report?
It is probably either the sender or the receiver causing the problem as far
as I can tell. Routers shouldn't have any effect. They don't change or
check the TCP checksum, under normal circumstances.
There is one other thing to consider, which is NAT. The TCP checksum is
based on the TCP header and data as well as the "pseudo header." The pseudo
header grabs data from the IP layer, including the source and destination
addresses. If these fields are getting changed by NAT and the TCP checksum
isn't recalculated or is recalculated incorrectly, you could have a problem.
Regarding whether a protocol analyzer captures bad packets, it depends on
the driver. Most drivers trash frames with a bad data-link-layer CRC. You
need a special driver to capture these with an analyzer. I don't the answer
for your particular situation.
Good luck. This is a difficult problem. Please let us know what you find
out! Thanks.
Priscilla
At 03:55 PM 8/22/01, Anatoly Shein wrote:
>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
________________________
Priscilla Oppenheimer
http://www.priscilla.com
Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=19164&t=16776
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
