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
