Let’s say you had a full evening to yourself. If you’re a student, you don’t have to study. If you’re a husband you don’t have to do the chores, if you’re a wife with kids then you don’t have to watch them. Why? Because someone you love and trust is taking care of all the details for you.
How would you use this redeemed time? A student might use it to live licentiously. A husband might use it to veg out in front of the computer. And a wife might use her free time to get a massage. But do you know what I would do?
I would use it to play with Wireshark! I love analyzing packets and seeing how things work. But Wireshark is more than an entertainment tool for geeks. You can use it to solve problems like network latency or even use it tighten up network security.
In this guide we’re going deep into the bowels of Wireshark by demystifying dissectors. Just like you used a knife to dissect Kermit the frog in Chemistry class, Wireshark uses special dissectors to decode captured protocols.
Diligent Dissectors
Wireshark dissectors are the workhorses that make Wireshark useful. They decode the information at each layer of the TCP/IP model. For example, the Ethernet dissector shows you all the frame details and the Network layer dissector shows you everything you could possibly want to know about packets.
If you’ve been using Wireshark this far then you’ve already been using dissectors. (you just didn’t realize it was called that)
For example, the network layers in the details pane are a corollary of those industrious dissectors identifying your protocols.
The dissectors looks for clues in the PDUs and then make an educated guess about the type of data they see. For example, if the dissector sees a TCP segment using well known port 80 it assumes a HTTP traffic flow. Web traffic typically traverses port 80 so it says,
Yup, this is web traffic
Dealing with dastardly ports
Just as people aren’t perfect, Wireshark isn’t perfect either. Sometimes Wireshark doesn’t get it right. If someone is using a non-standard port for something Wireshark won’t be able to identify the traffic flow because it won’t know which dissector to use.
For example if someone is using a non-standard port for SSH (which is recommended because it improves security) you’ll have a bunch of missing fields in the PDU details pane. Or if someone uses a non-standard port for HTTP traffic it won’t show up correctly.
In the graphic below you can see my computer at 10.0.0.51 is connecting to 10.0.0.1 over port 2222.
What the heck is port 2222? Good question! I made it up.
I setup a web server at 10.0.0.1 and told it to listen for incoming TCP requests on port 2222. This really confuses the Wireshark dissector and it can’t identify the traffic as HTTP.
To fix this, right click the incorrectly identified item in the PDU list view and choose Decode As.
Then select the appropriate protocol from the list and click OK.
Now the correct protocol will show up in the details pane.