Wireshark-bugs: [Wireshark-bugs] [Bug 11152] Wireshark decodes some valid RTP packets as STUN pa
Hadriel Kaplan
changed
bug 11152
| What |
Removed |
Added |
| CC |
|
hadrielk@yahoo.com
|
Comment # 6
on bug 11152
from Hadriel Kaplan
(In reply to Radovan Prodanovic from comment #5)
> > Perhaps we should mark the entire UDP "conversation" (between the two IP
> > address/UDP port endpoints) as being an RTP conversation once a single
> > packet has been dissected as RTP.
>
> Keep in mind that, according the RFC3550, initial SN for RTP session should
> be a random number. As such, there still would be a small probability of
> decoding the first packet as a TURN message.
In theory that shouldn't happen because the STUN heuristic dissector checks if
there is an existing conversation for that 5-tuple before accepting it as a
TURN ChannelData message. Unfortunately, the UDP layer's dissector will create
that conversation before invoking the STUN heuristic dissector, so this extra
safety check is essentially useless right now.
What it should probably do is never match a TURN ChannelData message in the
STUN heuristic dissector, and instead if the heuristic dissector dissects a
STUN-based TURN message (i.e., any TURN message type other than ChannelData),
then it should set the conversation's dissector to be the handle for
dissect_stun_udp or dissect_stun_tcp based on the transport. That way it will
decode messages as TURN ChannelData only if other TURN messages were seen on
the same 5-tuple. That would perform the original intent/spirit of the current
code's conversation check, I think.
The current odds of the STUN heuristic dissector incorrectly deciding a random
packet is a TURN ChannelData message is fairly high. (approx. 1 in 80k?) The
odds increase a bit for captured RTP traffic, to 1 in 64k.
But the odds of the STUN heuristic dissector incorrectly deciding a random
packet is a STUN-based TURN message (not ChannelData) is insanely low. (it
would be like 1 in 2^50) And for captured RTP traffic it would never
incorrectly match that as a STUN-based TURN message.
BTW, the attached capture showed that with RTP heuristics disabled, the CATTP
heuristic dissector matched some of the packets (packet #74, 177, 596, etc.).
It too is a fairly weak check, and should probably be disabled by default. It
was just a coincidence that RTP's heuristic dissector gets invoked before
CATTP's heuristic dissector - otherwise it would have been another problem like
the TURN ChannelData one.
You are receiving this mail because:
- You are watching all bug changes.
