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.
> 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"?
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.
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <[email protected]>
Archives: http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:[email protected]?subject=unsubscribe
