Ethereal-users: Re: [Ethereal-users] PASSIVE FTP SESSIONS

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

From: Guy Harris <gharris@xxxxxxxxx>
Date: Sat, 1 Mar 2003 02:54:56 -0800
On Fri, Feb 28, 2003 at 09:09:08PM -0500, Tony Fortunato wrote:
> When I have a trace file that contains a passive ftp session Ethereal
> correctly identifies the data as ftp-data. All my other analyzers do not.
> Can you explain how Ethereal does that?

Its FTP dissector includes code to look at replies to PASV commands and,
if it sees one, to arrange that future TCP traffic using the IP address
and ports specified in the response will be dissected as FTP data.

> I also attempted to capture a passive ftp session with a capture filter
> unsuccessfully.  Any tips on how to properly capture a passive ftp session.

Find somebody with precognitive powers, ask them to tell you what port
number will be used for FTP data in that session, and use that port
number in the capture filter. :-)

Capture filters are interpreted by the BPF interpreter, which is an
interpreter for a fairly simple machine; the filter programs are
stateless, so filters can check only for specific port numbers.  They
also can't modify themselves.

That means that it's impossible to construct capture filters that can
capture passive FTP sessions.

At least with Tethereal, you could use a "read filter" specifying
something such as

	ftp or ftp-data

which will accept either FTP control or data traffic.  Read filters are
like display filters, which means they work on the protocol tree
generated by Ethereal's dissectors.

The good news is that means that you can use any filter expression that
would work as a display filter.

The bad news is that this means that it has to do a full dissection of
*every frame that's handed to Tethereal*, so every frame that passes the
capture filter - and if there's no capture filter, that means every
frame that the machine sees on the interface on which Tethereal is
capturing - gets

	1) copied to userland

and

	2) fully dissected

which could take a significant amount of CPU time.  If you have a
sufficiently busy network, it could take enough time that you'd drop a
significant number of packets.  (I don't know what "sufficiently busy"
or "significant number" would be.  Your mileage would vary depending on
the speed of your machine, the quality of the C compiler used to compile
Ethereal, the speed of the network, etc. - and even given that
information I couldn't give you numbers or even estimates of numbers.)