Guy Harris wrote:
>
> 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.
It's a write unreassembled packet (Saul mailed me a capture) so plen is
actually data and yes it's 2^32 -16, leading to an infinite loop.
>
> > 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.
It's the case with DSI (read and write packets are the only packets
fragmented with an ethernet like MTU).
Didier
