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
