Wireshark-dev: Re: [Wireshark-dev] displaying multiple pdu's in one packet as multiple packets
From: Ulf Lamping <ulf.lamping@xxxxxx>
Date: Thu, 22 Jun 2006 12:22:44 +0200
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.

Regards, ULFL