> Do tvbuffers help solve the problem of tcp fragmenting the input stream?
Composite tvbuffs would certainly be a useful mechanism for TCP
reassembly code.
However, I'd say they "help solve the problem of TCP fragmenting the
input stream" in the same sense that "malloc()" helps solve the problem
of building parse trees for input of arbitrary length - it certainly
makes it easier to allocate nodes for the parse tree as needed, but it
doesn't do any of the actual work of parsing the input, so it does only
a tiny part of the work needed.
In order to *solve* the problem:
the TCP dissector would have to reassemble the TCP data stream,
so that the dissectors it calls see an in-order sequence of
bytes with no duplicates or out-of-order packets - however, the
dissectors called from TCP would have to be prepared for
*missing* data, as the data simply might not be in the capture
(either because it wasn't captured or because it wasn't
transmitted in the first place;
the dissectors called by TCP would have to assemble higher-level
packets out of that data stream - if, for example, the protocol
involves a 4-byte integer giving a packet byte count, followed
by that number of bytes of packet data, in the data stream, the
dissector would have to extract that byte count and extract that
amount of data from the stream, and then extract the next byte
count from the 4 bytes following the last of the extracted data,
and so on.
This would all have to be done on the first pass through the packets,
done when the capture is read in, so that all link-layer packets in the
capture are seen sequentially. The dissector would then have to
associate with each of those frames enough information so that, on a
subsequent dissection of those frames it can reconstruct whatever data
it needs to re-dissect the frame *without* any guarantee that frame N-1
will be seen before frame N (as there *is* no such guarantee - users
can click on frames in whatever order they want).
> Basically, I've got an input stream of packets. How should I handle packet
> fragments, and oversized packets, when TCP arbritrarily combines and splits
> them?
>
> For example, let's assume the client is sending 200 byte blocks to the server,
> and that the client sends 10 packets.
>
> TCP would send (Assuming a MTU of 1500):
>
> 1500 bytes, containing 7 and a HALF packets in the first block
> 500 bytes, the 2 and a HALF remaining packets.
>
> Has this been handled by ethereal,
No.
> or do I have to put a static buffer into my dissector.
A static buffer probably won't help, as per the above - a user must not
be forbidden from clicking on the second 500-byte frame before
clicking on the first 1500-byte frame, and there could be *more than
one* occurrence of that, and they could click on the first 1500-byte
frame of the twelfth occurence of that and then click on the second
500-byte frame of the eighth occurrence of that, and that has to work
correctly.
Beside, it also wouldn't always help because TCP won't always show you
stuff in order with duplicate data removed.
> Are there any other dissectors that handle this that I can steal from?
No. The other dissectors for "packets atop TCP with byte counts"
protocols just punt on this; unless you want to wait a while before
doing your dissector, you may be forced to punt as well, just as they
(ONC RPC over TCP, NetBIOS Session Service over TCP, etc.) punt.
