Hi, I am making a plugin for Java Serialized object stream. Similar questions occur to me. As the stream doesn't indicate length, so it could run very long inside one tcp stream. I can use conversation to preserve the information across packets. But how do I handle the boundary case. How do I detect an object is sitting at the end of one packet and continues to the next packet.
One way I can think of is to look ahead for the length_remaining to make sure there is enough packets to decode. But this requires to put length check everywhere, as most of the code is generated from ASN.1 file that is some efforts. The other way is, as I know the whole TCP stream is dedicated for this java object stream, so in theory I just need to reassemble all of them into one big buffer. Then the question is, 1. for static file (packets captured already), is there a function to reassemble all tcp packets into one buffer? (similar to trace tcp stream) 2. for live capture, can I do this. When my plugin is decoding, the buffer is growing as well to append all incoming packets. Any other suggestions? Thanks /Yin On 7/13/07, Guy Harris <[EMAIL PROTECTED]> wrote: > > other protocols, such as HTTP, do the reassembly differently, as HTTP > requests and responses don't have a message length in a header near > the beginning of the message (the HTTP header is terminated by a blank > line, so you have to keep grabbing data until you find the blank line; > the HTTP body might have its length specified by the Content-Length > field of the header, or it might run until the connection closes). > > The TCP reassembly mechanism is, by design and intent designed to > handle only the reassembly of messages that cross TCP segment > boundaries. It involves both the TCP dissector and the dissector > above it, as the service TCP provides is a byte stream, with no > message boundaries, so only the dissector above TCP knows what the > message boundaries are. tcp_dissect_pdus() is a wrapper that > > 1) handles multiple messages in a single segment > > and > > 2) handles the details of telling the TCP dissector that more data > is > needed for messages that cross segment boundaries. > > Burdening the TCP reassembly mechanism with handling reassembly for > other protocols would complicate that code - and it's already > complicated, and has some known bugs that need to be fixed. > > > Think about what happens when a P2 packet is split across two P1 > > packets, and each of the P1 packets is encapsulated in a different > > TCP packet. > > Think about what happens when a TDS packet is split across multiple > NETLIB packets. See packet-tds.c for an example of a set of protocols > that work the way your P1 and P2 protocols work. > > > What is needed is a fancier or more general implementation of > > tcp_dissect_pdus, updated to handle new-style dissectors. > > No, what is needed is dissectors for P1 and P2 that do the reassembly > of P2 packets fragmented over multiple P1 packets. Again, see packet- > tds.c. > _______________________________________________ > Wireshark-dev mailing list > Wireshark-dev@wireshark.org > http://www.wireshark.org/mailman/listinfo/wireshark-dev >
_______________________________________________ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
