For those that may read this some when in the future
fragment_add_seq_next() does not need a target fragment offset, so much
better suited for TCP based protocols, that do not carry any redundant
sequence logic.
And there are more variants. To better understand the reassembly, read
all the comments in reassemble.c & h.
David
Am 30.06.2010 21:03, schrieb David Aggeler:
I'm trying to get fragment_add_check() working and I did make quite a
bit of progress. D03_Harris_Writing Wireshark Dissectors_Advanced.pdf
was a good start, but is missing the details I need to know. Debugging
helped, but now I'm somewhat stuck with the frag_offset parameter.
DICOM does not have any byte counter in the fragments, so all fragments
need to be merged back-to-back.
Is there an elegant way to let fragment_add_check() resp.
fragment_add_work() doing that, or is the dissector supposed to always
deliver this?
If the later is the case, in order to know how much my reassembly
already progressed, I would need to keep multiple sorted lists of
fragments and their length, i.e. using my own hash tables. So I have a
hard time to believe, this is what should be done.
However, the comment in packet-smb-pipe.c, line 3367 is not very
motivating "instead of assuming we always get them in the correct
order". I expect fragment_add_check() to handle the packet order.
So any hint on the API usage or directions to documentation I may have
missed would be appreciated.
David
___________________________________________________________________________
Sent via: Wireshark-dev mailing list<wireshark-dev@xxxxxxxxxxxxx>
Archives: http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
