Agere (Lucent) Orinoco

Wireless networking is far older than the 802.11 standard. Several proprietary approaches had been released and were gaining a foothold in the market in the early 1990s. One of the first notable products was the NCR WaveLAN, released when NCR was a division at AT&T.[*] When Lucent was spun off from AT&T in 1996, the WaveLAN division, like most communications product manufacturing at AT&T, was made a part of Lucent.

[*] NCR, which was founded in 1884 as the National Cash Register Company, was acquired by AT&T in 1991. I can only assume that a cash register company was interested in wireless networking because it would enable cash registers to be placed anywhere without wiring.

Early WaveLAN hardware was a completely proprietary system. After 802.11 was finally standardized in 1997, new hardware that complied with the standard was sold under the WaveLAN brand. To distinguish the standards-compliant cards from the proprietary cards, the former were called "WaveLAN IEEE" cards, while the latter were simply "WaveLAN" cards.

As the market for 802.11 hardware continued to develop, Lucent decided to rename the WaveLAN division under another brand name. The new name, Orinoco, comes from the third largest river system in the world. During the rainy season in South America, the Orinoco swells with fresh rainfall flowing in from over 200 tributaries. At its peak, the river grows to over 10 miles wide and more than 300 feet deep. Nearly 1,000 miles of the Orinoco's 1,300 miles are navigable; it is no wonder that the river's name is derived from the native words for "a place to paddle."

Lucent's initial strategy for support on open source platforms was to offer a choice of drivers. A closed-source proprietary binary driver, wavelan2_cs, provided full functionality, and a second, less functional open source driver, wvlan_cs, was made available under the GPL. wvlan_cs was based on a low-library provided with the closed source driver, and it was an evolutionary dead-end. Rather than continue along that path, wvlan_cs was rewritten with new low-level operations and became orinoco_cs in Linux kernel version 2.4. (orinoco_cs was originally known as dldwd_cs, which stood for David's Less Dodgy WaveLAN Driver!)

In addition to the WaveLAN cards and any OEM versions of WaveLAN cards, orinoco_cs contains basic support for some PRISM-2-based cards and Symbol cards that use the same MAC chipset. orinoco_cs has been part of the Linux kernel distribution since kernel Version 2.4.3.

Compiling and Installing

All distributions based on the 2.4 and later kernels include orinoco_cs. In many cases, it will be possible to use the driver that shipped with your kernel. The major exception is if you plan to run xsupplicant and need to apply the key management patch, which will be discussed later.

PCMCIA configuration

Older distributions may ship with the wvlan_cs driver still enabled. To change the driver used by the distribution, it is sufficient to change the module binding the PCMCIA configuration. The author of orinoco_cs supplies a file, hermes.conf, which contains card definitions for the cards supported by orinoco_cs. Because hermes.conf ends in .conf, it is sourced by the line at the end of /etc/pcmcia/config that reads all .conf files. However, to avoid binding conflicts, you must comment out all the lines that bind the older wvlan_cs driver to newly inserted cards. Alternatively, it is sufficient to edit the definition of your wireless card to bind the orinoco_cs driver after grabbing identification information from the output of dump_cis:

 # in hermes.conf
 #
 card "Lucent Technologies Wavelan/IEEE"
 version "Lucent Technologies", "WaveLAN/IEEE"
 bind "orinoco_cs"

 # from standard /etc/pcmcia/config
 #
 # card "Lucent Technologies WaveLAN/IEEE"
 # version "Lucent Technologies", "WaveLAN/IEEE"
 # bind "wvlan_cs"

 

Doing it yourself

This is part of the kernel, so you generally don't need to install it unless you're looking for a particular bug fix or feature enhancement. The most common reason to recompile the driver is a requirement to support dynamic WEP with 802.1X authentication. xsupplicant distributes a patch to be applied for rekeying. Firmware updates may also be necessary to support dynamic keys. I have used firmware version 8.42. Later versions almost certainly work, but earlier versions may not.

Requirements are straightforward. The code itself is fetched from the distribution site at http://ozlabs.org/people/dgibson/dldwd/. Make sure that you have a copy of patch to apply the patches of interest (the rekey patch is not required in version 0.15rc2):

 gast@bloodhound:~$ cd orinoco-0.13e
 gast@bloodhound:~/orinoco-0.13e$ patch -p1 <
 ../rekey_patch_orinoco-0.13e
 patching file orinoco.c
 patching file orinoco.h
 msg@bloodhound:~/orinoco-0.13e$ make
 (build messages snipped)
 root@bloodhound:/home/msg/orinoco-0.13e# make install
 if [ -d /etc/pcmcia ]; then install -m 644 -o 0 -g 0 hermes.conf /etc/pcmcia/hermes.conf; fi
 mkdir -p /lib/modules/2.4.26/kernel/drivers/net/wireless
 for f in hermes.o orinoco.o orinoco_cs.o orinoco_plx.o orinoco_tmd.o orinoco_pci.o; do 
 if test -e /lib/modules/2.4.26/pcmcia/$f; then 
 install -m 644 -o 0 -g 0 $f /lib/modules/2.4.26/pcmcia/$f; 
 else 
 install -m 644 -o 0 -g 0 $f /lib/modules/2.4.26/kernel/drivers/net/wireless/$f; 
 fi; 
 done
 depmod -a

At the end of the build process, the system has several kernel modules: orinoco_cs.o, the PCMCIA interface; orinoco.o, the hardware driver; and hermes.o, the driver for the MAC chip.

Configuring the orinoco_cs Interface

Configuration of orinoco_cs is identical to the configuration of wvlan_cs. When the card is inserted, the /etc/pcmcia/wireless script is run, using the configuration options in /etc/pcmcia/wireless.opts. The wireless script is a frontend to the iwconfig program. Editing fields in wireless.opts sets the arguments to iwconfig. For details on configuring the options to iwconfig, see the previous section on the wvlan_cs driver.

Resetting on WEP Key Installation

Not all card manufacturers have committed to supporting Linux. Revealing intellectual property by giving away driver source code is usually the major concern. Finding the engineering time to write, maintain, and support drivers given to the user community is another.

When using dynamic WEP on Linux, the 802.1X supplicant derives WEP keys from the authentication exchange, and then loads them into the driver. Up until 1999, many cards did not support the dynamic provisioning of keys, and needed to reset the microcontroller in the card to make the new key take effect. Drivers were written with this assumption, and the code that updated keys would reset the hardware.

Resetting the hardware when a key is installed is undesirable behavior with dynamic WEP. Once the authentication has completed, a key must be installed. If the driver resets after key installation, the link will bounce. In many cases, the AP will note the link bounce and require a new authentication. Once the supplicant detects the link state change, it will run the authentication again to derive a new key. After the new authentication completes, the supplicant resets the card to install the new key, starting the cycle over yet again.

Most interface cards have firmware upgrades available which eliminate the need to reset the hardware after key installation. Once the right version of firmware is in place, the driver needs to be updated to a dynamic WEP-capable version that does not send reset commands.

If dynamic WEP is not working because the card resets after the authentication succeeds, check either the source code or the online forums for the driver for your card to see if an update or patch is required.