TAP(4) | Device Drivers Manual | TAP(4) |
tap
— Ethernet
tunnel software network interface
pseudo-device tap
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.
Interfaces may be created in two different ways: using the
ifconfig(8)
create
command with a specified device number, or
its ioctl(2) equivalent,
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.
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 application 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).
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.
When an application has opened the tap
character device the link is considered 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.
The tap
driver first appeared in
NetBSD 3.0.
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.
May 2, 2022 | NetBSD 10.99 |