On Tue, Aug 27, 2002 at 10:34:56PM +0200, Joerg Mayer wrote:
> On Tue, Aug 27, 2002 at 01:00:13PM -0700, Guy Harris wrote:
> > It might be interesting to see if the protocol statistics could be
> > computed without building a protocol tree (as all it cares about is
> > protocols, not all protocol tree items). If that were done, the
> > statistics could be computed when reading in the file in Ethereal, and
> > displaying them wouldn't require another pass through the file. (They'd
> > be recomputed when filtering the display, as the statistics apply to the
> > displayed packets.)
>
> Just an idea that I've been toying with for some time: Ideally the
> statistics should be generated for every protocol, not just a few ones
To which statistics are you referring?
The ones displayed with "Tools->Protocol Hierarchy Statistics" are, as
far as I know, generated for every protocol (or, at least, every one
where its top-level protocol tree item is at the top level of the
protocol tree; that's not the case for some of the authentication
protocols such as NTLMSSP and GSS-API, and it's not the case for
protocols in ICMP/ICMPv6/CLNP error packets, but that's arguably not a
bug but a feature).
> and they should be one pass so that tethereal can use them too.
> In order to reduce the effort involved, this should either be done
> automatically, i.e. without changeing existing dissectors or in a
> manner that allows the necessary changes to the dissectors to be
> done via a script.
> This is what I've come up with:
> each protocol dissector does a call similar to this one:
>
> col_set_str(pinfo->cinfo, COL_PROTOCOL, "TCP");
Almost all protocol dissectors are called with a call to
"call_dissector()" or "dissector_try_port()" or
"dissector_try_heuristic()"; dissector handles have, as one of their
members, the index value for the protocol, so, at least for dissectors
called through a handle, the aforementioned routines could accumulate
the statistics.
The only exceptions are dissectors not called through a handle; we might
want to look into arranging that they be called that way as well.
Another problem is with ARP vs. ATMARP - the ATMARP dissector is only
called by the ARP dissector, if the hardware type is RFC 2225 Classical
IP, but as the ARP dissector has already been called, the packet has
already been added to the statistics as an ARP packet, so we'd have to
have a way for the ARP dissector to "un-count" it before calling the
ATMARP dissector.
BTW, note that the fact that almost all dissectors are called through a
handle also means that we could probably put the
if (check_col(pinfo->cinfo, COL_PROTOCOL))
col_set_str(pinfo->cinfo, COL_PROTOCOL, XXX);
stuff into the code to call through a handle as well, and remove most of
those calls from the dissectors - they'd only be needed if
1) the name in the Protocol column differs from the name the
protocol was registered with (which raises the question
"why?");
2) the protocol column includes a version number;
3) the protocol column displays a protocol number field's value
rather than the name of the protocol with that field (the
Ethernet dissector does that for unknown protocols).
