On Aug 25, 2009, at 1:24 PM, Beth.Tridium@xxxxxxxxx wrote:
I'm writing a dissector plugin for a protocol that supports
fragmentation. I've made some good progress with dissecting the non-
fragment packets, but the fragmentation reassembly not so much.
The fragment packet headers include a PDU length, a tag, and the
offset of the current fragment in the full PDU. There is no explicit
information as to whether a given fragment is the "last", so I am
trying to figure out how to supply the final argument to
fragment_add_check.
So is the "PDU length" the length of the PDU to be reassembled? If
so, presumably the length of the fragment is also available (either
implicitly from a containing protocol, or explicitly in the header); a
fragment would be the "last fragment" if the fragment offset plus the
fragment length = the length of the PDU to be reassembled.
(In that case, note that you should probably flag as an error
fragments for a given PDU that disagree as to the length of the PDU to
be reassembled.)
I could keep track of the fragment lengths and offsets seen so far,
and calculate for myself when all fragments have been received.
The "last fragment" flag means "this fragment is the one whose content
goes at the end of the reassembled packet"; it does *not* mean "this
is the last piece of the puzzle - the packet is now complete", as the
"last fragment" could well be the *first* fragment received (I think
that, at least at one point, Linux sent the fragments of a fragmented
IP datagram in *reverse* order, perhaps so that the reassembly code
can see the last fragment first and know how big a buffer to initially
allocate for the reassembled datagram), or could be received in the
middle of the sequence of fragments.
The reassembly code knows when the puzzle is complete; you don't need
to determine that. You just need to determine which fragment would go
at the end of the reassembled packet. (I.e., "last" refers to the
sequence of data in the packet, going from the first byte of the
packet to the last byte, not to the sequence of packets received over
time; it's an ordinal in space, not time.)
Also a broader question: is there a good resource for the wireshark
fragmentation API?
Unfortunately, no.
