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