Ethereal-dev: Re: [Ethereal-dev] Feature request - Follow UDP Stream

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Guy Harris <guy@xxxxxxxxxxxx>
Date: Fri, 10 Oct 2003 15:12:43 -0700
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).