On Tuesday, July 1, 2003, at 2:32AM, Biot Olivier wrote:
How about providing more generic "decode as" functionality by mapping a
protocol to a protocol field? We already have udp.port and tcp.port
for the
current "decode as", but how can I map e.g., "smpp.udh.ports.src ==
12345"
to "wap-wsp"?
Mapping *arbitrary* protocol fields requires that the protocol tree be
built; we don't always build it, for example, when initially reading
the packets in, as doing so costs more CPU time.
Mapping arbitrary *dissector tables* is easier - that's what "udp.port"
and "tcp.port" are in the "decode as" code, they're not protocol
fields. (They happen to have the same names as some protocol fields,
but they're not the same thing.) We already support that in Tethereal,
with Lionel Ains' recent changes; you could, for example, match
"smpp.udh.port == 12345" to "wap-wsp" in Tethereal with "-d
smpp.udh.port==12345,wap-wsp".
That command-line flag is currently not supported in Ethereal, but
that'd probably be a simple matter of copying the code over from
Tethereal (and putting as much as possible in common code shared by
Ethereal and Tethereal).
It might be a bit more work, but it might be possible to support that
in the GUI for "Decode As" as well. One way to do it might be to
attach to the "packet_info" structure a stack of dissector table match
information, which would be maintained by "dissector_try_port()", with
each entry in the stack supplying:
the dissector table in which the match occurred;
the port number that matched.
The GUI would change somewhat, as, instead of offering "Link",
"Network", and "Transport" tabs, it would have to offer each of the
dissector table/port pairs, along with a list of dissectors that can be
used with that table. It also wouldn't allow specifying the source
*or* destination port or both for TCP or UDP unless we, for example,
had a "dissector_try_ports()" routine, taking two ports and checking
both (in the same way "decode_tcp_ports()" and "decode_udp_ports()"
do).
