Hello All We use a few different packet analysis suites - Wireshark being one of the main ones. One of the biggest problems I have is Wireshark's often incorrect assumption about retransmitted packets. I know that NG and OpNet follow an entire TCP stream before assessing the number of retransmissions - but I'm not sure how WireShark handles it. Another issue we're having right now is a few of our probes are tapped into fiber uplinks - and as of a recent code change the packets aren't always being written onto disk in the correct order (maybe off just a few ms) - and this has thrown WS for a loop. I expected the number of OOS packets to go up, which it did, but the number of suspected retransmissions has gone through the roof. Is there a way to avoid this? asked 29 Sep '10, 10:31  GeonJay |
One Answer:
You can read the code at http://anonsvn.wireshark.org/viewvc/trunk-1.4/epan/dissectors/packet-tcp.c?revision=33861&view=markup (that's the location for verion 1.4.0) - search for: That section explains how the decision to mark a packet as a retransmission/fast_retransmission/out-of-order is made. You could turn off TCP Preferences Analyze Sequence Numbers, but then you'd miss so much interpretation of TCP issues... Hope this helps. answered 29 Sep '10, 16:20  lchappell ♦ |
Hi, you're saying you've "tapped into fiber uplinks" - how exactly do you do that? Are you using a full duplex fiber tap with 2 downlinks that are captured on two separate interfaces and then merged? Or do you use SPAN ports, or even link aggregation taps?
These are full duplex taps. To be honest they're one of my favorite desktop conversation items. I've cracked one open and it's literally a small mirror sitting at what I assume to be a 45 degree angle. We only trust TAPs at our core-to-dist border because of the high throughput (we have 10G bowties). So, two switches and two headend routers meshed gives you 4 connections, each consisting of two fibers for a total of 8 fibers - so we have 8 TAPs that feed a monstrous probe. The probe then aggregates all 8 interfaces into a single virtual interface from which we can grab captures.
I like FDX Taps to, especially the optical ones. I don't like aggregation taps as they sometimes introduce errors either to the production connection or in the connection to the capture device.
Problem with full duplex captures is that sometimes the single interfaces have difficulties "delivering" the packets to the merge process in time and get delayed because the other cards have higher priority or just "better luck" with IRQs etc. Then the merge reorders packets and you have stuff like for example a "200 OK" appearing before the "GET" request is issued. It throws Wireshark off, too.
This is our current problem. We use one of the well known probe manufacturers (rhymes with petsnout). As of the last two code releases we have major issues with aggregate interfaces in high volume network segments writing the packets to the disk out of order AND the AGG interfaces have started dropping segments. This is a code issue for sure - it didn't happen until the last 2 updates. That's the code change I mentioned in my earlier post - those OOO packets are part of our incorrectly reported retrans. Lately we've been unAGGing the interfaces and grabbing individual captures :(
Ouch, that's no fun, but unfortunately I think you'll have to get the code guys to fix things so that the automatic aggregations do work correctly again. There's not much that you can do to avoid OoO packets otherwise, and probably no way to fix things within Wireshark either. It will keep displaying suspected retransmissions messages since it sees a lower sequence number appearing after a higher sequence number in the packet before the current one.