EF(4) BSD Kernel Interfaces Manual EF(4)NAME
ef -- pseudo-device driver providing support for multiple Ethernet frame types
SYNOPSIS
device ef
DESCRIPTION
The ef pseudo-device driver clones each Ethernet type device with four additional interfaces. Each of them is capable to send or receive
only one predefined frame type.
Names for the new interfaces are created by adding a fN suffix to an existing device name. Where N is a device unit which can have one of
the following values:
0 interface with an Ethernet_II frame
1 interface with a Novell Ethernet_802.3 frame
2 interface with an Ethernet_802.2 frame
3 interface with an Ethernet_802.2/SNAP frame support.
For example, device ed0 will be populated with four devices: ed0f0, ed0f1, ed0f2 and ed0f3.
After that, each device can be configured as usual:
# ifconfig ed0f1 ipx 0x105
This will configure IPX protocol with network number 0x105 and Ethernet_802.3 frame type.
Please note that it is impossible to configure the IPX protocol on the parent ed0 device after the if_ef.ko driver has been loaded.
If the parent interface is not configured for any other protocol (IP for example), subinterfaces will not function. To avoid that, the par-
ent interface should be manually marked as ``up'':
# ifconfig ed0 up
EXAMPLES
The ef driver can be loaded via the loader.conf(5) file:
if_ef_load="YES"
In this case, ordinary interface configuration commands can be used in the rc.conf(5) file:
network_interfaces="ed2 lo0 tun0 ed2f0 ed2f1"
ifconfig_ed2f0_ipx="ipx 0x101"
ifconfig_ed2f1_ipx="ipx 0x102"
DIAGNOSTICS
None.
SEE ALSO ipx(3), ifconfig(8)AUTHORS
Boris Popov <bp@FreeBSD.org>.
CAVEATS
Avoid to configure the parent Ethernet device for the IPX protocol, after the ef driver is loaded.
BSD June 20, 1999 BSD
Check Out this Related Man Page
TAP(4) BSD Kernel Interfaces Manual TAP(4)NAME
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