Port Numbers reused

Sharkfest 2015 is coming up fast (22 days, 12 hours to go when typing this), and so I spend the morning hours of my Saturday for preparation of materials for my three talks. Since that also involves adding features and fixing bugs in TraceWrangler (which I also need for the large demo part of my FIRST presentation the week before Sharkfest) it is a slow process. So let’s waste a little additional time on a blog post 🙂

Wireshark 1.99

Not sure if you have seen it yet, but the Wireshark we have all been using every day (hm, maybe not all of us, but still) is going to be replaced with a completely new GUI version soon. The new version is going to leverage QT instead of GTK, and from the reactions of the Mac OSX users it’s a step in the right direction. At which point I have to add that it is also possible to make the GTK version look beautiful on MAC OSX too, if you want – take a look at Bálints blog post.

The one reason I could not start to use the new developer builds of the QT version was that it was missing a feature I use more than any other: the TCP conversation filter pop up menu option. What it does is to create and apply a socket display filter, adding both source and destination address and port without having to type anything. This is a real important filter because most analysis tasks require to look at isolated conversations. I sometimes teased the core developers about it (sorry, guys 😉 ), because Gerald often says that he uses 1.99 on day-to-day basis for a long time now. And I can’t say the same because of the conversation filter feature missing.

Well, this is what happened yesterday:

So today, I downloaded the latest portable developer version and checked it out. And Alexis was right (of course) – the conversation filter menu option is included. Yay! – now I can start using the new version! Thanks, Alexis! 🙂

The “Port numbers reused” diagnosis

During my preparation of capture files for Sharkfest I came across the problem of TCP sessions using the same port numbers – meaning, the 5-tuple is exactly the same for multiple conversations:
PortNumberReused
This is something that rarely happens, but if it does it is worth investigating. If the port is reused too soon it may confuse the TCP stacks involved, so you need to look at the delta time between closing the old conversation and starting the new one. It needs to be at least as long as the time the stacks keep the old connection in their tables (TIME_WAIT comes into play here unless a Reset packet terminates the session).

In my case, I knew already why the port reuse happened and could dismiss it as not being a problem. But it gave me a another thing I had to solve: how do I filter on each of the conversations when they share the same 5-tuple? Obviously, my beloved TCP conversation filter pop up menu option will not help. Instead, this is a case for using the stream index.

The stream index is a number that is incremented with each TCP conversation (UDP has its own stream index now; in really old version they used the same index, but Sake fixed it at some point). To filter on it, simply use e.g. “tcp.stream == 0” for the first TCP conversation.

The stream index has a couple of advantages over the conversation filter:

  1. it can separate multiple conversations on the same port, because Wireshark knows internally that the new connection is also a new stream
  2. you can iterate through it in a tshark script, starting from 0 and counting up to perform tasks on all streams separately
  3. it’s also used for the one thing every Wireshark newbie seem to use exclusively at first: the “Follow TCP stream” option

The single disadvantage it has is that it doesn’t stay the same for the 5-tuple across multiple files. This is due to the stream index starting at zero for the first conversation found in each file, so if you need to find the same conversation in multiple files, you need to use the conversation filter instead.

That’s it for now – back to my talk preparation for me 😉

 

Tags: , ,

Discussions — No responses yet

CAPTCHA

*