Mailing List Archive

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@ethereal.com
http://www.ethereal.com/mailman/listinfo/ethereal-dev

Ulf Lamping 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.

Just two days ago I was looking at an M3UA/SCTP trace with *35* (M3UA)
DAUD messages bundled into a single packet.

> The solution I've implemented is to "show" this in the Info column.

That works up to a point (that point being when the Info column is so
long it scrolls off the right of the screen!). I think, though, that
having some way of viewing the payload PDUs separately would be useful.
I just haven't thought of how that could be done.
_______________________________________________
Ethereal-dev mailing list
Ethereal-dev@ethereal.com
http://www.ethereal.com/mailman/listinfo/ethereal-dev

Jeff Morriss wrote:

> That works up to a point (that point being when the Info column is so
> long it scrolls off the right of the screen!). I think, though, that
> having some way of viewing the payload PDUs separately would be useful.
> I just haven't thought of how that could be done.

One possibility might be to have the packet list be a "tree view" widget
rather than a "list view" widget; if a given link-layer packet has data
from more than one higher-level packet in it, the top-level row for the
packet might be a summary of all the higher-level packets, and if you
open it up you'd see the individual summary lines for each of the packets.
_______________________________________________
Ethereal-dev mailing list
Ethereal-dev@ethereal.com
http://www.ethereal.com/mailman/listinfo/ethereal-dev

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@web.de> 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@ethereal.com
> http://www.ethereal.com/mailman/listinfo/ethereal-dev
>
_______________________________________________
Ethereal-dev mailing list
Ethereal-dev@ethereal.com
http://www.ethereal.com/mailman/listinfo/ethereal-dev