Ethereal-dev: Re: [ethereal-dev] Should "Follow TCP Stream" filter the display or not?
> Actually, I have something to say about this. Protocols which run over
> TCP typically are not cognizant of packet boundaries; they have their
> own internal packetization. Having these protocols limited to IP
> packets means that a large packet in a TCP flow which has many IP
> packets (or many small protocol packets in a single IP packet) is not
> handled well. This weakness is evident in MS Netmon as well.
>
> I think we have an opportunity to do something different
> here. Basically, for a TCP connection, you find all the packets in
> that connection, extract the data portion of those packets, write them
> to a separate (temporary) file,
...which is one of the things "Follow TCP Stream" does.
However:
> then run a protocol-only decoder on
> that data - perhaps in a separate window.
...all "Follow TCP Stream" currently does with the resulting file is put
it into a text window, which is OK for text-based protocols, but may not
be so useful for non-text-based protocols such as ONC RPC-based
protocols or SMB.
> I have some demo code for
> this which I'll send in shortly. This will allow us to write TCP-based
> protocol decoders properly.
Note that there's more to the problem than just TCP - at least some of
this problem exists even some *UDP*-based protocols.
If the protocol sends out UDP datagrams that don't fit in a single
frame, so that the IP datagram containing the UDP datagram gets
fragmented, and a dissector that would dissect the entire UDP datagram
can't do so unless the IP fragments get reassembled and the reassembled
fragment handed to the dissector.
Both Gilbert and I have been thinking about this; Gilbert sent out mail
about this a while ago, discussing an approach that I think was similar
to the one you're suggesting, and I'd been thinking about whether it'd
be possible to have this work with the regular dissection window.
