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<[email protected]> 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 <[email protected]> >> Archives: http://www.wireshark.org/lists/wireshark-dev >> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev >> mailto:[email protected]?subject=unsubscribe >> >> >> > > ___________________________________________________________________________ > Sent via: Wireshark-dev mailing list <[email protected]> > Archives: http://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > mailto:[email protected]?subject=unsubscribe > ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <[email protected]> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
