Simple answer : tcp_dissect_pdus works, I tested it. Does not work, for example : - not into tcp - there is no (data into the) header which gives you the length of the pdu/chunk.
After a test with wireshark 1.2.1, the offset given to get_pdu_len is allways zero. data inside tvb != data inside packet data inside tvb (given to get_pdu_len) is only a part of the packet. zero inside this tvb != zero inside packet get_pdu_len must return the entire size of the pdu/chunk (not only the size after the header). pinfo->desegment_offset and pinfo->desegment_len are more complicated to use They could be used when you cannot use tcp_dissect_pdus Finally, what is your problem visually ? Olivier Sudarshan Raghavan a écrit : > 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<[email protected]> 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<[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 > > > ___________________________________________________________________________ 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
