Wireshark-bugs: [Wireshark-bugs] [Bug 11152] Wireshark decodes some valid RTP packets as STUN pa
Comment # 3
on bug 11152
from Guy Harris
(In reply to Radovan Prodanovic from comment #2)
> I've managed to disable STUN via Analyze -> Enabled protocols and unchecking
> STUN.
>
> Not sure how to disable it via "LH click menu on the packets details".
>
> Originally, I was trying to disable the STUN protocol in Edit -> Preferences
> -> Protocols, but STUN is not listed there.
>
> I think the way it is now, am not going to be the only one that's confused
> by the interaction of the RTP and STUN. Would it make sense to include the
> option to disable the STUN protocol in Edit -> Preferences -> Protocols?
>
> Could you please advise which version of wireshark first included the
> support for the STUN. I've recently upgraded to 1.12.2 and then 1.12.4 and
> this is where I've observed "the issue".
As per my answer to the question on ask.wireshark.org that started this:
https://ask.wireshark.org/questions/41803/wireshark-1124-decodes-rtp-packets-as-stun-why
what matters here is not support for STUN but support for TURN ("Traversal
Using Relays around NAT") as described by RFC 5766, "Traversal Using Relays
around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT
(STUN)":
https://tools.ietf.org/html/rfc5766
with the packets in question, the ChannelData messages, described in section
11.4:
https://tools.ietf.org/html/rfc5766#section-11.4
so what matters is the addition of support for TURN.
The STUN heuristic dissector is recognizing the RTP packets as TURN ChannelData
packets. There *is* a check, early in dissect_stun_message() in packet-stun.c,
for valid ChannelData messages, including a check of the value of the putative
length field, so either that check is somehow being bypassed or is letting the
packets in question pass the test.
You are receiving this mail because:
- You are watching all bug changes.
