ethereal-dev-request@xxxxxxxxxxxx wrote:
Message: 8
From: Guy Harris <guy@xxxxxxxxxx>
Subject: Re: [Ethereal-dev] Binary PDUs in TCP: Possible to put each
on di fferent summary lin e?
On Thu, May 29, 2003 at 05:15:23PM -0600, Bryant Eastham wrote:
I appreciate your quick (if not ideal) reply.
Is this sort of thing viewed by the majority as a limitation?
I'm not the majority - I'd only be the majority if I were the only
developer - so I can't answer that question; I'm CCing my reply to
ethereal-dev, so we can actually ask enough people to get a majority.
I certainly would love to see such a feature. I have viewed it as a
limitation for quite a while. More specifically, I first encountered
this with OSPF LSA's.
It certainly
is for the class of protocols that I work with. Viewing it a nice thing, and
with your knowledge of the internals, would such a feature be difficult to
implement?
I don't know. You'd have to look through the code to see how many
places assume (implicitly or explicitly) that there's a one-to-one
correspondence between frames and rows.
Note also that
1) the way the summary display works is subject to change (e.g.,
it's subject to being modified so that the text values of the
columns in a row are found not by storing them in a data
structure attached to a row but by reading in the frame and
dissecting it);
Guy, you keep mentioning that recently... is there a thread of
discussion that you can point me to where that has been discussed in detail?
2) people might, in the future, want a feature that does
multiple rows per frame, but not of the sort you're talking
about - they might want to be able to display a multi-line
Info column for a *single* packet, or they might want to
display Info column values for all the layers in the packet
(Network Associates' Sniffer can do that), so a scheme to do
multiple Info lines should be able to handle all of those
being in effect for the same frame.
I could imagine that there might be a way to try and merge the protocol
tree with one-line summaries that are currently shown... I believe that
the trees used in a dissector are already registered... If each tree
(sub-tree) could have the one-line summary fields associated with it,
then there could be some form of user preferences to select between them.
An OSPF example:
* Frame (Time, packet # are stored)
* Ethernet (source, destination, protocol, info stored)
* IP (source, destination, protocol, info stored)
* OSPF (protocol, info stored)
* LSA 1 (info stored)
* LSA 2 (info stored)
* LSA 3 (info stored)
by default, the final item from each top level protocol would be used...
ie. info, protocol from "OSPF"; source, destination from "IP"; Time,
packet # from "Frame"...
A user then interested in OSPF could elect to see LSA rows' data...
either creating a multi-line INFO (one for each LSA), or 3 independent
packet rows showing data for each LSA.
Doing something like Network Associates would also be pretty easy too...
This technique keeps the dissectors from having to know if they should
update the info column or not... and allows the user to see summaries
for only higher layers without disabling the dissection of the lower
layer protocols.
