https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4097
Chris Maynard <christopher.maynard@xxxxxxxxx> changed:
What |Removed |Added
----------------------------------------------------------------------------
Severity|Major |Minor
--- Comment #9 from Chris Maynard <christopher.maynard@xxxxxxxxx> 2010-12-02 08:17:16 PST ---
(In reply to comment #8)
> I just tried the trace files again with 1.4.2. With UDP heuristics enabled,
> packets are still decoded as STUN. So no changes from the original bug report.
OK, I was looking for a STUN preference when I should have been looking for a
UDP preference.
The stun dissector references draft-ietf-behave-turn-ipv6-03, but as far as I
can tell (see http://tools.ietf.org/wg/behave/), this is now RFC 5766.
According to http://tools.ietf.org/html/rfc5766#section-11, the only allowable
channel numbers are 0x4000 through 0x7FFF, so the first change I made to try to
tighten the heuristics was to limit the channel numbers to that range. Yes, I
know the RFC also says the reserved values may be used in the future so an
implementation MUST NOT assume that a TURN message always starts with a 0 bit
... this was just a test. Unfortunately it didn't help for any of these
packets because the 1st 2 bytes fall within that valid range anyway.
Well, at the very least, turning off the UDP preference to "Try heuristic
sub-dissectors first" "resolves" the problem. It's not a solution, but it is
an easy work-around, thus I'm lowering the severity.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.