Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: [Wireshark-dev] N in 1 packets

From: Akos Vandra <axos88@xxxxxxxxx>
Date: Sat, 10 Dec 2011 00:11:46 +0100
Hi!

For my thesis project I am trying to get a new type of data source,
ARM TPIU trace messages to work with wireshark.

I am starting of getting the hang of how libpcap works, however a
strange problem arose, that I don't know how would be best handled.

"On the wire", there are fix, 16-byte frames. However these frames
don't contain any useful data, they only act as a container for
smaller data packets, which are packed, and sent together.
This is a little bit blurry, but I'll provide an example.

The target want to send these packet, in timely order:

Exception 15 occured - 5 bytes
Exception 3 occured - 5 bytes
Memory address written - 6 bytes
Exception 3 handling done - 5 bytes
Exception 15 handling done - 5 bytes
All exceptions handled, returning to user application - 3 bytes.

On the wire I can see two 16-byte frames. The first one contains the
first 3 "interesting" packets, the second one the last 3.

My question is this:

Should the pcap code doing the packet capturing present the incoming
datastream as two 16-byte frames, or split the dissection of the
packets, and the libpcap code - upon receipt of a 16-byte frame -
dissect the frame, and present the 3 packets as different packets to
wireshark?

Is it possible for a wireshark dissector to say "hey, this packet
isn't really a packet, actually there are 3 packets here"!

For this project to be useful I need to present the packets in the
wireshark window as seen above. Seeing 2 packets, and then seeing the
inner packets in the subtree is not a good idea. Also, sometimes these
"sub-packets" are not within a single 16-byte frame, sometimes they
are split, if the remaining space in the 16-byte frame is too small
for the packet to fit.

Like this:


Exception 15 occured - 5 bytes
Exception 15 handling done - 5 bytes
All exceptions handled, returning to user application - 3 bytes.
Exception 3 occured, part I - 3 bytes
------------ FRAME BOUNDARY --------------------
Exception 3 occured, part II - 2 bytes
Exception 3 handling done - 5 bytes
All exceptions handled, returning to user application - 3 bytes.


I hope my email is understable....

Regards,
  Ákos Vandra