zessel@incas.informatik.uni-kl.de (Holger Zessel AG Nehmer) (05/25/90)
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. > --Vince yep. Someone did that already ! It was in the news in the last year i believe. There was an Instructions file included which should suffice hopefully all your questions: =<cut here>==================================================================== This ethernet access library is a part of the Columbia Netmate project which is being released as a useful component in its own right. These functions provide access to the raw ethernet for user-level programs. On Suns, they are implemented using NIT(4p) (network interface tap). While they do not provide the full functionality of NIT, these functions do run on both the socket- and streams-based NIT implementations. On Ultrix systems, they are implemented using DLI (data link interface). On Berkeley systems, they are implemented using the Stanford enetfilter available as user-contributed software in the 4.3 BSD release. These functions are not designed to be used for ethernet monitoring, but rather for programs implementing ethernet protocols such as RARP, or the Ethernet configuration test protocol. It comes with a manual page, and both a GNU makefile and a regular one. If you are on a BSD system with the enetfilter, you will have to create some new device files before you can build or use this library. Because there is no way to map between the interface names ("il0", "de0", etc.) used by most programs and the old enetfilter device names (/dev/enet0, /dev/eneta0, etc.), this library uses a different convention for enetfilter device names, using device files in the /dev/enet/ directory. Therefore, you should create or link an enetfilter device in /dev/enet for each ethernet interface, with names like /dev/enet/il0, /dev/enet/de0, etc. The minor device numbers for these files will correspond to the order in which they are found by the kernel. This order is the same as in the config file, except that devices configured into the kernel but not present are not counted. You can look at the kernel startup messages in /usr/adm/messages to see the order of ethernet devices; the ethernet addresses are also printed out there, and you can check those against the results of the ethertest program here. If you have GNU make, you should be able to say "gmake" in this directory, and it will build the library for your system in a subdirectory. You may want to edit the GNUmake.config file to specify various options (such as installation directories, cc vs. gcc, etc.) Once you are satisfied that it has built correctly, you can say "gmake install". If you don't have GNU make, you will have to cd to the src subdirectory, and edit the Makefile there to reflect your system configuration. Once you have done this, you can say "make" to build the library, and "make install" to install it. If you encounter bugs, or are interested in porting this library to another ethernet access interface, please contact me. Alexander Dupuy 480 C.S.B. Computer Science Dept. Columbia University New York City 10027-6699 <dupuy@cs.columbia.edu> !rutgers!cs.columbia.edu!dupuy This library can be obtained via anonymous FTP from columbia.edu or cs.columbia.edu, in the file pub/etherlib.tar.Z. ==<cut here too>============================================================== Hope that helps ! Holger ---------------------------------------------------------------- Holger Zessel, zessel@informatik.uni-kl.de or zessel%informatik.uni-kl.de@relay.cs.net (from usa) or uucp: ...!uunet!unido!uklirb!incas!zessel Fachbereich Informatik, SFB124-D1 Universitaet Kaiserslautern, West-Germany
mogul@jove.pa.dec.com (Jeffrey Mogul) (05/26/90)
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