Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!elroy.jpl.nasa.gov!decwrl!pa.dec.com!mogul
From: mogul@wrl.dec.com (Jeffrey Mogul)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Subject: traffic monitoring by net snooping
Message-ID: <1991Feb16.014841.10155@pa.dec.com>
Date: 16 Feb 91 01:48:41 GMT
References: <CHRIS.91Feb13165726@endgame.gsfc.nasa.gov> <5455@s3.ireq.hydro.qc.ca> <85756@sgi.sgi.com>
Sender: news@pa.dec.com (News)
Organization: DEC Western Research
Lines: 28

In article <85756@sgi.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>Trying to keep up with and properly filter network traffic from an Ethernet
>or FDDI MAC in promiscuous mode requires substantial support below the
>application.  Such support, if present, is not currently likely to be
>sufficiently similar on products from hardware vendors.

I've ported a number of such programs, and (if the program structure
is at all modular) it turns out to be pretty easy to get a program
(e.g., tcpdump, nfswatch, statspy) to run on the following systems:
	Ultrix + Ultrix packet filter
	SunOs + NIT
	4.xBSD + new "Berkeley Packet Filter" (BPF)
and possibly the IBM RT using the modified Stanford packet filter done
by some folks at Merit.

True, all of these facilities have evolved from the same base
(even NIT seems to be based on the Stanford packet filter), but
that base did not support promiscuous mode, and all those evolved
versions do.

Admittedly, it becomes a little trickier if your application does
fancy filtering, since the filter languages are slightly different
(the BPF language is entirely different).  However, most statistical
network monitors (as opposed to a trace-program such as tcpdump)
general want to see all (or almost all) the packets, so filtering
isn't an issue.

-Jeff