Re: [Ethereal-users] networked reading of captures?

[Guy Harris <gharris@xxxxxxxxx>]

On Sat, May 03, 2003 at 05:00:03PM -0700, Jon Baer wrote:
> i noticed that winpcap now has remote capture abilities (via
> http://winpcap.polito.it/docs/man/html/group__remote__help.html) but what im
> really wondering is if it is currently possible or possible in the future to
> view via ethereal (for say if you had a wifi dmz setup w/snort to monitor
> traffic) ...

What do you mean "view"?

Do you really mean "is it currently possible or possible in the future
for Ethereal to use those remote capture abilities"?

(If you mean "can you view, with Ethereal, a capture that was done
remotely by another application with those capabilities?", the answere
is "if Ethereal can view a local capture done with that application, it
can almost certainly view a remote capture done with that application,
because you open a remote capture with 'pcap_open()', which returns the
same type of handle that the 'pcap_open_live()' routine to open a local
capture returns, so unless the creator of the application is a complete
idiot who deliberately broke compatibility by changing the file format
when they changed it to use 'pcap_open()', the remote capture ability
makes no difference" - but that's not a very interesting question, as
the answer is a trivial "barring complete idiocy on the part of the
application author, yes, you can", so I'll assume that's *not* what you
mean.)

Current Ethereal uses "pcap_open_live()" to open a capture, so it cannot
use the remote capture capabilities.

It would be possible in the future to have it use "pcap_open()", on
those platforms that have it; on those platforms, it would be possible
to use those remote capture capabilities with a such a modified version
of Ethereal.

There is no official roadmap to do that, however, so I cannot guarantee
that it'll happen in some particular release.  It will probably happen
eventually.

(Changing it to *unconditionally* use "pcap_open()" would be an error of
immense proportions, as the WinPcap developers haven't yet checked
"pcap_open()" support into the libpcap source tree, so it's currently
WinPcap-only, and even when a libpcap with "pcap_open()" support is
released, there will be versions of WinPcap and libpcap that don't have
it, and it would be bad to require people to immediately upgrade to a
newer version of libpcap even if they *don't* care about remote
capture.)