[Rayne <hjazz6@xxxxxxxxx>]

Replies inline, prefixed with **.

Thank you.

--- On Tue, 4/7/09, Guy Harris <guy@xxxxxxxxxxxx> wrote:
From: Guy Harris <guy@xxxxxxxxxxxx>
Subject: Re: [Wireshark-dev] Using port numbers to determine next dissector
To: hjazz6@xxxxxxxxx, "Developer support list for Wireshark" <wireshark-dev@xxxxxxxxxxxxx>
Date: Tuesday, April 7, 2009, 6:38 AM

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.

** You're right.

> 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 do you mean by "'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?

** I was thinking more in general terms. If traffic from another protocol is wrongly classified as Protocol A, how do I determine what protocol it actually belongs to?

> 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.

** That's what I thought, but I saw packets classified as GTP with TCP port 2152 listed as their source or destination ports. However, I do not have the trace on hand.