Ethereal-dev: Re: [ethereal-dev] logical display

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

Date: Fri, 12 May 2000 04:28:00 -0400 (EDT)
On 12 May, Guy Harris wrote:
> 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.

This needs to be available from each packet (i.e. it shouldn't be
attached to the first packet, but in a global list you can query based
on your current frame), I think. This involves a lot of changes in the
way a dissector looks for data. If we are on the 2nd packet (of a
protocol that doesn't have a well defined start boundary, how do we
find the start of the next request/data. I'm thinking of HTTP, for
example, with keep-alives enabled. You're going to need to go
back to the beginning to find the start of the next request in the
current packet.
 
> 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)?

Well, it's what I want eventually. It's up to the protocol(s). For LDAP
& HTTP, it would be at that level. For RPC, it would probably be at
that level. What I want is to see the the actual high-level
communication at a message level. Maybe the CList should be a CTree
with a branch for each protocol level (like the per packet CTree) but
at a per stream level. Sorta like this

Ethernet (Source XXX, Dest YYY)
  TCP  (Source XXX:xx, Dest YYY:yy)
    LDAP Bind Request
    LDAP Bind Response
    LDAP Search Request
    LDAP Search Entry
    LDAP Search Entry
    LDAP Search Response
    LDAP Unbind Request
Ethernet (Source AAA, Dest BBB)
  TCP  (Source AAA:aa, Dest BBB:bb)
    HTTP Request (http://zing.org/)
    HTTP Response (http://zing.org/)
    HTTP Request (blah)
    ...
  ...
 
-- 
Doug Nazar
Dragon Computer Consultants Inc.
Tel: (416) 708-1578     Fax: (416) 708-8081