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, then run a protocol-only decoder on
that data - perhaps in a separate window. I have some demo code for
this which I'll send in shortly. This will allow us to write TCP-based
protocol decoders properly.
As far as having a filter to select all IP packets in a TCP
connection, that can be a separate filter option - maybe from the
menu. We'd use the same (or a similar) filter to actually find the
packets for the above stuff, but it would not be in the same window et
al.
Thoughts?
-Ashok
Guy Harris writes:
> It used to leave a display filter in effect, so only the packets in the
> TCP stream were displayed. It now runs the display filter to generate
> the text window, and then undoes the display filter.
>
> I'd used "Follow TCP Stream" in the past to select a particular TCP
> stream and look at its packets, so I actually prefer having it leave the
> display filter in effect, and would like to have *some* option to
> continue to do that, even if "Follow TCP Stream" doesn't do that.
--
--- Asok the Intern (well, not really...) ------------------
IOS Network Protocols, Cisco Systems
250 Apollo Drive, Chelmsford, MA 01824
Ph: 978-244-8387
