That is a lot more than what I was looking for. Just the simple
filtering is what I wanted, anything more is gravy.
I agree on the TFTP scenario, but had in mind L2TP, NFS and RTSP which
involve matching ip/port pairs. Also DNS would be a candidate.
In the DNS and RTSP cases, the text window is very handy.
Just my $0.02
Thanks a lot
Kevin
On Friday, October 10, 2003, at 06:12 PM, Guy Harris wrote:
On Fri, Oct 10, 2003 at 03:06:17PM -0400, Kevin wrote:
Would it be possible to add "Follow UDP Stream" or a generic "Follow
Stream" to the right click on the Summary screen? I have to plow
through NFS2 and Streaming traces, both of which are UDP based. It
would be great to have a simple menu pick to do this instead of
building the filter.
The issue this brings up is that "Follow TCP Stream" was originally
implemented to show the text of the stream in a window; the fact that
it
also filtered the display to show only the packets in the stream was, I
think, a side-effect of the implementation.
Some people don't like it. Others, however, find it very useful - I
often use it on non-text protocol streams (SMB, NFS, etc.) where the
text window is useless but the filtering is useful.
Perhaps we should have a "Follow TCP Stream" option to show the text,
with no committment to having it do the filtering (so that we might at
some point re-implement it not to do filtering), and a separate set of
options to filter conversations?
Note, however, that for UDP conversations, you don't always have the
conversation defined by two IP address/port pairs - in some cases, the
replies might come from an IP address different from the address to
which the request was sent, and, in the case of TFTP, the first request
goes from XXX.XXX.XXX.XXX port YYY to ZZZ.ZZZ.ZZZ.ZZZ port 69, the
reply
comes back from ZZZ.ZZZ.ZZZ.ZZZ port WWW to XXX.XXX.XXX.XXX port YYY,
and subsequent requests go to ZZZ.ZZZ.ZZZ.ZZZ port WWW.
This is handled by the conversation code; perhaps what we need is to
have dissectors construct a stack of conversations to which a packet
belongs (i.e., if they create a conversation or look one up, add it to
the stack), and have the UI capable of offering "filtering" based on
any
of the conversations in the stack? That'd work for NFS or any other
ONC RPC-based protocol, as ONC RPC sets up conversations, as well as
TFTP, and it might work for at least some other protocols. A raw
"Follow UDP Conversation" would handle the rest of the cases (as long
as
the same IP addresses and ports are used in all packets).
_______________________________________________
Ethereal-dev mailing list
Ethereal-dev@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-dev
