Path: utzoo!attcan!uunet!samsung!sdd.hp.com!elroy.jpl.nasa.gov!decwrl!decwrl!mogul
From: mogul@jove.pa.dec.com (Jeffrey Mogul)
Newsgroups: comp.unix.ultrix
Subject: Re: DLI programming interface info request (for traceroute)
Keywords: Data Link Interface DLI traceroute
Message-ID: <442@jove.dec.com>
Date: 25 May 90 22:17:20 GMT
References: <1990May18.181145.5630@cs.utk.edu> <11727@shlump.nac.dec.com> <9642@lindy.Stanford.EDU>
Sender: mogul@decwrl.dec.com
Organization: DEC Western Research
Lines: 54

In article <9642@lindy.Stanford.EDU> vaf@Valinor.Stanford.EDU (Vince Fuller) writes:
>Has anyone considered implementing a raw I/O library which would define
>a common interface to both the packet filter and NIT? I started to do
>this at one point, but didn't have both packet filter and NIT systems
>available to test it. Unfortunately, the packet filter interface also
>provides somewhat more functionality than NIT, so such a library would
>have to cater to the "least common denominator" of the two... Still,
>such a library would be very useful to those writing raw-packet code.

That's an interesting suggestion.  I've written a few library functions
for my own purposes as a way of simplifying the interface to the packet
filter.  However, when I ported three NIT applications (tcpdump, statspy,
and nfswatch) to Ultrix, I found it simpler to modify the existing code
in those applications instead of using a set of common library routines.

The reason is that there seems to be three interesting classes of things
to do when coding for the packet filter:

    (1) Initialization: open the device, set the various parameters.
    
    (2) Filter creation: if you want to filter packets in the kernel
    (as opposed to simply receiving everything) you need to produce
    the right "filter program".
    
    (3) Receiving packets: this usually takes the form of a loop, perhaps
    protected by a select() statement, that unpacks batches of packets
    and dispatches them, perhaps after incrementing some counters.
    
Step #1 (initialization) is probably the most stereotypical phase,
but even there one would have to provide a bunch of options ... and
you are right that NIT and the packet filter differ somewhat in the
facilities that they provide at this point.

Step #2 (filter creation) is probably the hardest problem.  The NIT-based
applications I ported don't bother with filters.  I've played around
with a few approaches (including canned library routines for things
like "receive all NFS packets", and a "compiler" that translates from
a LISP-like notation to "optimized" filter programs) but what I really
want is something that takes a high-level notion ("all packets between
host x and host y to or from tcp port telnet") and converts it directly
to a filter program.  (In many cases, the program could not be exact;
it would have to pass certain packets to the application for final
filtering.)  Anyway, consider this an "open problem" and not really
amenable to a standard.

Step #3 (packet reception loop) is hard to standardize mostly because
what goes on in the middle of the loop is quite application-specific.
Probably a clever up-call interface design would work.  Still, this
is the one part that I don't even have in my own libraries, because
each of my applications does it slightly differently.

If someone wanted to get started on this, I wouldn't mind participating.

-Jeff