[David Aggeler <david_aggeler@xxxxxxxxxx>]

>> To what port numbers are you referring?  The fragment_add_seq 
routines are used to reassemble data from protocols that have no port 
numbers.
>> The fragment_add_seq know nothing of IP or TCP, which is as it 
should be.

Interesting.

I was asking on how to properly do reassembly before I started, but did 
not get much more that references to tcp_dissect_pdus().
But as far as I could tell, one requires to know the final lenght when 
using tcp_dissect_pdus(). That's why I explored your presentation about 
'Writing advanced dissectors'. And as example you mention decryption, 
which can very well be a payload of TCP.

And the debugging showed, that the fragment_add_seq functions are doing, 
what I had done manually in the DICOM dissector, but better. I liked the 
hashing concept and the new final buffer, I was only struggeling with 
the usage API. But in the end, I AM HAPPY with them, even for TCP 
payload. And I would do it again.

>>If the issue is reassembling packets from separate TCP connections 
separately, one solution is to have separate
>>fragment and reassembled tables per TCP connection (or per whatever 
type of connection is involved).

Would be an alternative to the conversation index you suggested. For 
DICOM the compression of the 32 bit index and the 8 bit presentation 
context ID into a 32 bit ID, was possible. Of course, there's a chance 
for a false true, but since I skip the top 8 bit of the index, the 
probability is low enough for me. And it less effort than dynamically 
create and manage the two lists. I'll consider it for the next revision.