Gilbert Ramirez wrote:
>
> On Wed, Oct 13, 1999 at 01:12:41PM -0500, Laurent Deniel wrote:
> >
> >
> > I agree for the detailed window but having the proto/info fields in the
> > summary list repaced by UDP while it is not really a simple IP+UDP packet
> > is a bit confusing. The worst case for instance is having an UDP or NBNS
> > info field when decoding an ICMP port unreachable message for instance
> > (if we had called dissect_ip in dissect_icmp) ... Maybe some GUI options
> > could be added to control the level of decoding (in the detailed tree as
> > well as in the summary list window).
>
> It should be fairly easy to add some options to be able to stop
> the addition of information to the list of packets at any point.
> If I say "don't show information above PIM in packet-list" (but do show
> it in the protocol tree), dissect_pim() could detect that and do
> some magic to the column pointers, so when dissect_ipv6() is called
> and does its check_col() checks, it won't add info to the columnar list,
> but it will add data to the protocol tree.
Right.
> Would this alone be enough? Do you really want to stop decoding at
> certain levels in the protocol tree?
Maybe not (but might be useful for performance reason or for disabling a
buggy dissector).
In any cases, the mechanism I was thinking about for months which is almost
required to fully and correctly? implement the first part could be also used
for other purposes (graphs, statistics and some other things).
I have no time to describe it completely now but here is a quick overview:
We currently have protocol registration which defines fields of protocol
header as well as relations between each protocol trees which are dynamically
defined at run-time when a particular protocol is found in a packet.
This means that we do not have static (in the sense of "known before
packet decoding") relation between protocols.
To allow the user to disable a particular decoding, it would be interesting
to show a graph of protocol dissectors e.g. :
eth -A+--> ip -+-> udp ...
| |
fddi -B+ ... +-> tcp ---> http
|
... +-> icmp -C-> ip
So the user could for instance cancel the link C to disable any IP decoding
from ICMP packets etc.
This kind of relation could also be used to store in a more generic way some
information needed between different level of dissectors.
Semi-dynamic registering could be made by registering any dissect_xxx
routines called in a particular dissector.
For instance in dissect_ip :
proto_register_subprotocol("udp", "tcp", ...);
Each string could represent the protocol name specified with
proto_register_protocol). Then when all protocols are registered (when all
proto_register_xxx routines are called via proto.c), all relations are known
and it is possible to link each name with their protocol registration ids.
With this kind of registration, the hierarchy is still known at run-time but
without any need of packet dissection (and is complete).
I think this stuff could be used for canceling the decoding according to the
user needs (either in the column window and/or in the detailed tree) but also
for other purposes (to save some protocol tree lookup ?) ...
Any comments ?
Laurent.
--
Laurent DENIEL | E-mail: deniel@xxxxxxxxxxx
Paris, FRANCE | laurent.deniel@xxxxxxxxxxxxxxxxxxxxxxxxxxxx
| WWW : http://www.worldnet.fr/~deniel
All above opinions are personal, unless stated otherwise.
