On 12 May, Guy Harris wrote:
> Well, I'd actually like the data to be coalesced even when viewing
> individual packets, e.g.:
>
> in all but the first frame in a multi-frame NFS READDIR reply
> there might be a "Continuation from frame N" tree item after the
> IP header (for fragmented UDP) or the IP and TCP headers (for
> NFS-over-TCP) and before the directory entries, and in all but
> the last frame there might be a "Continued in frame N" tree item
> at the end;
>
> only the fields that contain at least one byte from a given
> frame would show up in the protocol tree for that frame (the
> first and last fields might span two packets - presumably if you
> clicked on them, the part that's in this frame would be
> highlighted).
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).
> The logical view you describe, however, would also be useful; in that
> view, you might well have one line in the summary display per
> higher-level packet, e.g. one per NFS request or reply, which would not
> only mean you might have one line in the summary display that referred
> to more than one frame, you might have more than one line in the summary
> display referring to the same frame if there's more than one request or
> reply per packet (which could happen with ONC-RPC-over-TCP or with SMB -
> I have an SMB capture in which that happened).
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.
--
Doug Nazar
Dragon Computer Consultants Inc.
Tel: (416) 708-1578 Fax: (416) 708-8081
