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
>