Re: Extra DLT types required for opensolaris DLPI DL

[Alexander Dupuy <alex.dupuy () mac com>]

Guy Harris wrote:
> Arguably, a library for writing link-layer protocols in userland, 
> separate from libpcap, would be useful.  For example:
>
>     on a number of platforms, the former library would bind to the 
> low-level networking stack with a particular SAP rather than 
> "promiscuously" for all SAPs (I think that would be the case on Linux, 
> Windows with the WinPcap driver and packet.dll library, and systems 
> with DLPI - and, at least on HP-UX, where I think you can have only 
> one DLPI stream in "SAP promiscuous" mode, it'd work better that way);
>
>     for packet capturing, you usually want buffering done in the 
> kernel, so that you get multiple packets per read, while, when 
> implementing a link-layer protocol, you usually want packets delivered 
> as soon as they arrive;
>
>     for some link-layer protocols, you might want the details of 
> particular link layers hidden from your implementation, e.g. Ethernet 
> types vs. 802.2+SNAP headers.
>
> I really wish I had time to implement that right now.

Actually, I already wrote something very much like that 20 years ago 
(admittedly, for a number of hardware/OS platforms that you would be 
hard-pressed to put together today).  For what it's worth, I implemented 
a generic packet-sending link layer protocol  library in userspace, with 
support for SunOS, Ultrix, and BSD with the Stanford enetfilter (while 
not exactly predating BPF, it did predate BPF's acceptance into 
main-line BSD distros).  I did this back in the late '80s as a 
portability layer for a reverse-engineered implementation of the DEC 
RBMS bridge management protocol, which operated at the link-layer 
(Ethernet) and provided the ability to get management statistics from 
DEC LanBridges.  The library did not actually support 802.2+SNAP or 
802.3 - it was a pure Ethernet access library.

Amazingly enough, it is still out there on the internet, although if you 
didn't know it, you would never be able to find it.  You can download a 
release of it from http://moscoso.org/pub/unix-c/networks/etherlib.tar.Z 
(it's in compress(1) format, which dates it, but gunzip is able to 
uncompress it just fine).

Just for kicks, here's a snippet of the etherlib man page:

DESCRIPTION
      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 4.3 BSD systems, they 
are implemented using the Stanford  enetfilter device driver in the 
user-contributed software.  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.

The function ether_open returns a  file  descriptor  for  the  ethernet 
device  specified  by  name  (such  as  "le0" or "ie1").  If no name is 
given, the default ethernet interface is used.  Packets for the  
ethernet  address  address  will  be received in addition to packets for 
the local ethernet address and broadcasts; this  is  useful  for  
multicast protocols.   Superuser  privilege  is needed to use this 
feature.  Only packets with a protocol type of type will be received  
or  sent.   This value should be passed in host byte order, not in 
network byte order.

[The Ethernet configuration test protocol (CTP, ethertype 0x9000) is an 
obscure network protocol that allowed you to effectively source route a 
packet among various ethernet interfaces on the same LAN - the 
echo/relay function was implemented in the DEC Ethernet interface 
hardware/firmware - and served as a fancy Ethernet-level ping; a test 
program is included in etherlib.  Cisco devices apparently still use it 
for loopback tests 
(http://www.mail-archive.com/cisco () groupstudy com/msg30992.html), 
although the protocol allowed for more sophisticated diagnostics, 
routing through several CTP-capable hosts, like VAXen.]

@alex

--
mailto:alex.dupuy () mac com

-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.