| TAP(4) | Device Drivers Manual | TAP(4) | 
tap —
pseudo-device tap
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.
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.
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).
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.
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.
tap driver first appeared in NetBSD
  3.0.
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.0 |