Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] TCP Reassembly issues

From: Graham Bloice <graham.bloice@xxxxxxxxxxxxx>
Date: Tue, 10 Jul 2007 11:13:08 +0100
Didier wrote:
> Hi,
> On Fri, 06 Jul 2007 16:45:07 +0100, Graham Bloice wrote
>> I'm still having issues with TCP reassembly when PDU's are split 
>> across TCP segments.  This is a local build of r22258.
> 
> packet-dnp is doing strange and in my understanding wrong things with TCP
> conversations. You can't hijack it that way for you own application layer
> defragmentation.
>

Entirely possible, I just blundered about a bit until it seemed to work ;-)

> 
> Attached is a patch which will work, but only with your capture.
> 
> You have to understand that
> 1) file is first read sequentially (flag.visited is false) and you should only
> create states then, otherwise something will leak and anyway there's no
> guarantee that data will be there, ie when the user browses the packet list.
> 
> 2) You should only use tcp or udp conversation for not mixing stuff from
> unrelated hosts.
> 
> Without your protocol spec it's a bit of guessing but it seems there's no
> sequence number at the application layer so you need to create one:
>

DNP application message fragments are carried in a transport layer which has a
single byte header containing a 6 bit sequence number (tr_seq, 0-63) and two
flags, first (tr_fir) and final (tr_fin).

A single fragment message will have both flags set.

The sequence number does not necessarily reset to 0 at the start of a sequence
of fragments, it just runs sequentially from the fragment where the first bit
is set.

Because the protocol sequence number is repeated between hosts, I needed to
invent a unique one to link related application message fragments together,
hence the static seq_number.  The aim of this is to allow many conversations
between hosts that are individually identifiable, but reuse the protocol
sequence number.  If I understand correctly, you are saying that I should only
increment this and add fragments when first finding a fragment, i.e. the
flag.visited is false.

> 1) find the tcp/udp stream conv
> 
> 2) If there's none attach a proto data with a new se_tree to it, one se_tree
> per conversation, with the frame number as key and your own defragmentation
> counter as data.
> 
> 3) when flag.visited is false and tr_fir (?) is true increment your global
> counter and store it in the se_tree.
> 
> 4) now you can use se_tree_lookup32_le for finding the sequence number of a
> packet. 
> 
> 5) use fragment_add_seq_check as you already do with this sequence number.
> 
> Didier
> 


-- 
Regards,

Graham Bloice