Re: dissecting TCP packets with multiple PDUs

[John Dill <John.Dill () greenfieldeng com>]

> Message: 1
> Date: Fri, 5 Aug 2016 14:47:59 +0100
> From: Graham Bloice <graham.bloice () trihedral com>
> To: Developer support list for Wireshark <wireshark-dev () wireshark org>
> Subject: Re: [Wireshark-dev] dissecting TCP packets with multiple PDUs
>
> > On 5 August 2016 at 14:08, John Dill <John.Dill () greenfieldeng com> wrote:
> >
> > I have a TCP protocol that sends multiple PDUs.  So far, my dissector
> > seems to handle the cases where one PDU is split across multiple frames,
> > and when multiple PDUs are dissected in one frame.  Unfortunately, I'm
> > having issues where the TCP dissection stops if I have multiple PDUs that
> > are split inside a frame, e.g.
> >
> >
> >
> > packet 37104 TCP segment (536)
> >
> > packet 37167 TCP segment (498) - creates reassembled TCP size of (1034)
> > which is correct
> >
> > However, packet 37167 has the start of another PDU containing 38 bytes.  I
> > can't seem to get the dissector to recognize the start of it.
> >
> > ?I printed out the captured length, but it always seems to be 1034.  I'm
> > not sure how to recognize that the current frame has leftover bytes to
> > start a new dissection.
> >
> > Is there an example plugin that someone can suggest that I can investigate
> > to see how this scenario is handled?
> >
> > Thanks,
> >
> > John D.
>
>
> Is your dissector returning the number of bytes it dissected?

Yes, I am returning tvb_length(tvb), and the length matches the expected size of the Reassembled TCP packet.  It 
appears everything makes sense from that perspective.

Upon closer inspection, I found that one of the frames in a sequence of PDUs appears to have been dropped, so the PDU 
length read in the earlier frame didn't match the data.  I believe that caused the TCP dissector to not parse properly.

I'm looking at another capture, and it appears to have the same issue where one of the last frames of a sequence of 
PDUs is not captured.  I thought I had a problem with my dissector code, but now it looks more like a protocol software 
bug.

On a different note...

One problem I have is that I'm creating multiple subtrees for a protocol when two PDUs are found in the same frame.  
What's the best way to avoid this?

\code
gint
dissect_mk32_tcp_pdu(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree, void *data)
{
  proto_tree *mk32_tree = NULL;
  proto_item *ti;                 /* ti := tree item */
  gint       offset = 0;

  /*
   * This is a high level dissector targeting a re-assembled TCP
   * packet containing MK32 messages.  The main responsibilities
   * of the dissector is to control the meta data displayed in the
   * "Packet List" pane, and to display the packet contents in the
   * "Packet Details" pane.  Typically, the dissection details of
   * higher level protocol messages (MK32) and their contents are
   * handled in message specific sub-dissectors.
   */

  /* Change the Protocol column to MK32 in addition to TCP. */
  col_set_str(pinfo->cinfo, COL_PROTOCOL, "TCP/MK32");

  /* Change the Info column to indicate what? */

  /* Process the remaining data only if actively viewed in the
     "Packet Details" pane (when 'tree != NULL'). */
  if (tree)
  {
    ti = proto_tree_add_item(tree, proto_mk32, tvb, offset, -1, ENC_BIG_ENDIAN);
    mk32_tree = proto_item_add_subtree(ti, ett_mk32);

    mk32_dissect_messages(tvb, pinfo, offset, mk32_tree);
  }
  return tvb_length(tvb);
}
\endcode

If the frame has multiple PDUs, I create multiple mk32_tree subtrees instead of just one.  Is there any recommended 
heuristic or method I should use to determine whether my PDU is in the same frame as another so that I don't make 
duplicate protocol subtrees, e.g. "if (tree && <current_frame_has_not_already_processed_another_PDU_already>)"

I thought about static variables, or maybe using the 'data' member.  Any suggestions?

Thanks,
John D.
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe