Wireshark-dev: Re: [Wireshark-dev] displaying multiple pdu's in one packet as multiple packets
On Thu, 22 Jun 2006, Ulf Lamping wrote:
> ronnie sahlberg wrote:
> > I think this problem primarily show up for protocols running over TCP.
> >
> > Some of the dissectors try to overcome this issue by either using
> > col_set_fence() or some fancy tracking inside the dissector itself.
> > That is probably a mistake.
> >
> >
> > I think the best would be to enhance
> > tcp_dissect_pdus() so that it is aware of and manages the problem, not
> > the dissectors itself.
> >
> > I.e. the natural place to manage this would be inside
> > tcp_dissect_pdus() but I dont have a good solution right now.
> >
> >
> > Maybe to start with, a better than nothing implementation could be to
> > everytime a new tcp segment is processed, clear the info list.
> > before evey call to the subdissector, clear the info column
> > after the subdissector returns read info column and store it in a list.
> > Once all subdissectors have return, set the info column to a string
> > that is all the strings from above concatenated together, prepended
> > with [X PDUs]
> > To start with.
> > If there was only one PDU then everything should be as it is today.
> > (If there are too many PDUs to fit on the info line, the user would
> > at least see [999 PDUs] and would be able to click on the packet and
> > look at the decode pane. This should be relatively rare)
> >
> >
> > It would at least give an indication to the user that there are more
> > than one PDU in this segment. which is the main issue right now, the
> > lack of this indication.
> >
> ACK, this would be the more "natural" and clean solution.
>
> If there would be any other transport protocol layers than TCP showing
> this problem, the same solution should be applied there too, but
> obviously the TCP is the most prominent one.
Well, it's a problem for every transport protocol, TCP (stream) and UDP
(datagram) I've seen this on.
Not sure what to do. I would like the summary pane to display a summary
of the _frame_ (lowest level entity) captured at that instance in time.
That we try and present info regarding the top most protocol in that
frame is very helpfull, but shouldn't clutter the presentation of the
entity at hand: the frame. It's the details pane that shows you whats
inside the particular frame, which could be a string of PDU's.
A PDU count column would be a nice feature to add, along the lines
presented above. That would make it very easy to add to all transport
protocol dissectors.
Thanx,
Jaap
