Matevž Pustišek wrote:
Is this change made deliberately?
Yes.
I haven't noticed any discussion on gnutella lately.
Not all Ethereal changes are preceded by discussion; sometimes they're
provoked by somebody happening to notice something, e.g. somebody doing
a regression noticing a behavioral difference in the Gnutella dissector,
looking at it to see what caused it, noticing that it was due to a
change that affected the way purportedly invalid packets are handled,
further noticing that the "invalid" packets were really the latter parts
of Gnutella packets split across TCP segments, and adding support for
reassembly of those packets.
Note, by the way, that if you filter a file that contains packets
fragmented across multiple link-layer frames, and the filter is for the
protocol whose packets are so fragmented or for a protocol running atop
that protocol (where "atop" is the transitive closure of "immediately
atop"), the filter will not match all of the fragments, as only the last
fragment is, in most cases, going to be dissected by the dissector for
the protocol whose packets are fragmented - that dissector will cause
the other fragments' payloads to be reassembled as part of the larger
packet, but they'll only show up as fragments in the dissection.
For packets split over TCP segment boundaries, TCP itself doesn't know
how to reassemble them, as TCP supplies no notion of packet boundaries
to protocols using its service, so the dissector for the protocol whose
packets are split would be called for those packets, and could
conceivably put a hidden field in so that a filter for that protocol
would match those packets. This wouldn't help for any filter for
protocols running *atop* that protocol, or for filter expressions that
test particular fields of the packet; those will only match the last TCP
segment.
For packets fragmented with other protocols, where the lower-level
protocol handles the reassembly (e.g., IP fragmentation), the
upper-level dissector won't even be called until the reassembly is
complete, so the fragments can't be marked in such a way as to match
such a filter.
There *might* be a way to somehow arrange that those packets so that
they'd match an Ethereal display filter that matches the last
fragment/segment, as display filters are only applied after the
dissection is complete, so that, *if* there's a way to "retroactively"
mark a packet as matching a filter, they could be made to appear.
"Retroactively" so marking a packet would mean that we'd have to
"retroactively" add the packet to the packet list pane in the display,
which might be a bit complicated or a bit expensive. Filters that can't
be applied retroactively would be impossible to make match all fragments
of a fragmented packet, e.g. you wouldn't be able to make that work with
read filters or Tethereal filters.
What exactly does the "countinuation" refer to? A jumbo
frame?
In theory, it'd refer to an indication that the TCP dissector thought
that it was a continuation of the data in frame 56 - but I'd only expect
that to happen if the Gnutella dissector were trying to reassemble
packets but the TCP dissector was configured not to do reassembly;
however, prior to change 13165, the Gnutella dissector *didn't* try to
do reassembly. (I'm probably missing something here; Ronnie, why would
that show up if the Gnutella dissector weren't trying to do reassembly?)
Could you send that capture, if you haven't already sent it? I'm
curious why the pre-13165 version would think that a Gnutella packet
*could* be un-reassembled.
