Wireshark-dev: Re: [Wireshark-dev] fragment_add_..(), pinfo->src/dst, IP vs. TCP Session
From: David Aggeler <david_aggeler@xxxxxxxxxx>
Date: Mon, 12 Jul 2010 00:26:12 +0200

>> 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.