Wireshark-dev: Re: [Wireshark-dev] Using port numbers to determine next dissector

From: Guy Harris <guy@xxxxxxxxxxxx>
Date: Mon, 6 Apr 2009 23:38:00 -0700

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.