Re: fragment_add_..(), pinfo->src/dst, IP vs. TCP Session

[Bill Meier <wmeier () newsguy com>]

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 () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe