Wireshark · Ethereal-dev: Re: [ethereal-dev] Binding multiple ports to one dissector

[Guy Harris <guy@xxxxxxxxxx>]

> Actually, I think doing it like I did it in packet-diameter.c is the wrong
> way to do it.  Once several dissectors do this, the preferences dialog is
> going to get un-wieldly.

Yes, I seem to remember that some UI book or Web site I saw indicated
that having too many tabs in a tabbed dialog box wasn't necessarily a
good thing.

> I think a higher up package needs to create the tab, and different dissectors
> need to add their ports to it.  Maybe packet-tcp and packet-udp?

"packet-tcp.c" and "packet-udp.c" aren't higher up enough; they're *not*
the only dissectors that have ports in the sense of fields whose values
specify which dissector is to be called next, and aren't necessarily
even the only dissectors that have ports of that sort where the user
might have a reason to want to *change* which values specify particular
dissectors.

It's arguably bad enough that the TCP and UDP dissectors are the only
ones for which the display-filter-based mechanism for connecting plugins
to other dissectors; I don't want to see additional TCP/UDP-specific
mechanisms of that sort stuck in.

There are some other alternatives to obliging sub-dissectors of UDP and
TCP (what about SCTP?) to stuff their port fields under TCP or UDP:

	Date: Mon, 14 Aug 2000 01:52:29 -0700
	From: Guy Harris <gharris@xxxxxxxxxxxx>
	To: Laurent Deniel <deniel@xxxxxxxxxxx>
	Cc: ethereal-dev@xxxxxxxx
	Subject: Re: [ethereal-dev] Edit:Protocols...

	On Sun, Aug 13, 2000 at 04:09:30PM +0200, Laurent Deniel wrote:
	> >   It is now possible to enable/disable a particular protocol
	> >   decoding (i.e. the protocol dissector is void or not). When
	> >   a protocol is disabled, it is displayed as Data and of
	> >   course, all linked sub-protocols are disabled as well.

	The dialog for that seems a bit clumsy, as it gives only the
	short name for the protocol, not the full description.

	A CList display showing the full name and an indication of
	whether the protocl is enabled or not - similar to the
	"Tools->Plugins..." dialog - might look a bit better, although
	the list would be longer.

	It might also be interesting to have a "Properties..." button -
	if the currently selected row in that display is for a protocol
	that has properties registered, that button would become active,
	and would pop up a dialog box showing the same stuff that the
	tab for that protocol in "Edit->Preferences" shows (if we get
	lots of protocols with preferences, "Edit->Preferences" could
	become somewhat clumsy).

which eliminates the tabbed dialog entirely, or:

	Date: Sat, 19 Aug 2000 20:17:53 -0700
	From: Guy Harris <gharris@xxxxxxxxxxxx>
	To: Richard Sharpe <sharpe@xxxxxxxxxx>
	Cc: ethereal-dev@xxxxxxxx
	Subject: Re: [ethereal-dev] What about one dissector for multiple ports

	On Sun, Aug 20, 2000 at 11:09:21AM +0900, Richard Sharpe wrote:
	> It just struck me that we cannot easily re-use a dissector in the case
	> where the same protocol is being carried on multiple ports.
	> 
	> For example, SWAT traffic is simply HTTP on port 901.
	> 
	> 1. How do we declare that port 901 is HTTP, and should be dissected
	> with dissect_http?

	Either by

		1) having "packet-http.c" register itself

	or

		2) having a "packet-swat.c" that contains no dissector, just a
		   call to register port 901 as HTTP.

	> 2. How do we have dissect_http display it in the packet list as
	> SWAT? Since dissect_http has been hard-coded to refer to its
	> protocol as HTTP, we seem to be in a bind.

	Actually, it *currently* is hardcoded to refer to its protocol
	either as HTTP or IPP; if the source or destination port is 631,
	it says it's IPP, otherwise it says it's HTTP.

	Is SWAT just "filling out forms to configure Samba", or does it,
	like IPP, impose restrictions on the HTTP payload such that an
	additional SWAT dissector would be useful, as was done with IPP?

	For various reasons, I've been thinking that it'd be useful to
	be able to register protocols as more than just fields for the
	top-level protocol-tree item for that protocol; I'd see
	protocols as having

		a short name, to put in the "Protocol" column and in the
		tab for the "Preferences" dialog (and perhaps elsewhere);

		a long name, to put in the top-level protocol tree item;

		a filter name, used in filters to refer to the protocol;

		a dissector function;

		a list of preferences;

	and perhaps other items as well (e.g., a "medium length" name to
	set "pinfo->current_proto" to, unless we decide that it'll
	always be the "short name" or "long name").

	If we then had the code to add dissectors for ports or
	heuristics take a reference to a protocol, rather than a
	reference to a dissector, as an argument, the code that then
	calls dissectors from those tables could set
	"pinfo->current_proto", rather than requiring the dissector to do
	it.  We could also have that code handle setting COL_PROTOCOL,
	instead of requiring dissectors to do it.

	We might also have a "hand off to this particular protocol"
	routine - or routines, one taking old-style arguments and one
	taking tvbuffified arguments - taking a handle on a specific
	protocol as an argument, which would do that stuff and then call
	the protocol's dissector; they could be used by the routines
	that look up dissectors by port and that call heuristic
	dissectors.  (This would perhaps require that all dissectors
	return a gboolean rather than void, so that all dissectors have
	the same function signature.)

	With that scheme, SWAT (if it doesn't require any additional
	dissection, along the lines of IPP) and HTTP would be registered
	as separate protocols, but with the same dissector; the setting
	of the protocol name would be done by the common code, not by
	the dissector.

	This might also permit us to have all the work done by
	"dissector_add()" and the like done from a configuration file,
	containing stuff such as

		ethertype	0x0800	IP
		ethertype	0x086dd	IPv6

			...

		ip.proto	6	TCP
		ip.proto	17	UDP

			...

		tcp			RPC
		udp			RPC
		tcp			GIOP

	(the latter entries being for heuristic dissectors).

	We'd probably have both global and per-user versions of that
	file (the global version suggests that we might want to put our
	global configuration files in an "ethereal" subdirectory of
	"/etc" or "/usr/local/etc" or...), and have something in the GUI
	to let users edit those tables.  (This would subsume the current
	cases where individual protocols let you change the port or
	ports they use.)

	It might also be useful to have each registered protocol have a
	"enabled/disabled" flag; the "call this dissector" routine could
	check that flag and, if the protocol is disabled, just dissect
	the payload as data rather than calling the dissector - this
	might obviate the need for the CHECK_DISPLAY_AS_DATA stuff
	currently in all the dissectors.

which could simplify a number of things inside Ethereal, and would
reorganize the way we do dissector handoffs in such a way that the UI
could again be done differently.