Ethereal-dev: Re: [Ethereal-dev] Patch to add the "Decode as" functionality to tethereal

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Lionel Ains <lains@xxxxxxx>
Date: Sat, 28 Jun 2003 23:14:30 +0200
Guy Harris wrote:

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.

That's actually much better than using dissectors' short names or names. I tried this for different tables, but I got a segmentation fault for a few of them (ethertype, gre.proto...). I thus added a test for proto_id's value, which is the one returned by dissector_handle_get_protocol_index(). When it is equal to -1 (no protocol id found), further calls to proto_get_protocol_filter_name(-1) will return NULL, which creates a segmentation fault. I also added a g_assert on the pointer returned by proto_get_protocol_filter_name(), just in case...

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

This is great because it actually adds more flexibility to what's available in the GUI.

	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.

I have added some more changes (mainly updates to the comments, from the parts of the code you changed), and I've renamed a few functions to make their name more explicit. I also separated the two parts that display 1) the list of layer types and 2) the list of protocols supported over a given layer type. These two functions also take an extra user_data parameter to allow the output on any stream (which remains stderr so far).

Finally, I changed a little bit the code that parses the command-line parameter to be slightly more user-friendly. It now tries as much as possible to output the information that the user needs in order to fill-in the different parts of the "-d" parameter.

I hope this will be useful. A patch containing all the changes above is attached to this email (it is based on tethereal.c v1.186).

Lionel

Attachment: patch_decodeas_20030628.gz
Description: GNU Zip compressed data