Linux on the Air
Filanet is a venture capital funded startup company that, like many other companies, saw the advantages of basing their software architecture on an embedded version of Linux. The benefits were quite clear: a familiar and flexible operating system with the power of the Open Source community behind it.
Filanet's CEO, along with a group of software and chip engineers, began Filanet with the idea of creating a simple and inexpensive solid-state appliance that would provide all of the networking services a small office might need. This would include a custom ASIC system-on-a-chip design with a number of I/O interfaces and would run an embedded version of Linux, µClinux, at its core. A simple and elegant web management interface and remote management capabilities would allow for easy installation and configuration.
After a couple years of development (and a bit of pain and suffering), this idea has turned into the Filanet InterJak Service Appliance (Figure 1).
Figure 1. Filanet InterJak 200 Service Appliance
A variety of basic and optional networking services have been added to the product line since, as well as a number of WAN connectivity options including ADSL, SDSL, ISDN and USB-attached V.90 modems.
In exploring sales opportunities, a quite interesting product request came from Trillion Digital Communications, a large wireless ISP covering much of the southeastern United States. They were looking for a solid-state, wireless broadband router that could support networking services such as firewalling, web content filtering, NAPT/NAT, dynamic routing, traffic shaping and remote management--all in a small reliable platform that could withstand the harsh environment of rural Alabama. Trillion had already gone through the experience of developing and supporting standard Linux-based rackmounted PCs, dealing with reliability, deployment and provisioning issues in the field, and were looking for a better solution.
Filanet, a typically aggressive startup, decided that this application was an absolute perfect fit for the InterJak product line. Well, it was a perfect fit except for the complete lack of a wireless interface. And, there were a couple of other complications. We (Filanet) had no idea what ``in the field'' really meant when talking about long-distance outdoor wireless connectivity in rural Alabama. Oh, and Trillion required a shipping solution in two months. No problem. Time to rattle engineering's cage.
Engineering quickly decided that doing any new hardware design was out of the question, due to the need for a quick solution. The InterJak product line did have a single PCI slot available, which was designed to support more traditional WAN connectivity such as ADSL and ISDN. We also had decided that using standard IEEE 802.11b (11Mbps) hardware would be the most flexible solution, as the growing wireless LAN opportunity was looking quite attractive. We had heard that it was possible to hit fairly long distances with standard 802.11b equipment (in conjunction with specialized directional antennas and amplifiers), and figured that 802.11b would work out fine for last-mile wireless broadband connectivity.
On the development side of things, we had to make several decisions:
How to jam a wireless PC Card into our available PCI slot?
Which wireless chipset to support?
What can be leveraged from the Linux Open Source community?
What are the major software development pieces?
How do we test and productize this wireless thing?
Since the PC Card didn't just fit (darn), we started looking at PCI sled adaptors for PC Cards. Numerous PCI to PC Card (16-bit and 32-bit) sled adaptors based on standard chipsets from TI, Ricoh and others were available on the market, but we rejected them for the following reasons.
The first was overkill. We really didn't want to port over the complete Linux card and socket services when all we were looking for was a PCI to 16-bit PC Card bridge. After all, the InterJak runs an embedded version of Linux that must fit into 8MB of Flash memory (with almost half of that Flash space reserved for the boot loader, configuration files and backup recovery image).
The second reason was that they were too expensive, and cheaper solutions were to be found somewhere. We then came across some very simple PCI to 16-bit PC Card sled adaptors based on the PLX 9052 chipset. The PLX 9052 is a simple PCI bus target interface chip providing a built-in ISA local bus, which is essentially the same thing as a 16-bit PC Card interface. These adaptor cards were available inexpensively from a number of Taiwanese OEM manufacturers and provided a very simple PCI interface to I/O mapped registers on the PC Card (Figure 3).
One PCI BAR (base address register) on the PLX 9052 provides access to control registers on the 9052 itself, a second BAR provides access to the PC Card attribute space and a third provides access to the PC Card 16-bit I/O mapped registers. Very little PCI bridge configuration was necessary to begin working with the wireless PC Card itself in our system.
There are several flavors of IEEE 802.11b chipsets on the market, with the majority based on an original MAC design from Choice Microsystems, making the software interface to these chipsets very similar. Filanet selected the Intersil PRISM 2 chipset because of the wide availability of wireless cards based on this chipset, and because Intersil makes available special wireless access-point firmware to off-load functions from the host processor, which is very nice for embedded systems.
There is strong support for wireless in the Linux community, and it was easy to see that porting established Linux open-source wireless drivers to the InterJak would be far more efficient than developing wireless support from the ground up. There were several available Linux wireless driver solutions supporting Intersil PRISM based 802.11b chipsets to choose from:
linux-wlan project from AbsoluteValue Systems: a complete, standards-based wireless LAN system, aimed at the Intersil PRISM chipset, supporting wireless access point (with Intersil tertiary AP firmware), station and ad hoc modes of operation (http://www.linux-wlan.com/linux-wlan/).
wvlan_cs driver: a wireless Linux driver targeting Agere Orinoco-based wireless cards, but also supporting Intersil PRISM cards to a limited degree (station and ad hoc modes). Not currently maintained--replaced with orinoco_cs driver (http://www.fasta.fh-dortmund.de/users/andy/wvlan/).
orinoco_cs driver: a newer wireless Linux driver supporting Agere Orinoco, Intersil PRISM and Symbol-based wireless cards (station and ad hoc modes). Included in the latest 2.4 Linux kernels (http://ozlabs.org/people/dgibson/dldwd/).
prism2 host ap driver: an experimental wireless driver for the Intersil PRISM 2 chipset, supporting a host-based software access point mode of operation. Also supports station and ad hoc modes (http://www.epitest.fi/Prism2/).
Wireless LAN Resources for Linux: the best place for an introduction to wireless technology and solutions for Linux (http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/).
Engineering evaluated several of the wireless driver solutions available and ultimately chose the linux-wlan drivers from AbsoluteValue. The linux-wlan package is targeted at the Intersil PRISM chipset, allows tremendous configuration flexibility through use of a standard 802.11b SNMP MIB-like interface and supports the ability to download the special wireless access-point firmware from Intersil. The driver supports all three modes of operation necessary to support wireless broadband point-to-point and point-to-multipoint applications.
After porting the base linux-wlan drivers and applications to the InterJak platform, fixing some minor ARM related alignment/packing issues and checking out basic functionality, it was time to turn this into a real wireless product.
Filanet needed to create some easy-to-use web management pages to support this new wireless interface, a web configuration handler and a simple /proc file interface for wireless status.
The web management pages for the wireless interface were created basically as an extension to InterJak's standard Ethernet configuration web pages, with support for wireless operation mode, network name (SSID), channel number, security settings and display of some current wireless status. A web-based pop-up window also was created to allow a real-time graphical display of link, signal and noise levels for the wireless link (Figure 4).
A web configuration handler dæmon also was created to accept input from the web management pages, provide current wireless status and control the two user-mode configuration utilities provided as part of the linux-wlan package. The wlanctl user-mode utility allows configuration of the linux-wlan driver through use of 802.11b MIB-like commands. The prism2dl utility is able to download the special tertiary access-point firmware from Intersil to the PC Card itself (into volatile memory), so that access-point functions may be off-loaded from the host CPU (in our case, our custom ASIC).
Here is a quick example of how the prism2dl and wlanctl utilities may be used to start the linux-wlan driver in wireless access-point mode on the InterJak. This 802.11b configuration complexity is hidden from the user behind a friendly web management interface and configuration handler dæmon:
prism2dl -r /etc/wlan/apfw.hex wlan0 wlanctl wlan0 dot11req_mibset mibattribute=dot11ExcludeUnencrypted=false wlanctl wlan0 dot11req_mibset mibattribute=dot11PrivacyInvoked=false wlanctl wlan0 dot11req_mibset mibattribute=dot11RTSThreshold=2347 wlanctl wlan0 dot11req_mibset mibattribute=dot11FragmentationThreshold=2346 wlanctl wlan0 dot11req_mibset mibattribute=p2CnfEnhSecurity=0 wlanctl wlan0 dot11req_start ssid=trillion bsstype=infrastructure beaconperiod=100 dtimperiod=3 cfpollable=false cfpollreq=false probedelay=100 dschannel=10 basicrate1=2 basicrate2=4 operationalrate1=2 operationalrate2=4 operationalrate3=11 operationalrate4=22
In addition to the web configuration handler, we created a simple proc file interface for the linux-wlan driver, allowing the configuration handler to quickly obtain the current state of the wireless interface:
cat /proc/net/wlan Device Cap Mode WEP Status Link Signal wlan0 1317 st off up 56 44 Noise ChNo TxRate BSSID SSID 0 10 4 00:06:25:03:0c:2d trillionSome of the challenges in developing this wireless support involved:
Debugging wireless packet loss and performance: with wireless, unless you have a very controlled environment, it's difficult to create a solid baseline for performance. Determining whether wireless packet loss is due to software driver issues, the wireless access point next door or the microwave in the kitchen is quite a challenge.
Fitting everything into limited Flash space: this is a challenge for anyone involved with embedded applications. For this project, it was necessary to compress the Intersil access-point firmware more efficiently, as it is 130KB in size. Converting S-record formatted firmware to binary and then gzipping it saved a lot of space.
Integrating wireless support into entire product (testing): this new wireless interface simply became a third network interface in our InterJak product (in addition to the two Ethernet interfaces). Testing and supporting this new interface with the large number of networking services available on the platform involved serious test time. The services requiring integration testing included routing, NAPT/NAT, firewall, network monitoring, traffic shaping, VPN, file and print sharing, and others (Figure 5).
Obtaining volume OEM wireless cards and antennas: sourcing and evaluating OEM wireless cards and antennas within a very short time frame was probably one of the greatest challenges. Suppliers generally require substantial lead times and quantity agreements, and it's difficult to properly evaluate the sample product quickly enough to commit volumes to an OEM supplier.
Now, for a bit of personal experience. One of the most interesting and challenging phases of any project is field-testing, and this project was no exception (Figures 6 and 7). About two months after beginning to work on the wireless InterJak product, I found myself on a plane heading to Mobile, Alabama to help install and test the product across wireless links of between five and fifteen miles in length. Watching Trillion technicians climb towers of 150 feet in height during Alabama summer days to install antennas and amplifiers was awe-inspiring (and tiring just to watch). Troubleshooting performance across ten-mile wireless links during Alabama summer thunderstorms is really scary at best. The lessons learned here are that every bit of testing you can do before releasing a product to the field is worthwhile, and stay away from tall outdoor towers during thunderstorms.
After spending a long week performing field-testing and tuning of the wireless InterJak product, we were ready to deploy. We met our product development time frame of two months with not much room to spare.
Figure 6. Two InterJak 200 802.11b Products in the Field
Figure 7. Tower Providing Long-Distance Wireless Links of More than Ten Miles
Where does wireless on the InterJak go next? Wireless LAN is one of the most promising new technologies but also one needing immediate solutions to deal with current security issues. In the longer term, 802.1x addresses the security concerns related to wireless LAN deployment. In the immediate term, the most effective security for wireless LAN is an isolated wireless segment, a secure reverse-firewall and VPN support over wireless. A good fit for the InterJak, yes...but, this wireless story is for another day.
James Goodwin is a senior software engineer at Filanet Corporation, has turned into a wireless junkie and can be reached at firstname.lastname@example.org.