Hi,
This sounds reasonable to me ...
I will be spending 6 or so hours on a plane to Singapore next week, so I
will be looking at the issues around per-frame information keeping.
However, I think that this is orthogonal to the issues discussed below ...
Perhaps.
At 12:58 AM 3/18/00 -0800, Guy Harris wrote:
>An issue brought up by Gilbert in mail to me a while ago (which he sent
>to the list inside a later message):
>
> 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
>
>As noted, IPX needs more than one hash table - one for the packet type
>("ipx.packet_type"), and one for the destination socket
>("ipx.dst.socket").
>
>I suspect that if we replaced "find_proto_id()" with a routine that
>takes a field name as an argument, looks it up in the *complete* list of
>hfinfo structures (not just in the list of protocols) and returns either
>NULL (if not found) or "hfinfo->sub_dissectors" for that field (if
>found), that'd let us handle that case.
>
>Presumably, TCP and UDP would register their hash table with "tcp.port"
>and "udp.port", respectively, rather than with both "tcp.srcport" and
>"tcp.dstport", and with both "udp.srcport" and "udp.dstport",
>respectively.
>
Regards
-------
Richard Sharpe, sharpe@xxxxxxxxxx, Master Linux Administrator :-),
Samba (Team member, www.samba.org), Ethereal (Team member, www.zing.org)
Co-author, SAMS Teach Yourself Samba in 24 Hours
Author: First Australian 5-day, intensive, hands-on Linux SysAdmin course
Author: First Australian 2-day, intensive, hands-on Samba course
