Path: utzoo!utgpu!water!watmath!clyde!bellcore!rutgers!ucsd!ucbvax!SPAM.ISTC.SRI.COM!brunner
From: brunner@SPAM.ISTC.SRI.COM (Thomas Eric Brunner)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Interlan drops a byte?
Message-ID: <8808232013.AA00841@aai7>
Date: 23 Aug 88 20:13:14 GMT
References: <978@rlgvax.UUCP>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 57

Dennis Bednar wrote asking for "ethernet sniffer" info, whether they
(etherfind, tcpdump) ran on Unix boxes, PCs, was source available, etc.

I've just gone through using two reasonable tools, the Network General
"Sniffer", and the Exelan "LANalyser", both PC based for ethernet
analysis, as well as using Van's Tcpdump (daily) and SMI's Etherfind
(only where tcpdump is not available) for the purpose of determining
why a diskless Sun fails under some conditions to boot when running
the 4.0 release of the Sun OS. So I'll share what little I know.

The "Sniffer" is a menu-driven package that runs on a PC, either lap-top
or the usual notion of a PC. It only uses 2 bytes of a packet for filtering,
so one's ability to form a reasonably complex "from/to/size/type" boolean
is limited, though I personally didn't find this limitation a problem at
all - having lived with "noisier" tools. Price, $19,000, $15,000 for the
single-board PC.

The "LANalyser" is less menu-oriented, also runs on a PC, either flavor,
and uses more bytes for filtering. Price, $15,000.

The LANalyser was the choice of SRI's link-level folks whos interest is
mostly in connectivity diagnosis.

The Sniffer was the choice of my own staff, whos interest is both connectivity
and network-level and above diagnosis. With it we found that the diskless
boot problem resulted from interactions between VMS hosts running TWG/SRI
ip software and the Sun's broadcast boot request. Details available upon
request.

Tcpdump is not available in source form, one can either ftp it from any of
the usual places, or if one is not able to ftp from say, lbl or ucbarpa,
via tape from someone who is. It comes as an executable binary (Sun 3.x),
with awk scripts for digestion of its output, in tar format. On a lan with
a lot of hosts, getting a Sun just to run tcpdump seems very reasonable to
me -- I've seen a quote for a 3/50 (used) for $850... I use it to catch
the initiation of "hostile" and "questionable" events here - we've several
scripts to wrap it which may be in our ftp area (spam) if either I or Tim
remember to keep those versions current, and to diagnosis some really bad
vendor cruft (line-at-a-time smtp, with a seperate cr/lf packet!), etc.

Etherfind is available from SMI as part of their operating system release.
It supports fewer of the boolean constructions than tcpdump, and I really
avoid using it since Van's first release of tcpdump.

Another possibility is SMI's traffic routine, which is visual, a nice intro
to the activities on the wire, but little beyond that. Almost no filtering
is possible. Each of these use the NIT interface, particular to SMI, which
has bugs. For those sourced, putting metering into the device driver(s) is
an equivalent approach.

Others on this last can easily improve on this little note, in particular
someone from Network General and Exelan on pricing, "protocol suite" software
extra pricing, and capabilities.

Happy lan-ing Dennis!

Eric