ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

Wireshark-dev: [Wireshark-dev] packet reassemle question

From: Lars Poeschel <poeschel@xxxxxxxxxxx>
Date: Fri, 16 Jan 2015 16:06:14 +0100
Hello!

I try to implement a dissector for the 3gpp mux27010 protocol based on
the siemens/cinterion mux27010 that is already available in wireshark.
Besides some trivial things, the interesting part is the PPP HDLC frames
that are carried inside those mux frames. I managed to reassemble the
PPP HDLC frames in most cases. I can at the moment handle the case,
where on mux frame encapsulates exactly one PPP HDLC frame. I can also
handle big PPP HDLC frame that is spread across multiple mux frames, but
where I am stuck at the moment is when a mux27010 frame encapsulates more
than one PPP HDLC frame.
What I do in dissect_mux27010 is this:

  frag_msg = fragment_add_seq_next(&msg_reassembly_table,
          tvb, offset, pinfo, 1, NULL, length, more);

  next_tvb2 = process_reassembled_data(tvb, offset, pinfo,
          "Reassembled PPP-HDLC message", frag_msg, &msg_frag_items,
          NULL, mux27010_tree);

  call_dissector(ppp_hdlc_handle, next_tvb2, pinfo, tree);

This does the trick for both of the above mentioned cases, but if there
are multiple PPP HDLC frames inside a mux frame this does not work. I
have to do the above sequence for every PPP HDLC frame I recognize and
sure it can not this way because I use the constant 1 as id to
fragment_add_seq_next and the pinfo->fd->num is also the same, so the same
hash is used for the msg_reassembly_table hash table and I get the same
frag_msg everytime.
The protocols frames give me no idea about wheter actual the frame is
containing a first, a middle or a last part of the encapsulated
protocol. There is no id, no sequence number - nothing. The PPP HDLC
frames inside just use the value 0x7e as a mark where a frame ends or
begins. Does anyone have an idea how I can do a correct dissection /
reassembly in this case ?

I thought about storing some internal state of the dissector somewhere
and beeing then able to use different ids but this is propably also
likely to fail.
Another way I can think of is if there where a way to look back from one
pinfo to their predecessors and see if there was this special case and
to use another id then. But I see no way to look at previous pinfos
during dissection.
Are there other ideas ?

Thanks,
Lars