Re: [Wireshark-commits] rev 44802: /trunk/epan/ /trunk/epan/dissectors/: packet-6lowpan.c packet-atalk.c packet-bacapp.c packet-batadv.c packet-ber.c packet-btobex.c packet-capwap.c packet-cell_broadcast.c packet-clnp.c ...

[Stig Bjørlykke <stig () bjorlykke org>]

On Fri, Sep 7, 2012 at 4:10 AM,  <morriss () wireshark org> wrote:
>  tcp.data already exists for exposing a single TCP segment's payload as a byte
>  array. It would be handy to have something similar for a single application
>  layer PDU when TCP segment reassembly is involved. I propose
>  tcp.reassembled.data, named and placed after the already existing field
>  tcp.reassembled.length.

What is the functional difference between tcp.segments and tcp.reassembled.data?

They both provide the reassembled data, and I think this looks like a
duplicate field.
Or do I miss something here?

The reason I ask is because I was thinking about this when
implementing reassembled.length, but found the existing field
(hf_fragments) sufficient for all practical use.  And yes, I know this
question is a bit late :)


-- 
Stig Bjørlykke
___________________________________________________________________________
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