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
