Don’t Let Wireshark’s Assumptions Mislead Your Troubleshooting

In an effort to educate myself on the inner workings of WebEx, I recently looked at a session with Wireshark. Knowing that WebEx audio has the ability to use UDP or TCP, I wanted to isolate the protocol being employed in my configuration. I watched for a new stream of traffic as I enabled the audio portion of a meeting. I found that the audio was using UDP port 9000.

I next applied a filter to see only this traffic. What immediately jumped out at me was what appeared to be malformed and fragmented packets. I also noticed a lot of strange IP addresses like,,, and so on.

WebExUDP9000Knowing that the audio was working perfectly, I could have easily concluded that my eyes were deceiving me. When I looked closer, I quickly realized that Wireshark was recognizing and decoding this as if the packets were Lawful Intercept.

Changing the Decode TypeDecodeAs

This is a common scenario and the solution is straightforward. In Wireshark, right-click any of the packets and choose Decode As…

TransportAt this point, a new window will appear. Make sure the Transport tab is selected then choose Do Not Decode and Apply.

Now the capture should be reparsed and the stream will no longer be decoded as Lawful Intercept encapsulated traffic. Wireshark shows the packets with the IP addresses we expect and they now appear to be properly formed.



Just like simple Firewalls, Wireshark makes assumptions based on TCP and UDP ports. Most of the time this yields the expected results. However, some ports may be used by multiple upper layer protocols. In those cases, Wireshark’s assumptions may mislead those who don’t regularly look at Packet Captures. Changing the decode to the appropriate protocol or disabling it altogether will allow the analyst to examine and properly interpret the captured traffic.


Disclaimer: This article includes the independent thoughts, opinions, commentary or technical detail of Paul Stewart. This may or may not reflect the position of past, present or future employers.

About Paul Stewart, CCIE 26009 (Security)

Paul is a Network and Security Engineer, Trainer and Blogger who enjoys understanding how things really work. With over 15 years of experience in the technology industry, Paul has helped many organizations build, maintain and secure their networks and systems.
This entry was posted in Other. Bookmark the permalink.

2 Responses to Don’t Let Wireshark’s Assumptions Mislead Your Troubleshooting

  1. NepaMR says:

    Hi Paul,
    I don’t use Wire shark so frequently but anyway i will keep that in my mind……
    How could you hide this kind of blog from me???
    I am always after you…Keep rocking…

  2. Duane Grant says:

    Hi Paul,

    I’ve also had the automatic packet decodes work for me in a much less direct way. We had chosen tcp:2000 for a real-time steam of data and we were seeing odd disconnects where the session was reset for no apparent reason. We scattered a few sun netra boxes around the network to run pkt capture and crossed our fingers. Some weeks later, we captured a disconnect and on tcpdump it seemed as though the packet was dropped downstream repeatedly. When we loaded the file into ethereal, it decoded as skinny which was something we knew nothing about.

    Upon further investigation into the protocol and our cisco routers, we found out that if you were running nat, by default, it would look for embedded nat addresses within the skinny protocol and apparently every few million pkts it thought it found an embedded IP address and then decided it was malformed and dropped it. Turning it off solved the problem and it also showed up in the config. I really need to work in my ethereal/wireshark skills because when in a bind its a critical tool.

    Enjoy your blog and happy holidays!!


Comments are closed.