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.

Figure 2. Trillion Digital Communications Wireless Network

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:

Figure 3. Adding a Wireless Interface to the InterJak Service Appliance

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:

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).

Figure 4. Adding a Wireless Interface to the InterJak Servicei Appliance

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 trillion

Figure 5. Networking Services Requiring Integration Testing with Wireless Support

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.

Resources