Wireshark-dev: Re: [Wireshark-dev] fragment_add_..(), pinfo->src/dst, IP vs. TCP Session
Hi Bill,
Thanks for you comments. I've looked at quite a few other dissectors and
the comments around the reassembly function calls do not increase
confidence.
Therefore I'm debugging the reassemble module for quite a while now, to
understand of what is going on.
For DICOM, I need to do the reassembly at two levels. The first one is
at the top, where I have a PDU length to request data.
Here I plan to use tcp_dissect_pdus(), once I undestand how this
interacts with the heuristic hook. My custom merge at this level works
reasonable.
The bigger challange is the second level. For PDVs, there's only a more
flag, and then tcp_dissect_pdus() can't help.And this is where I'm using
fragment_add_seq_next().
David
Am 11.07.2010 17:10, schrieb Bill Meier:
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
___________________________________________________________________________
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
