Wireshark · Wireshark-dev: Re: [Wireshark-dev] Reassembling tvbuff_t

[fab12@xxxxxxxxxxx]

> When you receive a fragment, can you tell which PDU it belongs to (1 or
> 2), or does that only become clear after one of the PDUs is reassembled?
>
> If you can identify the PDU ID before reassembly, then the existing
> reassembly code can be made to work, by allocating a separate reassembly
> buffer for each PDU.
>
> If the PDU ID is ambiguous before reassembly, then the current
> reassembly algorithm will not work for you.
>

I can know the PDU Id before reassembly but the fragments may not come in
order. I guess this is a problem too right.

Also do you imply the code I propose is wrong?

>
>
> -----Original Message-----
> From: wireshark-dev-bounces@xxxxxxxxxxxxx
> [mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] On Behalf Of
> fab12@xxxxxxxxxxx
> Sent: 28 April 2011 08:09
> To: Developer support list for Wireshark
> Subject: Re: [Wireshark-dev] Reassembling tvbuff_t
>
> Hi Anders,
>
> I'm not sure the regular reassembling algo presented in README is good
> for
> me because my fragment do not come in sequence.
> That is I can receive fragment of packet 2 between 2 fragment of packet
> 1.
>
> That is why I'm wondering if my algorithm below is correct and
> especially
> the way I use composite buffer. Is this the general spirit?
>
> /* Fragment receipt */
>  tvb_memcpy(tvb,data,offset,length)
>  frag_buf=tvb_new_real_data(data,length,reported_length)
>  Add frag_buf to global fragrment list
>
> /* Upon receiption of the last fragment */
>  pckt_buf=tvb_new_composite  (  void  )
>  For each frag_buf of same PDU in global fragrment list {
>     tvb_composite_append(pckt_buf,frag_buf)
>  }
>
> /* Then I call my dissector on the reassembled packet. */
>     tvb_set_child_real_data_tvbuff(tvb, next_tvb);
>     add_new_data_source(pinfo, next_tvb, "Complete PDU");
>
>     MyDissector(next_tvb)
>
> /* Do I need to free next_tvp? */
>     free(next_tvb);
>
>
> Regards
> Fabien
>
>> Hi,
>> We have a reassembly API in ~/epan/reassemble.c see also the README
> files
>> in ~/doc
>> Regards
>> Anders
>>
>> -----Original Message-----
>> From: wireshark-dev-bounces@xxxxxxxxxxxxx
>> [mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] On Behalf Of
>> fab12@xxxxxxxxxxx
>> Sent: den 27 april 2011 13:38
>> To: wireshark-dev@xxxxxxxxxxxxx
>> Subject: [Wireshark-dev] Reassembling tvbuff_t
>>
>> Hi
>>
>> I am currently working on a dissector for some proprietary protocol
> and I
>> need to do some reassembling of buffer.
>> I am looking for information on how to handle tvbuff_t API.
>>
>> I have found this :
>>
> http://wireshark.sourcearchive.com/documentation/1.0.0/tvbuff_8h_aa919b4
> 3fdba78f4be4a76aa274e6cce.html#aa919b43fdba78f4be4a76aa274e6cce
>>
>> which is useful but I'm not sure to understand it.
>>
>> With my protocol I am receiving packet in several fragment.
>> The fragment header tells me if it is a head, tail or mid fragment
> packet.
>>
>> I am thinking processing as follows but I am not sure if it is the
> best
>> way or even if it is correct:
>>
>> Upon reception of a fragment:  I copy it in a new tvbuff_t and save it
> in
>> some global list:
>>
>> tvb_memcpy(tvb,data,offset,length)
>> frag_buf=tvb_new_real_data(data,length,reported_length)
>> // what is reported_length by the way?
>> // Is there a better way to make a buffer copy?
>> Add frag_buf to global fragrment list
>>
>> Upon receiption of the last fragment
>> pckt_buf=tvb_new_composite  (  void  )
>> For each frag_buf in global fragrment list {
>>    tvb_composite_append(pckt_buf,frag_buf)
>> }
>>
>> // Then I call my dissector on the reassembled packet.
>>
>> Is this the general idea?
>>
>> Thx
>> Fabien
>
>
> When you receive a fragment, can you tell which PDU it belongs to (1 or
> 2), or does that only become clear after one of the PDUs is reassembled?
>
> If you can identify the PDU ID before reassembly, then the existing
> reassembly code can be made to work, by allocating a separate reassembly
> buffer for each PDU.
>
> If the PDU ID is ambiguous before reassembly, then the current
> reassembly algorithm will not work for you.
>
>
>
>
>
>
> This message contains confidential information and may be privileged. If
> you are not the intended recipient, please notify the sender and delete
> the message immediately.
>
> ip.access Ltd, registration number 3400157, Building 2020,
> Cambourne Business Park, Cambourne, Cambridge CB23 6DW, United Kingdom
> ___________________________________________________________________________
> Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
> Archives:    http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>              mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
>