Re: libpcap timeout weirdness

[Guy Harris <guy () alum mit edu>]

On Mar 24, 2013, at 2:59 PM, Guy Harris <guy () alum mit edu> wrote:

> Arguably, something like Linux's PF_PACKET sockets would be best for people trying to implement protocols atop the 
> link-layer, as (either when not in memory-mapped mode, or when in TPACKET_V1 or TPACKET_V2 memory-mapped mode) it has 
> no timeouts, but does have a buffer, so that you don't have to *immediately* read the packet or have further packets 
> dropped due to being out of buffer space.  (In TPACKET_V3 mode, it appears to work more like, err, umm, BPF, with 
> entire buffers full of packets being delivered, and with a timeout to keep it from waiting forever for a buffer to 
> fill up; I think that mode was introduce for the benefit of packet capture.)

After a bit of a dive into xnu, it appears that there might be something *somewhat* similar to PF_PACKET sockets in OS 
X - PF_NDRV sockets.

The documentation is somewhat, umm, sparse.  See, for example, /usr/include/net/ndrv.h.

You'd presumably open a socket with a protocol family of PF_NDRV and type SOCK_RAW, bind it to a network adapter (the 
struct sockaddr_ndrv structure has an interface name in it, and that's what you'd use in a bind; set the family to 
AF_NDRV), and then use setsockopt() calls to do the *real* bind, i.e. binding it to a particular protocol type.

The socket level for setsockopt() would be SOL_NDRVPROTO, and the option would be NDRV_SETDMXSPEC to bind and 
NDRV_DELDMXSPEC to unbind.  They both take a struct ndrv_protocol_desc as an argument.  The version member of that 
structure should be set to NDRV_PROTOCOL_DESC_VERS; the protocol_family member should, I guess, be set to some number 
you pick to identify that protocol (maybe it's only used when unbinding), and the rest is a counted list of struct 
ndrv_demux_desc's, each of which specifies a link-layer protocol to bind to the socket.

That structure has:

        type, which is an indication of the type of protocol specification:

                NDRV_DEMUXTYPE_ETHERTYPE - an Ethertype (which is what you'd use);

                NDRV_DEMUXTYPE_SAP - an 802.2 header (DSAP, SSAP, and 1st byte of the packet type);

                NDRV_DEMUXTYPE_SNAP - a SNAP type (OUI and protocol ID);

              all in network byte order;

        length, which is the length of the protocol specification;

        a union for the various protocol specifications.

I have not tried any of this.

        https://github.com/okunnig-/Foobar/blob/master/main.c

is a very simple example, but it doesn't do any protocol type binding.  Googling for NDRV_DEMUXTYPE_ETHERTYPE might 
find some better examples.

(What might be Really Nice, as I've said on occasion, would be a "access to particular link-layer packets" library, for 
use by programs implementing protocols atop the link layer (rather than by programs running as packet capture and/or 
injection tools), which would use whatever mechanisms are appropriate for that.  Those mechanisms might be different 
from the ones used for packet capture:

        on Linux, packet capture might use TPACKET_V3 PF_PACKET/SOCK_RAW sockets not bound to a particular protocol 
type value, while protocols atop the link layer might use non-memory-mapped or TPACKET_V2 PF_PACKET/SOCK_DGRAM or 
SOCK_RAW sockets bound to a particular protocol type value;

        on AIX and Solaris 11, packet capture might use BPF while protocols atop the link-layer would use DLPI and bind 
to particular protocol type values;

        on other systems with DLPI, packet capture might use SAP-promiscuous DLPI devices while protocols atop the 
link-layer would use DLPI and bind to particular protocol type values;

        on OS X, packet capture might use BPF while protocols atop the link-layer would use PF_NDRV sockets;

etc..)
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers