p 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 .Nm and .Xr bridge 4 . Later, userland will actually access the interfaces through the specific device nodes
p 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
a /dev/tap , and is later destroyed when the last process using the file descriptor closes it. .Ss CHARACTER DEVICES Whether the .Nm devices are accessed through the special cloning device
a /dev/tap or through the specific devices
a /dev/tapN , the possible actions to control the matching interface are the same.
p When using
a /dev/tap though, as the interface is created on-the-fly, its name is not known immediately by the application. Therefore the .Dv 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 .Ft struct ifreq as an argument.
p Ethernet frames sent out by the kernel on a .Nm interface can be obtained by the controlling application with .Xr read 2 . It can also inject frames in the kernel with .Xr write 2 . There is absolutely no validation of the content of the injected frame, it can be any data, of any length.
p One call of .Xr write 2 will inject a single frame in the kernel, as one call of .Xr 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.
p .Nm character devices support the .Dv FIONREAD ioctl which returns the size of the next available frame, or 0 if there is no available frame in the queue.
p They also support non-blocking I/O through the .Dv FIONBIO ioctl. In that mode, .Er EWOULDBLOCK is returned by .Xr read 2 when no data is available.
p Asynchronous I/O is supported through the .Dv FIOASYNC , .Dv FIOSETOWN , and .Dv FIOGETOWN ioctls. The first will enable .Dv SIGIO generation, while the two other configure the process group that will receive the signal when data is ready.
p Synchronisation may also be achieved through the use of .Xr select 2 , .Xr poll 2 , or .Xr kevent 2 . .Ss ETHERNET ADDRESS When a .Nm 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 .Xr ifconfig 8 to add an active link layer address, or directly via the .Dv SIOCALIFADDR ioctl on a .Dv PF_LINK socket, as it is not available on the ioctl handler of the character device interface. .Ss LINK STATE When an application has opened the .Nm 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. .Sh FILES l -tag -compact -width /dev/tap[0-9]* t Pa /dev/tap cloning device t Pa /dev/tap[0-9]* individual character device nodes .El .Sh SEE ALSO .Xr bridge 4 , .Xr l2tp 4 , .Xr tun 4 , .Xr vether 4 , .Xr ifconfig 8 .Sh HISTORY The .Nm driver first appeared in .Nx 3.0 . .Sh CAVEATS Starting from .Nx 10.0 , the .Nm driver can no longer be used as a .Xr bridge 4 endpoint because it supports a link state based on if it has been opened or not. Use the .Xr vether 4 driver instead as it's been explicitly designed for this purpose.