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<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
___________________________________________________________________________
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
