[Guy Harris <gharris@xxxxxxxxx>]

On Tue, May 27, 2003 at 11:59:56PM +0200, Lionel Ains wrote:
> In the patch attached to this email, tethereal tries to get a dissector 
> handle from the short name associated with that dissector. 
> Unfortunately, if this short name isn't unique, tethereal will use the 
> first one it finds, which happens for DHCPV6 in tcp.port, for example. 

I'm not sure that works right in Ethereal, either.  The problem is that
there are two different DHCPv6 dissector routines (which call a common
routine, passing it a Boolean - which the common routine immediately
sets to "false"...) for "upstream" and "downstream" messages.  The
"immediately sets to 'false'" means it doesn't matter which one it picks
for now, but if there were two, that'd be ugly.

> It will however generate a warning if more than one dissector were found.
> If this short name isn't found, names are used (thanks to the function 
> Guy Harris has added), if this fails as well, then I call find_dissector 
> using the user-specified name as the key in registered_dissectors, but 
> we can then end up trying to decode IP over UDP or that sort of 
> things... is it really useful?

I'm not sure it is.  (If it were, the IP dissector should register
itself as "can run over UDP", so that you can choose it in the "Decode
As" GUI.)

> A parameter would look like that "-d 'tcp.port == 8080, HTTP'" or 
> "udp.port == 5000, RTP"
> In case a name is registered for the dissector we want to use, it is 
> then also possible to use the dissector's name:
> "-d 'tcp.port == 8080, http'" would actually do that.
> As a last attempt, the protocol name specified on the command-line will 
> be attempted as a key in the registered_dissectors hash:
> "-d 'tcp.port == 122, ssh'" would do that (ssh doesn't register a name 
> in the 0.9.12 version of ethereal, ssh is actually directly the key in 
> the hash)
> 
> Here is a patch (attached) to get this functionality into tethereal 

I've checked in a change based on that patch, with some changes:

	The protocol name in the "-d" argument can only be a "filter
	name" for a protocol, the "filter name" being the name used in
	display filters, so you'd do "rtp" for RTP, for example. 
	I left out the stuff to specify a dissector handle name - most
	dissectors don't have names for their handles, and if is the
	case that a given protocol can be usefully dissected atop
	another protocol, the upper-layer protocol should either be
	registered with the appropriate dissector table with a selector,
	or as a "can be used with" protocol (as is the case with RTP) -
	if it's not, it won't show up in the "Decode As" list in
	Ethereal.  (It might be nice to have some scheme in which all
	dissectors are registered by name, and the dissector tables are
	filled in purely from a text file - but we'd need to come up
	with some way to neatly handle, for example, protocols that run
	atop TCP and non-TCP protocols, where the XXX-over-TCP dissector
	is different from the XXX-over-everything-else dissector, as it
	might have to deal with a length field, as is the case with
	DNS-over-TCP vs. DNS-over-UDP, and would have to handle packets
	split across segment boundaries and multiple packets per
	segment.)

	I added code to iterate through all the dissector tables,
	calling a routine for each table, so that the code doesn't have
	to hardwire in the names of dissector tables such as "ethertype"
	or "tcp.port".  (Many of the tables it lists might not be useful
	as targets of "-d", but....).

	The code that lists the dissectors for a particular dissector
	table prints the "filter name" and the *long* name of the
	protocol (arguably, there should be a tooltip, or something such
	as that, in the "Decode As" dialog box, giving the long name, in
	case somebody doesn't know that QYCP is the Quick Yogurt Control
	Protocol or something such as that).

	If there's an error in the "-d" argument, Tethereal quits ("-d"
	doesn't apply if you're capturing to a file, and if you're
	printing output to the console, the error message might well
	scroll off the screen before you get to see it, especially if
	you're reading from a file).

One problem is that there are, arguably, two sorts of dissector tables -
ones where the selector values are strictly tied to protocols (e.g.,
Ethernet types and IP protocol numbers), and ones where the tie is much
looser (e.g., TCP and UDP port numbers).  Most of the time, people will
be doing "Decode As" stuff on the latter; the UI might be simplified if
it were only supported on the latter (simpler "Decode As" dialog box,
less output for the error message for "-d" if a bogus dissector table is
specified).  It might be useful to have a way of doing the others from
"Decode As" and getting a listing of more tables from "-d", however.