On Fri, May 12, 2000 at 03:44:54AM -0400, nazard@xxxxxxxxxxxxxxx wrote:
> This means that a dissector will need to be able to handle searching
> backwards for the start of the current information (i.e. the start of
> an NFS directory name). Or per stream & packet state if I add that
> packet allocation idea (a list of packets are marked as a group/stream).
I was expecting that, for example:
a fragment of a fragmented IP datagram would have attached to
it, as IP-layer per-packet state (using the stuff Richard Sharpe
added), a pointer to a data structure that listed all the frames
that get reassembled to make the datagram (plus perhaps
information about duplicated fragments, which might just have
"Retransmission of frame YYY" in the protocol tree for the
IP payload);
a frame that's part of a NetBIOS-over-TCP session service packet
would have attached to it, as NBSS-layer packet state, a pointer
to a data structure allowing other frames that are part of the
NBSS packets of which this frame is part to be found;
and so on, i.e. the per-packet state you mention.
> For the logical view, I finally wanted to end up with an end protocol
> driven tree (i.e. the LDAP dissector is in charge of adding frames as
> it follows the stream), and the lower-level protocols (Ethernet, TCP)
> are not added to the tree.
That was what I expected you meant - but would it be only the
highest-layer protocol, or would there be cases where some layers below
it would appear as well (probably any later that doesn't deal with
frames, e.g. for SMB it'd include SMB, everything above SMB, and, for
NetBIOS-over-TCP, the NBSS layer, but not TCP below that or anything
below TCP)?
