The Challenges of Dynamic Network Interfaces
Total Page:16
File Type:pdf, Size:1020Kb
The Challenges of Dynamic Network Interfaces Brooks Davis The FreeBSD Project Seattle, WA brooks@{aero,FreeBSD}.org Abstract vices to the modern age of near complete dynamism. Following this history, the problems caused by this dynamism are discussed in detail. Then solutions to On early BSD systems, network interfaces were some of these problems are proposed and analyzed, static objects created at kernel compile time. To- and advice to implementers of userland applications day the situation has changed dramatically. PC is given. Finally, the issues are summarized and fu- Card, USB, and other removable buses allow hard- ture work is discussed. ware interfaces to arrive and depart at run time. Pseudo-device cloning also allows pseudo-devices to be created dynamically. Additionally, in FreeBSD and Dragonfly, interfaces can be renamed by the ad- 2 History ministrator. With these changes, interfaces are now dynamic objects which may appear, change, or dis- appear at any time. This dynamism invalidates a In early versions of UNIX, the exact set of devices number of assumptions that have been made in the on the system had to be compiled in to the kernel. If kernel, in external programs, and even in standards the administrator attempted to use a device which such as SNMP. This paper explores the history of was compiled in, but not installed, a panic or hang the transition of network interfaces from static to dy- was nearly certain. This system was easy to pro- namic. Issues raised by these changes are discussed gram and efficient to execute. Unfortunately, it was and possible solutions suggested. not convenient to administer as the set of available interfaces grew. 4.1BSD, released June, 1981, included a solution to 1 Introduction this problem called autoconfiguration [McKusick2]. Autoconfiguration is a process by which devices are detected at boot time [McKusick1]. Under autocon- In the early days of UNIX, network interfaces were figuration, each system bus is probed for devices static. The drivers were compiled into the kernel and those devices that have drivers in the system along with their hardware addresses. The set of de- are enabled. The process of identifying devices is vices on each machine changed only when the admin- called probing and devices which are found in prob- istrator modified the kernel. Those days are long ing are attached. The procedure used to probe de- gone. Today devices, hardware and virtual, may vices varies by bus. On some buses, such as non- come and go at any time. This dynamism creates PnP ISA, compiled-in addresses are probed and if a number of problems for both kernel and applica- they respond as expected the device is assumed to tion developers. be there. With more advanced buses such as PCI or SCSI, devices are self-identifying. PCI devices This paper discusses how the current dynamism are identified by an ID number composed of a ven- came about in FreeBSD, documents the problems dor portion and a vendor allocated product portion. it causes, and proposes solutions to some of those SCSI devices are identified by a device class and a problems. The following section details the history free form string. With autoconfiguration, all devices of dynamic devices from the era of purely static de- to be used still had to be compiled in to the kernel, Published in the Proceedings of EuroBSDCon 2004 but a super set could be used enabling one kernel to c 2004 The Aerospace Corporation work with multiple system configurations. c 2004 Brooks Davis In FreeBSD 2.0, the LKM (Loadable Kernel Mod- port was introduced in FreeBSD 5.2. Being wireless, ules) system modeled after the facility in SunOS Bluetooth devices are inherently dynamic. While 4.1.3 was implemented by Terry Lambert [man4-2]. not currently supported, hot plug PCI, Compact The LKM system freed administrators from the re- PCI, PCI Express, and Express Card all support quirement that all device drivers be compiled into a some form of hot insertion and removal. Compact single static kernel. Now devices could be loaded at PCI is of particular interest because it provides the run time. This enabled support for a number of new administrator with a button to press to indicate their features. Devices manufactured after the kernel was intention to remove a device and a light the OS can first built could be supported without a full rebuild. use to notify the administrator that the device in Pseudo devices could be added on the fly. And some inactive and removal is now safe. development testing could be done without a re- boot1. With LKM came the possibility of devices I anticipate that as bus standards evolve, an increas- coming and going during run time. Generalized sup- ing number will support hot plug devices. Further, port for detaching interfaces was not implemented I expect that in the not too distant future, hot plug until Doug Rabson replaced LKM with the dynamic interfaces will be the norm with the exception of in- kernel linker (KLD) and newbus in FreeBSD 3.0. tegrated interfaces on motherboards. As part of this process, he implemented a primitive version of if detach(). The KLD interface is an In early autoconfiguration implementations, a finite enhanced module system based on dynamic linking number of units was statically allocated when the of ELF binaries. kernel or module was compiled. Devices implement- ing these sorts of preallocations are referred to as While modules introduced the possibility of dynamic count devices due to the kernel configuration direc- interfaces, dynamic interfaces were first used by or- tive used to declare them. Today, this sort of hard dinary people with the introduction of PC Card coding is frowned upon unless there can only be (PCMCIA) devices. The PC Card standard sup- a small, fixed number of devices (usually one). In ports hot insertion and removal of cards. Through FreeBSD 6.x, support for count devices will be re- use of short pins, a few milliseconds of warning that moved from the config program. This will require a device is departing are provided, but otherwise, that device counts either be fully dynamic or speci- they come and go at will. In the 2.x time frame, fied at boot time. With physical devices, new driver PAO2 was developed to provide PC Card support instances are allocated and destroyed as hardware is to FreeBSD [PAO]. Fairly functional support was added and removed so the removal of count devices available based on the work in PAO in FreeBSD 3. is no hardship. With the release of FreeBSD 4, PAO development ceased because all major changes had been incorpo- In FreeBSD 3.4 the netgraph system was introduced- rated into the FreeBSD tree. CardBus support was netgraph(4). Netgraph allows dynamically config- added in FreeBSD 5.0 and is currently fairly mature ured nodes implementing networking functions to be (roughly speaking, CardBus is to PCI what PC Card configured into arbitrary graphs. One of the stan- is to ISA.) dard nodes is ng iface(4) which appears as a virtual network interface. Since netgraph nodes are config- In FreeBSD 4.0, support for USB Ethernet devices ured dynamically using ngctl(8) [man8], this is an- was added. Like PC Card devices, USB devices may other source of dynamic interfaces. be attached and detached at will. For pseudo-devices such as the loopback interface, Since the introduction of USB networking devices, lo(4), most devices are created by the network in- a number of new types of removable networking de- terface cloning code, referred to as if clone. Net- vices have appeared. The fwe(4) [man4], Ethernet work interface cloning was introduced in FreeBSD over FireWire driver appeared in 5.0 and was later 4.4. Typically, a cloned device is created with a merged in to 4.8. The fwip(4), IP over FireWire command like ”ifconfig vlan create” which cre- interface, implements RFC 2734 [RFC2734], IPv4 ates a new vlan interface and prints its name. This over IEEE1394, and RFC 3146 [RFC3146], IPv6 over creates a number of interesting opportunities such IEEE1394; it was introduced in 5.3. Bluetooth sup- as an IPv6 tunnel server that creates gif(4) devices on demand. The initial cloning code in FreeBSD 1Assuming that the developer was fortunate enough to was obtained from NetBSD and has since been ex- make an error that did not result in a kernel panic. tended to allow cloned devices to match more com- 2According to the PAO FAQ, “PAO stands for nomads.” plex names in the ifconfig(8) create request. Ini- terfaces. tially, cloned devices could only be created with 2. A server with hot swappable network interfaces. a command of the form ”ifconfig <drivername> [<unit>] create”. With enhanced cloning sup- 3. An IPv6 tunnel server. port, devices may support more complex names such as <ethernet_interface>.<vlan_tag> for These systems are sufficient to expose most of the vlan(4). issues of dynamic network interfaces. A new feature of FreeBSD 5.2 and DragonFly BSD is The laptop I will consider has a USB Ethernet inter- the ability to rename network interfaces. This can be face supported by the aue(4) driver and a PC Card useful to allow an administrator to hide the details of wireless device supported by the wi(4) driver. This interface types or to easily identify the purpose of a situation presents several challenges. These chal- dynamically created interface. Returning to the ex- lenges derive from the fact that these interfaces may ample of a gif(4) based tunnel server, tunnels could come and go at arbitrary times. From the user’s be named after registered users; so instead of gif42, perspective there will be three significant problems.