[Guy Harris <gharris@xxxxxxxxx>]

Matevž Pustišek wrote:

> Here is the capture.

The first packet happens to be coming from the port the Gnutella 
dissector treats as the Gnutella port (6346), but it's either not 
Gnutella traffic, or it's a file transfer rather than a control packet, 
if for Gnutella that happens over the Gnutella port rather than port 80.

The field at the location that would correspond to the Gnutella packet 
length happens to have a very large number in it, so it's trying to 
reassemble a *lot* of packets.  If TCP reassembly is turned *off*, the 
first packet shows up as an unreassembled Gnutella packet and the second 
one shows up as a continuation of the first packet; if it's turned on, 
they both show up as components of a 
to-be-reassembled-when-the-last-fragment-is-seen Gnutella packet.

The old version of the Gnutella dissector didn't show the first one as 
an unreassembled Gnutella packet and the second one as a continuation 
(as per my message, I couldn't see how it would do so) - i.e., the older 
version wouldn't show "Unreassembled Packet" and "Continuation to #56", 
it would just show "Gnutella, 1460 bytes".

The Gnutella dissector should probably treat any putative Gnutella 
control packet with an unknown packet type, or a length greater than 
some value, as part of an upload/download stream rather than as a 
control packet.  Unfortunately, that might mean it'll have to do more of 
the reassembly work itself, rather than using "tcp_dissect_pdus()".