The out-of-order packet is the original packet, while the retransmission is a replacement for the original which had been lost somewhere somehow. Both are packets that arrive later at the receiving node than they were expected to. The difference between a packet being a retransmission or an out-of-order arrival is not really that big. Everything else is the same – apart from the (annoying) transport name resolution feature now being disabled by default (yay!) – so what did happen between 1.10 and 1.12? Retransmission vs. This time, the same packet is flagged as “TCP Out-of-Order”. Now lets open the same trace in Wireshark 1.12.0: Let’s take a look at a trace, first in Wireshark 1.10.9:Īs you can see, Wireshark flags packet 570 as a TCP Retransmission. Unfortunately, there are changes in Wireshark 1.12 regarding the TCP expert that are not listed in the release notes. By the way, if you ever have the chance to join us at Sharkfest, you might find yourself in a session where the “Read the Release Notes” inside joke comes up again – usually when Hansang and myself are in the room 🙂 TCP Expert changes Since that day I always read the release notes. To allow displaying delta times between packets visible after filtering, a new value was added: “delta time displayed”. Which means that if you apply a filter, my delta time column would show delta times to now invisible packets. In there it was mentioned that the “delta time” value was no longer showing the time between displayed packets, but between captured packets. It turned out that the unexpected behavior wasn’t a bug – the Google search results guided me to the release notes of Wireshark 0.99.6. When I open bug reports I always try to check if there is already a report for my issue, and in this case I even googled for the problem. So I was about to open a bug report, annoyed that the new version would introduce a bug like that. I had used the trace for so many trainings that I was sure what Wireshark should have displayed, but it didn’t.
They were slightly different from what I expected, and I knew they were just wrong. It happened to me during a Wireshark class a couple of years ago (using the then brand new version 0.99.6) that suddenly my delta time column showed strange values when I applied a filter.
The reason for reading the release notes is simple: sometimes, things that you were used to behave in a certain way may have been changed by the developers. Okay, before I get to the TCP expert thing, let’s see why release notes are important. The second thing to do should be to read the release notes.Nobody seems to do it, but everybody should. Wireshark 1.12 has just arrived, and of course the first thing to do is to download and install the new version.
0 kommentar(er)
