Wireshark-bugs: [Wireshark-bugs] [Bug 11152] Wireshark decodes some valid RTP packets as STUN pa
Jaap Keuter
changed
bug 11152
| What |
Removed |
Added |
| Status |
UNCONFIRMED
|
CONFIRMED
|
| URL |
|
https://ask.wireshark.org/questions/41803
|
| Hardware |
x86
|
All
|
| Ever confirmed |
|
1
|
| OS |
Windows 7
|
All
|
Comment # 1
on bug 11152
from Jaap Keuter
These packets land in exactly in the sweet spot for RTP / STUN confusion.
First of all the RTP packets cannot be identified for sure as RTP, so you have
to 'mildly suggest' Wireshark to do so. Now Wireshark sets up a 'conversation'
to group these packets now identified as RTP.
Here comes the fun part. The packets at hand (182 and 1637) correctly match the
profile for a STUN packet. And since there's a conversation between these end
points the STUN dissector correctly assumes that this must be STUN then.
There you have it. With creating the conversation of RTP packets, the
groundwork for STUN packets is laid down as well. And these two packets get
trapped. So, without knowledge of external signalling it's (virtually
impossible to know what these packets are, and is it a first come first serve
situation. Currently STUN is first. If it were the other way around there will
be bugs on Wireshark missing legit STUN packets.
The workaround (like RTP outside of conversations) is to
(temporarily/permanently) disable STUN, either from the LH click menu on the
packets details, selecting "Disable protocol...", or from the menu Analyze |
Enabled protocols...
You are receiving this mail because:
- You are watching all bug changes.
