Wireshark · Ethereal-dev: Re: [ethereal-dev] GxSNMP

[guy@xxxxxxxxxx (Guy Harris)]

> I am not familiar with how to use NIT or DLPI. Can you provide a really
> brief summary on how it works?

With STREAMS NIT, to do raw link-level I/O, you:

	open "/dev/nit";

	do "ioctl"s to specify which network interface to work with,
	etc.;

	optionally push a "packet filter" STREAMS module that provides
	CMU/Stanford packet filtering (which takes expressions in the
	form of 16-bit stack-machine code);

	optionally push a buffering STREAMS module that accumulates
	multiple incoming packets so that you can get multiple packets
	with one read;

	do reads and writes.

If you have a SunOS 4.x machine handy, the "NIT(4P)" man page, and the
man pages it refers you to, give details.

With DLPI, you do a twisty little maze of stuff, all different, to do
the same thing; it's also STREAMS-based (it's the interface, in System V
Release 4 land, between link-layer STREAMS drivers and networking code
above them, and sufficiently privileged user-mode code can also use it
directly).  It has similar buffering and packet-filtering STREAMS
modules.  A document on using it, and some sample code that uses it, can
be found at

	http://metalab.unc.edu/pub/sun-info/development-tools/dltest.tar.Z

> Do you set up a filter in a similar way to
> BPF (provide a string which represents the filter)?

Actually, with BPF, you set up the filter by providing a program in BPF
machine language; it's "libpcap" that takes a character string, compiles
it into BPF machine code, and hands it to BPF.  STREAMS NIT and DLPI
have similar mechanisms, although the filter is in the form of
16-bit stack-machine code for a CMU/Stanford-style packet filter rather
than 32-bit accumulator-plus-index-register code for BPF.

See Steve McCanne's and Van Jacobson's paper "The BSD Packet Filter: A
New Architecture for User-level Packet Capture", in the proceedings of
the Winter 1993 USENIX, for a discussion of BPF, including a description
of BPF machine code, and a comparison with STREAMS NIT and with
CMU/Stanford-style filter code.

STREAMS NIT, DLPI, BSD BPF, and Linux SOCK_PACKET sockets (without BPF,
as in 2.0[.x], or with BPF, as in 2.2[.x]), fit roughly the same niche -
they're kernel mechanisms that allow user-mode programs to send and
receive raw link-layer packets (I'm assuming here that SOCK_PACKET lets
you do that).

They're not alternatives to "libpcap"; instead, they're facilities
*used* by "libpcap".  "libpcap" hides from the application the
particular facility underneath it; the "pcap-XXX.c" files implement the
"live capture" facility of "libpcap" atop various underlying mechanims:

	pcap-bpf.c			BSD BPF

	pcap-dlpi.c			DLPI (on various UNIXes,
					including but not limited to
					SunOS 5.x)

	pcap-enet.c			Whatever OS has "/dev/enet"
					(Ultrix?  AIX?)

	pcap-linux.c			SOCK_PACKET

	pcap-nit.c			SunOS *3*.x NIT (Network
					Interface Tap)

	pcap-null.c			trivial "sorry, I can't do that,
					Dave" implementations for OSes
					lacking such a mechanism or
					lacking "libpcap" support for
					such a mechanism - lets you
					build "libpcap"-based decoder
					programs for such an OS
					
	pcap-pf.c			Digital UNIX (and Ultrix?)
					packet filter

	pcap-snit.c			SunOS 4.x STREAMS NIT

	pcap-snoop.c			IRIX "snoop" mechanism

> What other non-libpcap capture engines are out there?

STREAMS NIT and DLPI aren't "non-libpcap", in that "libpcap" supports
them, albeit not as well as it supports BSD BPF (it doesn't generate
CMU/Stanford packet filter code for capture filters - it reads *every*
captured packet, and does BPF filtering in userland, so cycles may be
wasted copying packets up to userland only to be thrown out; it also
doesn't currently support the BPF in the Linux 2.2[.x] SOCK_PACKET code,
although there may, as I remember from earlier discussion, perhaps here,
be a patch to implement it - hopefully the guy who did it will send it
on to the "libpcap" folks at LBL for inclusion in a future "libpcap"
release).

I don't know of any alternative libraries to "libpcap" other than
"wiretap" (which doesn't yet do live capture), but some programs may do
Full Frontal BPF or Full Frontal SOCK_PACKET without the aid of a
library (which, unfortunately, reduces their portability).