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

[David Aggeler <david_aggeler () hispeed ch>]

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 () 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
>
>    
___________________________________________________________________________
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