On Sat, Jan 10, 2004 at 07:14:14PM +0100, Olivier Biot wrote:
> How would you implement the "Decode As" function for media (and data)?
I.e., how would you force a particular media type to be decoded with a
particular dissector?
There are a couple of ways I see of doing that.
One way would be to add to the "Decode As..." dialog box the ability to
modify *arbitrary* dissector tables, rather than just the "ethertype",
"ip.proto", "tcp.port", and "udp.port" tables.
You might leave the existing tabs as alternative ways of modifying those
tables.
Another way would be to have the dissector-table matching routines add
to a "stack", attached to the packet_info structure, items for the
match. This might mean that a new routine should be added that takes a
dissector table and *two* port numbers (source and destination),
matching the lower-valued port first and the higher-valued port second,
and use that instead of pairs of "dissector_try_port()" calls (although
the IPX dissector needs a special-purpose hack for
IPX_SOCKET_NWLINK_SMB_NAMEQUERY - see the comment in "dissect_ipx()").
Then, I'd have the tabs for "Decode As" come from that stack. This
might require that some additional information be passed to the
dissector-table matching routines giving the name of the ISO protocol
layer of the protocol doing the matching - or require that, instead of
giving the Ethernet tab the name "Link", the IP tab the name "Network",
and the TCP and UDP tabs the name "Transport", you give them the name of
the protocol being matched (which might still require calling dissector
information be passed to the dissector-table matching routines; however,
that might be considered a feature, as it might also help make it
possible to disable not only protocols but handoffs *from* protocols,
e.g. forcing dissection to stop at the TCP dissector, so that all
subdissector calls from the TCP dissector other than direct
"call_dissector()" calls will fail and calls through "call_dissector()"
will always call the data dissector).