Wireshark · Ethereal-dev: RE: [Ethereal-dev] TCP/IP Retransmission

["Scott Emberley" <scotte@xxxxxxxxxxxxxxxxxxxxxx>]

Be careful with sales people - though we all love our own they can make
misleading statements in order to please a customer (or potential
customer).  I have looked at the retransmissions from ethereal and found
that ethereal does not always handle the closing of a TCP connection
properly.  I included a small capture that I made using Observer where I
simply opened up a web page and it shows an 'errant' retransmission flag
when viewed with ethereal.  The problem stems from ethereal not looking
deeply enough into the flags section of TCP, the retransmission is
actually the server resetting the connection (part of formally closing
the TCP connection).  Many TCP services do not close a connection
properly so the reset connection is not always generated - if the TCP
testing on ethereal was done using such a service this could cause it to
be missed in the analyzer. 

Scott Emberley
Senior Software Engineer
Network Instruments

-----Original Message-----
From: ethereal-dev-bounces@xxxxxxxxxxxx
[mailto:ethereal-dev-bounces@xxxxxxxxxxxx] On Behalf Of Chula Bandara
Sent: Tuesday, March 23, 2004 12:42 PM
To: ethereal-dev@xxxxxxxxxxxx; ethereal-users@xxxxxxxxxxxx
Subject: [Ethereal-dev] TCP/IP Retransmission

Thanks for your comments. Keep up your great work.I did not give you the
total description , because first i wanted to know wx there is a obvious
bug. Here is what i did .

i did a port SPAN at two locations (inside and outside) and let the SP
Engineer to monitor from outside while i was monitoring the inside using
ethereal. I noticed retransmission roughly every five minutes . but his
Sniffer did not flag any retransmissions. Then i switched his connection
to inside and i started monitoring outside , i saw the same behaviour.
He was kind enough to give his captured files to me which i analysed
using ethetreal , and i saw retransmission. And i send my analysis to
him , i did not get any favourable answer. Later my boss called Network
Assoicates , They immidiately scheduled a meeting with us eventhough we
were not the NAI customer.
At that point i thought may be i should share it with you guys and get a
reply from you before the meeting. But NAI guys were faster and i had to
stand up to them before i get a reply from you. when i showed my
Analysis , they also suspect a potential bug with their product and took
the case back to their developers.



> Sniffer Pro's Expert System feature is well-known for being faulty and

> misleading. 4.5 DID have quite a few problems "detecting"
> retransmissions properly - particularly if their Sniffer was placed at

> a point where the packet loss would have already occurred (so that the

> trace didn't contain the original segment AND the retransmitted
> segment) it wouldn't flag any retransmissions.
>
> ...Which is one of the dangers of relying on the tool to perform 100% 
> of your analysis, 100% of the time. The tool may not be working (and 
> you may have no idea). Did they do no analysis of their own to see if 
> they could determine if packets were being lost/retransmitted?
> Especially in a case where there is finger-pointing going on, they 
> should be double-checking the results - my guess is that they wouldn't

> know how.
>
> Later versions of Sniffer, up through 4.75SP2 made some improvements 
> in this area, though it still doesn't do a terribly good job.
>
> I'd trust Ethereal on this one, though do some spot-checking to make 
> sure it's not lying to you. Ethereal's TCP Analysis feature is very 
> very good, but not perfect - it does occasionally (rarely) provide 
> false positives or mis-diagnoses.
>
> Use this technique to prove to them - try to arrange to have captures 
> taken simultaneously on both sides of the link that you suspect is 
> faulty. Find a retransmission event, and figure out what happened - 
> was the packet actually "lost" on the link? If so, you should be able 
> to find the original copy of a retransmitted segment sent out to the 
> SP's link AS WELL as the retransmitted segment (and in such a trace 
> even Sniffer *should* find the retransmission), but when you look at 
> the trace on the other side of the link, that original segment should 
> be gone. Ask them where the packet went?
>
> Ian
>
> Chula Bandara wrote:
>
> Hi i am using Etereal Version 0.10.0a and this was very useful to me 
> solving connectivity issues with our Service Providers. Few days back 
> i had a similar problem that i see TCP retransmission but one of my 
> Service Provider did not those retransmissions. My SP was using 
> Network Associates Sniffer Pro Version 4.50.04. and i got some of 
> captured files from the Sniffer. Surprisingly when i open those files 
> with Ethereal , it sees Retransmissions , Packet Losses , Duplicate 
> ACks etc..
>
>could this be a bug in Ethereal or the Sniffer thanks you in advance.
>cbandara
>

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

____________________________
This email has been scanned.

Attachment: RetransError.enc
Description: RetransError.enc