Linux and UNIX Man Pages

Linux & Unix Commands - Search Man Pages

tap(4) [netbsd man page]

TAP(4)							   BSD Kernel Interfaces Manual 						    TAP(4)

tap -- virtual Ethernet device 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, but the added Ethernet layer allows easy integration with machine emulators or virtual Ethernet networks through the use of bridge(4) with tunneling. 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 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). 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. FILES
/dev/tap cloning device /dev/tap[0-9]* individual character device nodes SEE ALSO
bridge(4), etherip(4), tun(4), ifconfig(8) HISTORY
The tap driver first appeared in NetBSD 3.0. BSD
March 10, 2009 BSD

Check Out this Related Man Page

ETHERIP(4)						   BSD Kernel Interfaces Manual 						ETHERIP(4)

etherip -- EtherIP tunneling device SYNOPSIS
pseudo-device etherip DESCRIPTION
The etherip interface is a tunneling pseudo device for Ethernet frames. It can tunnel Ethernet traffic over IPv4 and IPv6 using the EtherIP protocol specified in RFC 3378. The only difference between an etherip interface and a real Ethernet interface is that there is an IP tunnel instead of a wire. Therefore, to use etherip the administrator must first create the interface and then configure protocol and addresses used for the outer header. This can be done by using ifconfig(8) create and tunnel subcommands, or SIOCIFCREATE and SIOCSLIFPHYADDR ioctls. Packet format Ethernet frames are prepended with a EtherIP header as described by RFC 3378. The resulting EtherIP packets will be encapsulated in an outer packet, which may be either an IPv4 or IPv6 packet, with IP protocol number 97. Ethernet address When a etherip device is created, it is assigned an Ethernet address of the form f2:0b:a5:xx:xx:xx. This address can later be changed through a sysctl node. The sysctl node is<iface>. Any string of six colon-separated hexadecimal numbers will be accepted. Reading that node will provide a string representation of the current Ethernet address. Security The EtherIP header of incoming packets is not checked for validity. This is because there seems to be some confusion about how such a header has to look like. For outgoing packets, the header is set up the same way as done in OpenBSD, FreeBSD, and Linux to be compatible with those systems. Converting from previous implementation A tunnel configured for the previous (undocumented) implementation will work with just renaming the device from gif to etherip. SEE ALSO
bridge(4), gif(4), inet(4), inet6(4), tap(4), ifconfig(8) HISTORY
The etherip device first appeared in NetBSD 4.0, it is based on tap(4), gif(4), and the former gif-based EtherIP implementation ported from OpenBSD. BUGS
Probably many. There is lots of code duplication between etherip, tap(4), gif(4), and probably other tunnelling drivers which should be cleaned up. BSD
November 23, 2006 BSD
Man Page