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.
At a later stage one could change this to print all the strings one by
one on individual lines or make the info colums an expansion or
something
On 6/21/06, Ulf Lamping <ulf.lamping@xxxxxx> wrote:
Durnford, Robin (EXP) wrote:
> I have been writing a dissector and recently implemented the
tcp_dissect_pdus function when I noticed some of my messages were longer
than the length field.
> The pdu dissection works great except that you have to select the message
with multiple pdus in the summary before you notice there are multiple pdus
in the packet.
> To tcp these packets look like one message and are therefore one row in
the summary window, but to the people who will be using the dissector and
looking for a particular message at a glance these pdus are actually 2 or
more different messages.
>
>
That's a common problem. For example, I've seen up to 12! DCE/RPC
requests in a single TCP packet.
The solution I've implemented is to "show" this in the Info column.
I've found the set_fence() function may help in this regard (can't
remember the exact function name), it prevents the info column from
being cleared at the beginning of the dissector (as your dissector will
be called more than once).
Regards, ULFL
_______________________________________________
Ethereal-dev mailing list
Ethereal-dev@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-dev