["yin sun" <sunyin51@xxxxxxxxx>]

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 <guy@xxxxxxxxxxxx> 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@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-dev