On Sat, Aug 20, 2011 at 9:58 PM, Guy Harris
<guy@xxxxxxxxxxxx> wrote:
On Aug 20, 2011, at 6:08 PM, Brian White wrote:
> I'm currently writing a dissector for a protocol where the server can fragment its data within a single frame as well as across multiple consecutive frames (if necessary). No fragment will ever begin in one frame and end in the next,
What do you mean by "frame"? If your reference to tcp_dissect_pdus() indicates that your protocol runs on top of TCP, then there is no notion of a "frame" at the TCP layer, there's only a sequenced byte stream with *NO* notion of packet boundaries.
I apologize for the confusing terminology, by frame I meant a TCP packet (?) that's shown as a single row in Wireshark.
> There are also no sequence numbers, ids, or anything else in the fragment headers, all I have is a byte containing some flags (indicating fragment or termination -- the final fragment) and the fragment length, which is present at the beginning of each fragment. There is no interleaving of application-level packets from the server to the client, so it is safe to keep reading fragments/frames until I find that a termination flag is set.
So does the "fragment" flag mean "this is a fragment of a larger packet", and the "termination" flag mean "this is the last fragment of a larger packet"?
Yes.
If you're running atop TCP, I would:
1) use tcp_dissect_pdus() to handle multiple fragments per TCP segment and fragments split across TCP segments (yes, that can happen, trust me);
2) do *another* layer of reassembly, in the routine called by tcp_dissect_pdus(), that reassembles the fragments.
Regarding #2, wouldn't this require using fragment_add_multiple_ok()? If so, the question about its offset and frag_offset parameters still stands.