On Apr 6, 2009, at 10:55 PM, Rayne wrote:
I understand that Wireshark uses 2 ways to determine what dissector
to call next, in the event that there is no "Next Protocol" field or
the equivalent - by looking at the port numbers of current layer, or
at a list of heuristic dissectors.
It's probably better stated as
Wireshark's TCP and UDP dissectors use 2 ways to determine what
dissector to call next - by looking at the port numbers of current
layer and by looking at a list of heuristic dissectors.
I.e., the statement is about particular dissectors, not dissectors in
general - there's no single centralized point at which the core of
Wireshark determines what dissector to call next; each dissector sets
its own handoff policy.
What happens if there are no heuristic dissectors to look at and
there are other traffic that also uses the port registered to a
particular protocol? For example, say ProtoA is registered to UDP
port 5000. If I have some non-ProtoA traffic that also uses UDP port
5000, would these traffic be wrongly dissected by ProtoA dissector?
Currently, yes, absent any mechanism to associate some protocol other
than protocol A with a given conversation.
There is *NO* solution to that problem that does not involve either
1) some form of heuristics
or
2) some mechanism to associate a different dissector with particular
traffic
or
3) some mechanism to dis-associate the protocol A dissector from some
or all traffic
as otherwise there's no way for Wireshark to determine, to use that
particular example, whether a given port 5000 packet is for protocol A
or protocol B or....
If we supported registering multiple dissectors for a given port
number, those dissectors would need to be "new-style" dissectors, so
that they're allowed to look at the packet and decide whether it's for
them or not; those dissectors are heuristic, even if they're not like
"regular" heuristic dissectors in that they're associated with a given
port.
Mechanisms to associate a given dissector with particular traffic
exist. If you can't make protocol A's dissector heuristic or a "new-
style" dissector, but some packets for another protocol can specify
that port 5000 will be used for some third protocol in a particular
conversation, the dissector for that protocol can set up the dissector
for that third protocol (some "setup" protocols can do that for RTP,
for example). You could also disable the dissector for protocol A,
and there's the "Decode As" mechanism.
What are some of the examples of protocol A and the other protocol, so
we can determine whether there's a way for Wireshark to handle that
problem automatically, or whether it requires human intervention?
Also, I noticed that traffic that uses TCP ports 2123 and 2152 are
classified as GTP traffic (I'm using Wireshark 0.99.6). However, if
I'm not wrong, the 3GPP specs state that GTP traffic only uses UDP
ports 2123 and 2152, not TCP (well, GTP version 1 anyway, version 0
and GTP' can use both TCP/UDP port 3386).
TS 09.60 V7.8.0 for GTP v0 mentions UDP and TCP port 3386.
TS 29.060 version 4.3.0 Release 4 for GTP v1 mentions UDP ports 2123
and 2152. Unless there's some flavor of GTP version 1 documented
elsewhere that runs over TCP ports 2123 or 2152, the GTP dissector
shouldn't register for those ports, just for UDP ports 2123 and 2152.