On 30/08/2012 02:09, mmann78@xxxxxxxxxxxx wrote:
It appears that the reassembly API doesn't handle inserting "known
middle" fragments (preferring them to be known consecutively). This
appears to be at least one of the reasons the SCTP dissector does its
own reassembly and why the new Bluetooth dissector from bug 7675
(https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7675) may need to
do its own reassembly as well. Am I understanding the reassembly API
correctly or am I just not being creative enough to understand how to
represent a "known middle" fragment with the current API?
The GPRS SNDCP (acknowledged mode) protocol is another first-middle-last
protocol that isn't handled by the current reassemble.c, see comment 1
in bug 2857.
I think it manages to insert "known middle fragments" OK, but reassembly
generally fails for other reasons.
I came to the conclusion that it is not practical to add this type of
reassembly to the existing functions, and a new function is needed.
The hard part (IMO) is garbage collection for protocols where the
segment number wraps around frequently, if a dropped packet (in the
trace but not end to end) blocks the reassembly of a PDU, then multiple
PDUs can get mashed together when the segment number is next used.
