[Chula Bandara <cbandara@xxxxxxxxxxxxxxx>]

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