On Thu, May 02, 2002 at 04:31:24PM +0000, didier wrote:
> As a quick fix (plen +16 overflow to 0),
Overflowing to 0 means it's 2^32-16; that's a *REALLY* big DSI packet,
and it's not going to fit in memory.
I suspect that's a malformed packet (or not a DSI packet at all). Some
other dissectors doing reassembly put in checks to suppress reassembly
for very large packets.
> but the way dsi handles unreassembled packets is, ... sub optimal.
Protocols running over TCP sometimes require reassembly to be correctly
dissected.
A mechanism might be useful to handle too-large packets by having the
TCP reassembly code
reassemble part of the packet, stopping at the end of a segment
(with some upper limit, maybe a megabyte or so, and stopping at
the end of the segment that takes you up to or past that limit);
for subsequent segments, telling the subdissector (via stuff in
the "packet_info" structure) that the first N bytes of that
packet are a continuation of the most recent packet, and having
those subdissectors display that stuff as such and start
dissecting regular data after those N bytes, if there are any
left.
Really Large reassembled packets are, I suspect, usually "write"
operations containing large chunks of data at the end, so this would
probably do the right thing in most cases.
We might be able to use this mechanism even if reassembly isn't being
done, although the problem is that you might get out-of-order segments
(although we don't handle those correctly even when we're reassembling).
(It might also be a useful mechanism for protocols such as HTTP, where
you probably don't want to reassemble an *entire* HTTP request or reply,
but where you might want to reassemble MIME headers, and use the
"Content-Length" header to let the TCP dissector know when the next HTTP
request or reply starts.)