tap(4) - NetBSD Manual Pages

Command:
Section:
Arch:
Collection:
>>>
TAP(4)                  NetBSD Kernel Interfaces Manual                 TAP(4)


NAME

     tap -- Ethernet tunnel software network interface


SYNOPSIS

     pseudo-device tap


DESCRIPTION

     The tap driver allows the creation and use of virtual Ethernet devices.
     Those interfaces appear just as any real Ethernet NIC to the kernel, but
     can also be accessed by userland through a character device node in order
     to read frames being sent by the system or to inject frames. In that
     respect it is very similar to what tun(4) provides.

   INTERFACE CREATION
     Interfaces may be created in two different ways: using the ifconfig(8)
     create command with a specified device number, or its ioctl(2) equiva-
     lent, SIOCIFCREATE, or using the special cloning device /dev/tap.

     The former works the same as any other cloning network interface: the
     administrator can create and destroy interfaces at any time, notably at
     boot time.  This is the easiest way of combining tap and bridge(4).
     Later, userland will actually access the interfaces through the specific
     device nodes /dev/tapN.

     The latter is aimed at applications that need a virtual Ethernet device
     for the duration of their execution.  A new interface is created at the
     opening of /dev/tap, and is later destroyed when the last process using
     the file descriptor closes it.

   CHARACTER DEVICES
     Whether the tap devices are accessed through the special cloning device
     /dev/tap or through the specific devices /dev/tapN, the possible actions
     to control the matching interface are the same.

     When using /dev/tap though, as the interface is created on-the-fly, its
     name is not known immediately by the application.  Therefore the
     TAPGIFNAME ioctl is provided.  It should be the first action an applica-
     tion using the special cloning device will do.  It takes a pointer to a
     struct ifreq as an argument.

     Ethernet frames sent out by the kernel on a tap interface can be obtained
     by the controlling application with read(2).  It can also inject frames
     in the kernel with write(2).  There is absolutely no validation of the
     content of the injected frame, it can be any data, of any length.

     One call of write(2) will inject a single frame in the kernel, as one
     call of read(2) will retrieve a single frame from the queue, to the
     extent of the provided buffer.  If the buffer is not large enough, the
     frame will be truncated.

     tap character devices support the FIONREAD ioctl which returns the size
     of the next available frame, or 0 if there is no available frame in the
     queue.

     They also support non-blocking I/O through the FIONBIO ioctl.  In that
     mode, EWOULDBLOCK is returned by read(2) when no data is available.

     Asynchronous I/O is supported through the FIOASYNC, FIOSETOWN, and
     FIOGETOWN ioctls.  The first will enable SIGIO generation, while the two
     other configure the process group that will receive the signal when data
     is ready.

     Synchronisation may also be achieved through the use of select(2),
     poll(2), or kevent(2).

   ETHERNET ADDRESS
     When a tap device is created, it is assigned an Ethernet address of the
     form f2:0b:a4:xx:xx:xx.  This address can later be changed using
     ifconfig(8) to add an active link layer address, or directly via the
     SIOCALIFADDR ioctl on a PF_LINK socket, as it is not available on the
     ioctl handler of the character device interface.

   LINK STATE
     When an application has opened the tap character device the link is con-
     sidered up, otherwise down.  As such, it is best to open the character
     device once connectivity has been established so that Duplicate Address
     Detection, if applicable, can be performed.  If connectivity is lost, the
     character device should be closed.


FILES

     /dev/tap        cloning device
     /dev/tap[0-9]*  individual character device nodes


SEE ALSO

     bridge(4), l2tp(4), tun(4), vether(4), ifconfig(8)


HISTORY

     The tap driver first appeared in NetBSD 3.0.


CAVEATS

     Starting from NetBSD 10.0, the tap driver can no longer be used as a
     bridge(4) endpoint because it supports a link state based on if it has
     been opened or not.  Use the vether(4) driver instead as it's been
     explicitly designed for this purpose.

NetBSD 10.99                      May 2, 2022                     NetBSD 10.99