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] behavior of tcp_dissect_pdus when protocol pdu is across tcp

From: Sudarshan Raghavan <sudarshan.t.raghavan@xxxxxxxxx>
Date: Tue, 25 Aug 2009 00:59:06 +0530
I think the basic question is can tcp_dissect_pdus work at an offset
inside the TCP segment? This is since an RTMP chunk can start within a
TCP segment and end within the same or a later segment. I looked at
the implementation in packet-bgp.c and there is a comment of similar
nature. The implementation there also uses pinfo->desegment_offset and
pinfo->desegment_len for achieving similar behavior. Is this the way
to proceed?

Thanks,
Sudarshan

On Tue, Aug 25, 2009 at 12:23 AM, Sudarshan
Raghavan<sudarshan.t.raghavan@xxxxxxxxx> wrote:
> I have checked this manually (followed the bytes in the raw TCP stream
> in wireshark). I can very clearly see that the start of the new TCP
> segment is where the get_pdu_len function pointer is called by
> tcp_dissect_pdu. I also verified that the RTMP chunk ends at the
> correct offset within the new TCP segment. I have tried with tcp
> checksum validation disabled and it still does not work.
>
> Thanks,
> Sudarshan
>
> On Tue, Aug 25, 2009 at 12:17 AM, wsgd<wsgd@xxxxxxx> wrote:
>> I think that
>> the start of tvb (given to get_pdu_len) corresponds to the start of the pdu.
>> So offset will always be zero.
>>
>> Olivier
>>
>>
>> Sudarshan Raghavan a écrit :
>>> I am currently working on adding a RTMP (Real Time Messaging Protocol)
>>> dissector to wireshark. RTMP sends out messages by splitting them into
>>> chunks. It starts with a default chunk size and sets it to a different
>>> value later if required. Each RTMP chunk will contain a chunk header
>>> and optionally a message header also.
>>>
>>> It is possible that a RTMP chunk starts at an offset inside the
>>> current TCP segment and spills over to the next TCP segment or later.
>>> My length function (get_pdu_len arg of tcp_dissect_pdus) returns the
>>> correct value to be able to get hold of the entire chunk. What i am
>>> seeing in this case (chunk across TCP segments) is that my length
>>> function is getting called as soon as the next TCP segment is seen and
>>> the offset argument passed is 0. I was expecting that tcp_dissect_pdus
>>> will call the length function at the appropriate offset in the next
>>> segment based on the length returned previously. Looking at the
>>> implementation of tcp_dissect_pdus in packet-tcp.c seems to confirm my
>>> analysis. Am I missing something here? How do I make tcp_dissect_pdus
>>> work correctly with chunks across TCP segments.
>>>
>>> Please note that it works fine if the chunk is contained entirely
>>> within a TCP segment.
>>>
>>> Regards,
>>> Sudarshan
>>> ___________________________________________________________________________
>>> 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
>>>
>>>
>>>
>>
>> ___________________________________________________________________________
>> 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
>>
>