Ethereal-dev: Re: [Ethereal-dev] Submission of a dissector for the IBM WebSphere MQ protocol v
On Wed, Mar 24, 2004 at 08:54:50PM +0100, metatech wrote:
> >If it's not to difficult to determine the length of an MQ message by
> >looking at the first few bytes of the message, it wouldn't be too hard
> >to make it use "tcp_dissect_pdus()" to handle those issues.
>
> I adapted my dissector quite easily (there is indeed a length field at the
> beginning of the MQ message), but I do not see the difference with the non
> desegmented mode.
I.e., you made a version of your dissector that uses
"tcp_dissect_pdus()" (or does the same sort of stuff that
"tcp_dissect_pdus()" does)?
> I tried with a long MQ message that spans on two Ethernet frames. The
> dissector is called twice, once for each Ethernet frame.
If desegmentation is being done, the dissector would be called for the
first Ethernet frame; it'd call "tcp_dissect_pdus()" (or do the stuff
itself, but if "tcp_dissect_pdus()" can do it, why do it yourself?),
which would check whether the frame was long enough to include enough of
the header to get the length field and, if not, set
"pinfo->desegment_offset" and "pinfo->desegment_len" appropriately and
return. The TCP dissector would start desegmentation, and show the TCP
payload as TCP segment data. If it did include enough of the header,
it'd call the routine handed to it to get the length of the packet from
the header. If the frame is long enough to include the entire packet,
it'd construct a tvbuff containing the packet (and only that one packet)
and call the other routine handed to it to dissect that packet;
otherwise, it'd set "pinfo->desegment_offset" and "pinfo->desegment_len"
appropriately and return, so that the data would be shown as TCP segment
data.
The TCP dissector would be called for the second Ethernet frame; it'd
see that there was a desegmentation in progress, and that the payload
from the second frame was sufficient to complete the desegmentation.
It'd reassemble the data, and call the MQ dissector with a tvbuff
containing the data reassembled from the two frames; the MQ dissector
would call "tcp_dissect_pdus()", which would do all of the same stuff
and discover that it had the entire packet, and would construct a tvbuff
containing the reassembled MQ packet (which would just be the tvbuff
handed to it), and call the dissector routine handed to it, which would
put that MQ packet into the protocol tree.
> I tried with two messages in the same Ethernet frame. The dissector is
> called once with a tvbuffer containing the whole packet.
You presumably mean "containing the whole TCP segment", as it'd contain
*two* MQ packets.
The dissector would call "tcp_dissect_pdus()", which would see that the
tvbuff handed to it has a complete MQ packet in it; it'd construct a
tvbuff for it and hand it to the dissector routine, which would put the
packet into the protocol tree. It'd continue in the loop and see that
the data in the tvbuff *after* that packet is also a complete MQ packet;
it'd construct a tvbuff for it and hand it to the dissector routine, so
you'd have two MQ packets in the protocol tree. (If there are more,
it'd put them into the tree as well; if the last packet was continued in
subsequent TCP segments, it'd do reassembly.)
