On Apr 7, 2009, at 1:52 AM, Rayne wrote:
** What do you mean by "'Decode As' mechanism"?
Select, for example, a UDP packet, and select "Decode As" from the
"Analyze" menu. The "Transport" tag is probably displayed; if not,
select it. It should offer the option of dissecting the packet's UDP
source port number, the packet's UDP destination port number, or both
port numbers as one of a list of protocols.
** 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?
If "I" refers to you as a Wireshark user, you'd look at the raw hex
data and see what the packet looks like.
If "I" refers to you as a Wireshark dissector writer, you'd make your
dissector look at the raw binary data handed to it and see whether it
looks like one of its packets or not.
There doesn't exist a magical general solution that always arranges
that packets are dissected by the right dissector.
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.
When I said "shouldn't", I meant it in a prescriptive sense, rather
than a descriptive sense - unless there's some way in which GTPv1 runs
over TCP ports 2123 or 2152, it's not correct for the GTP dissector to
register for those ports (that's the prescriptive sense of
"shouldn't"), but it *does* register for them ("shouldn't" in the
descriptive sense would have meant "the dissector doesn't register for
those ports, so there's no way it could be handed those packets").
