Wireshark · Ethereal-dev: Re: [ethereal-dev] Packet-icq.c update

[Guy Harris <guy@xxxxxxxxxx>]

> > Yes, and the ability to change that on the fly.  This has been discussed
> > (I think Gilbert proposed, a month or so ago, changes to the way
> > dissectors figure out what dissector gets called next, that could
> > provide some infrastructure to help this out), but hasn't been done yet.
> 
> Do you still have that e-mail? I think it was a private
> e-mail to you. It was the same one in which I asked you what was
> on TCP port 631, and it was IPP.
> 
> If you still have it, could you forward it to ethereal-dev?

Yup.  Here it is, along with my response:

Date: Fri, 17 Sep 1999 07:41:22 -0500
From: Gilbert Ramirez <gram@xxxxxxxxxx>
Subject: TCP, HTTP
To: guy@xxxxxxxxxx
Cc: gramirez@xxxxxxxxxx

What's TCP port 631?

} else if (PORT_IS(TCP_PORT_HTTP) || PORT_IS(TCP_ALT_PORT_HTTP)
            || PORT_IS(631))
      dissect_http(pd, offset, fd, tree);

Last night I was thinking about how to handle these "hand-offs", or how
one protocol hands off processing to the next protocol. There could
be some functionality added to the protocol registry, or an entirely new
section of code, that allows protocols to register the fact that they wish
to be called under certain circumstances.

For example, the proto_register_http() function could say:

	proto_register_handoff(proto_http, "tcp.port", TCP_PORT_HTTP);
	proto_register_handoff(proto_http, "tcp.port", TCP_ALT_PORT_HTTP);
	proto_register_handoff(proto_http, "tcp.port", 631);

I think it might be a good idea to use strings like "tcp.port" rather than
protocol numbers (proto_tcp) because one protocol in particular, IPX, uses
two different fields to determine who to call next. If the ipx type is a
certain value, it calls some dissectors, otherwise if the ipx port is a certain
value, it calls other dissectors. When showing the field name as a string, I'm
not suggesting that we use dfilters, but simply have proto_register_handoff()
use that string to lookup the protocol an field. We could use the variable
that holds the value of that field:
	proto_register_handoff(proto_http, hf_tcp_port, TCP_PORT_HTTP);

But then hf_tcp_port would have to be global. Using strings would be easier for
a user interface allowing the user to select TCP and UDP ports and which
dissecters should get called, and in the future for any type of module system
that we implement. The dissector module can plug-in to the processing stream
via proto_register_handoff().

If the code is general enough, every dissector would be able to use it
to determine which dissector to call next. In the TCP module we might say:

	DissectorFunc next_dissector;
	next_dissector = proto_lookup_handoff(hf_tcp_port, TCP_PORT_HTTP);

	(inside the TCP dissector there's no reason not to use hf_tcp_port)

Just some ideas,

--gilbert


PS. Now I have my e-mail system set up a bit more sanely. gram@xxxxxxxxxx
is my home mail, even though I check it once or twice from work. gramirez@xxxxxxxxxx
is my office mail, which I have open constantly. I rarely check that from home.

From: Guy Harris <guy@xxxxxxxxxx>
Subject: Re: TCP, HTTP
To: Gilbert Ramirez <gram@xxxxxxxxxx>
Date: Fri, 17 Sep 1999 10:40:22 -0700 (PDT)
CC: guy@xxxxxxxxxx, gramirez@xxxxxxxxxx

> What's TCP port 631?

The IPP port.  I wasn't sure what header file it should be put in (as
HTTP needs it as well - although, arguably, if and when we get to the
point where the HTTP dissector can see an HTTP transaction in its
entirety, it could base it on the MIME header in the HTTP transaction,
at least for the request, as it has a MIME type of "application/x-ipp"
or something such as that), so I left it as a number for now.

> Using strings would be easier for a user interface allowing the user
> to select TCP and UDP ports

...and, given that registration is done rarely, it's probably not a
performance issue.

That's one of the types of handoff Network Monitor implements; another
type involves (something like) packets processed by dissector X then
being handed, one at a time, to a series of dissectors, each of which
gets to look at the packet and either decide "this is one of mine",
dissect it, and return an indication that the packet's "owner" has been
found, or return a "this isn't one of mine, keep trying" indication.

This is what'd be used for stuff such as SMB (as called from the various
NetBIOS dissectors - if it doesn't begin with 0xff,"SMB", it's not SMB
traffic), ONC RPC (which can go over any port), GIOP (we currently have
TCP check for GIOP traffic, but the GIOP dissector could do that and
return "yes" or "no").