On 10 dec 2011, at 00:11, Akos Vandra wrote:
> 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?
The task of libpcap is to capture frames and hand each frame to wireshark, no dissection is done by libpcap, that is wiresharks job.
>
> Is it possible for a wireshark dissector to say "hey, this packet
> isn't really a packet, actually there are 3 packets here"!
Yes, this is how wireshark works if you implement your dissector to do that. Many dissectors work like that. For example, visit an https site and capture the traffic. You will most probably see multiple SSL records and/or multiple HandShake messages in one frame (sometimes after reassembly if a PDU was split across two or more packets).
> 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.
You're out of luck here with the combination libpcap / wireshark. You will need to make substantial changes to either one of them to make that possible.
> 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.
This is possible, as can be seen in the SSL example I mentioned earlier. There are two ways of doing this in wireshark. More details on reassembly can be found in README.developer (in the source tree).
Cheers,
Sake