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.
