David Aggeler wrote:
Roughly, DICOM has one TCP session for commands and one for data.
Now fragment_add_seq_next() does not seem to keep different TCP sessions
apart, and solely looks for pinfo->src/dst, which I think are supposed
to represent the IP addresses. But this screws up the reassembly.
Any precondition I missed? Do I need to add a new functions to the
reassemble module or somehow seqeeze srcport/dstport into the ID?
Two comments:
1. fragment_add_seq_next and similar take an "id" argument which is
supposed to be unique for each/any "currently in progress" reassemblies.
(My impression is that the id does not need to be unique for each
separate reassembly).
For example: One dissector uses a "conversation sequence number" as the
id; TCP uses "assembly first frame number".
My sense is that not all dissectors specify the "id" properly. I've had
an item on my ToDo list for a while to dig deeper.
(Looking at various dissectors which use fragment_add_seq_next may be of
help).
2. For TCP it's usually simpler to use tcp_dissect_pdus() for
reassembly. All the details are handled for you.
See doc/README.developer section 2.7.1
