Linux Unwired [Electronic resources] نسخه متنی

6.3 Linux-Powered Off-the-Shelf

Electronics manufacturers are increasingly
turning to Linux to power all sorts of devices: e.g., TV set-top
boxes, handheld computers, and mobile phones. Now wireless vendors
have begun shipping products running a Linux kernel.

For example, Linksys is now selling the WRT54G Wireless Router. As the
name implies, it uses an 802.11g radio. However, the name
doesn't tell you that the box is really running a
custom Linux kernel based on the 2.4.5 kernel code, running on a
Broadcom processor, based on a 125 MHz MIPS processor core. As of
this writing, a WRT54G can be purchased for as little as $70, making
it probably the cheapest project in this book.

The Seattle
Wireless folks have an excellent page on their web site detailing the
work they have done peeking into the innards of this device. You can
find it at http://www.seattlewireless.net/index.cgi/LinksysWrt54g.
Even before Linksys began releasing the source code, people were
hacking away at the WRT54G, trying to get a login shell and figure
out what made it tick.

6.3.1 Hacking the WRT54G Hardware

In the fall of 2003, several of the NoCat folks were hacking away at
a newly acquired WRT54G, attempting to learn how to
get a login shell on the box. Early on, the Seattle Wireless group
had determined that you could execute arbitrary code by using the
Ping.asp web page, which is part of the
administrative web pages shipped with the unit.

If you're just looking for a quick way to upload new firmware, such as a custom Linux distribution, to the unit, skip ahead to "Hacking the WRT54G Firmware," later in this chapter.

It was then possible to upload arbitrary files to the unit, which we
don't recommend for this reason: we managed to
render our WRT54G completely useless by attempting to modify the
administrative HTML pages. In other words, the configuration on the
box was stuck that way, and we couldn't change it.
Due to our error, none of the web pages were accessible, including
Ping.asp, which was the only method at that
time.

The box sat unhappily in a paper bag for a few months. Recently,
while reading through the Seattle Wireless pages again, we became
aware that someone had managed to solder the correct components on
the motherboard of a WRT54G and had a working serial port. With a
working serial console, you can interrupt the boot of the unit with
Ctrl-C:

^C
PMON>

This puts you at the PMON bootloader prompt. From here, you can
recover a crippled WRT54G by executing the following commands:

PMON> set boot_wait on
PMON> set nvram boot_wait

These commands tell the unit to wait at boot and to attempt to load
firmware via TFTP. In order to take advantage of this, you need a
tftp client that supports passwords. Standard tftp client software
does not use authentication, and the tftpd running on the WRT54G
expects authentication. You can download a tftp client for Linux that
supports authentication from http://redsand.net/code/linksys-tftp.tar.bz2.
The code can be compiled with a simple make. The
WRTG54 assigns itself the IP address 192.168.1.1, so to connect to
it, you must assign an IP address from the same subnet on the machine
from which you want to run the tftp client.

When you are attempting a tftp upgrade of firmware or using the
web-based firmware upgrade shown in the next section, you must make
sure you have a reliable power connection. Interrupting the firmware
upgrade process can corrupt the flash memory during a write and make
your unit a very nice blue and black brick. It's
also important to use an Ethernet connection to one of the LAN ports
of the WRT54G when upgrading the firmware. While it is possible to
use the wireless connection, if anything
interrupts the wireless transmission, you again run the risk of
killing your flash memory and the unit.

Once you have set the boot_wait parameter, you can
power-cycle the WRT54G. At this point, you have approximately three
seconds to start the tftp client. In these three seconds, you must
execute the following commands:

$ ./linksys-tftp 192.168.1.1
linksys-tftp> put firmware_image password

In the next section, we discuss alternate firmware images for the
WRT54G.

Without a console on the Linksys unit, you cannot enter the
bootloader. If you examine the motherboard of a WRT54G, you will find
several empty surface mount sockets, a mount for a crystal, and two
sets of standard pinouts marked UART1 and UART2 next to the WAN
Ethernet port and the reset switch. Figure 6-9
shows a close-up of this area.

Figure 6-9. Close-up of WRT54G showing space for a UART

The Seattle Wireless web pages have a list of hardware that must be
soldered on in the empty sockets:

UART: National Semi PC16552DV

Transceiver: Maxim MAS213CIA

XTAL: 12.75MHZ

The details in this section are relevant only for a Linksys WRT54GVersion 1.0. Version 1.1 hardware is different, and you can find a discussion on 1.1 serial port hardware at http://www.sveasoft.com/postt44l. Look on the bottom of the WRT54G case to determine the hardware version: if your hardware is Version 1.1, it is printed there. 1.0 hardware has no identifier.

We ordered the first two sample parts from each manufacturer. For
links to the order pages, see the Seattle Wireless WRT54G web page:
http://www.seattlewireless.net/index.cgi/LinksysWrt54g.
Search for "14 Booting your own
kernel" to find the correct section.

As for the crystal, our hardware and soldering guru Brad
Silva suggested
that we should use an oscillator instead. This required a slightly
different approach when we began construction, as
you'll see below, but it worked well. We ordered a
12.8 MHz oscillator from Digikey (http://www.digikey.com).

Once all the parts had arrived, we set aside an evening to work on
the unit in Brad's lab. He had the necessary
soldering equipment plus an oscilloscope and a number of other tools
that came in handy.

Unless you really know what you're doing, soldering extra parts on your WRT54G is an excellent way to void your warranty and potentially destroy the unit. You need exceptional soldering skills for this project.

The first task was to solder the National Semi UART to the socket at U5.
This was the most difficult part of the operation, as the socket is
surface-mount technology that is designed to be soldered by a
machine. The UART uses J-connectors, which curve inward under the
chip. We held the chip in place with a piece of double-sided tape
underneath, but it was still difficult for Brad. However, his
soldering skills won out in the end.

Once we had the UART in place, we pulled out the oscilloscope so we
could determine which of the two smaller sockets would need the Maxim
transceiver installed. The correct socket turned out to be U1, which
is strangely connected to the pinout for UART2, not to the pinout
marked UART1/CON1 (which would seem to be indicative of the console).

We then soldered the transceiver in place at U1, and despite the
small size, the soldering went much faster because the soldering iron
simply wicked the existing solder into place on the chip.

Next up was the
oscillator. As
stated earlier, we chose an oscillator in place of a crystal. Either
one should work, however. As Brad states, "Crystals
are finicky devices. Oscillators are much more reliable and easier to
work with." We mounted the oscillator on a small
piece of breadboard.

In order to get signal flowing to the oscillator, we had to remove a
resistor and a capacitor from the motherboard. These are located at
R7 and C14 between the UART and the spot where a crystal would be
mounted.

Lastly, we needed power and ground for the oscillator. We obtained
these from ZN1 and DS1 next to the DC power input. Figure 6-10 shows an image of the motherboard with all the
work completed up to this point.

During this process, we stopped at each step to use the oscilloscope
to look at output from each new chip. Checking the output from the
transceiver and doing a little math, we were able to determine that
the eventual console serial speed would be at least 115 kbps.

Figure 6-10. WRT54G with added UART, transceiver, and oscillator

The last requirement was to add a DB9 connector so we could connect to
the serial port with a laptop. For this, we needed pins 2, 3, and 5
from the pinout marked UART2. It is important to note that unlike a
standard RS-232 DB9 pinout, pins 2 and 3 are not crossed. The pinout
to the DB9 is as follows:

Pin 2: Pin 2 Transmit

Pin 3: Pin 3 Receive

Pin 5: Pin 5 Ground

Figure 6-11 shows the attached serial port close-up.
We were not striving for attractiveness, just function. The intent
was not to have the serial port permanently attached, because if the
whole exercise were a success, we wouldn't have
needed it afterwards.

Figure 6-11. WRT54G with attached DB9 serial port

This was the magic moment. Our monitoring with the oscilloscope was
promising, in that we were definitely seeing a flood of output
immediately after the unit was powered on. We hooked up a laptop to
the DB9 port, fired up a minicom session, set the port speed to
115200, no RTS/CTS, no Xon/Xoff, applied power to the WRT54G, and
voila!

We were then able to use Ctrl-C to immediately interrupt the boot
process, set the boot_wait parameter, and reboot.
This time, the console showed a message indicating that it was
waiting for network boot. Following the previous instructions, we ran
the linksys_tftp client software and were able to flash the WRT54G
with the latest Linksys firmware. We then went on to try out some
alternate firmware, which we describe in the next section.

6.3.2 Hacking the WRT54G Firmware

At the time of this writing, you can find
Linksys source code
modifications at http://www.linksys.com/support/gpl.asp.
Broadcom has not yet released any source code for the radio drivers,
nor has it released the modifications that it has made to the gcc
compiler.

Several Linux distributions for the WRT54G are available. Some of these depend
on execution of arbitrary commands via Ping.asp.
However, Linksys has fixed this
"bug" with software release 1.42.2,
which has made any release that depends on this feature unusable.

With the release of the modified source code for the WRT54G, it is
possible for interested parties to compile the source themselves and
learn how to build custom firmware that includes features that
Linksys does not support in its product.

These new distributions are easy to install, because they are
complete firmware releases based on the Linksys code. Linksys
includes a firmware upgrade option in the administrative web pages
for the WRT54G. Figure 6-12 shows the screen, which
you can find by selecting the Administration tab in the web page and
clicking on Firmware Upgrade.

Figure 6-12. WRT54G firmware upgrade

You can also upgrade the firmware via TFTP, as we described in the
Section 6.1. Of course, on
an unmodified WRT54G running Linksys firmware, the TFTP option is not
possible. You must have a soldered-on serial port to enable the
interrupt of the boot process, or you must flash the unit first with
one of the alternative firmware images we discuss below. They both
provide support for enabling the boot_wait option
from the administrative web pages.

As of this writing, there are two well-developed distributions
available that are based on the latest Linksys 2.0 source code. Each
distribution appears to have a number of similar features, and as
they continue to mature, it seems that they will continue to become
more similar. Right now, however, both have different feature sets
and appeal to somewhat different audiences. There is also a third
distribution at sourgeforge.net (see Section 6.3.2.3 later in this chapter),
which is built from the ground up and is not based on Linksys source
code.

Linksys doesn't support firmware that you receive from other sources. While you many not be voiding your warranty by flashing the firmware with alternate versions from other sources, you should be aware that the process is not perfect. There is a possibility of corrupting the flash in your WRT54G and making it an expensive paperweight. When you upgrade your firmware, whether it is a Linksys or alternative firmware file, the configuration in the WRT54G is erased. There is no provision for saving a configuration to NVRAM, so before you upgrade, make a note of all your settings. Finally, it should be stressed that as of this writing, all of the alternative firmwares are in beta or testing modes, and are not as stable as the Linksys firmware.

6.3.2.1 Sveasoft firmware

Sveasoft is a company with offices in
Sweden and California. It has developed a very nice firmware package
for the WRT54G. The developers host an active forum at http://www.sveasoft.com/forumsl and are
very responsive to bug reports and feature requests. Sveasoft is also
selling in Sweden an outdoor-mountable repackaged WRT54G with its
custom code, suitable for a wireless ISP or community network
installation.

The Sveasoft firmware includes the following features:

Telnet daemon

SSH daemon

OSPF routing from the Bird routing daemon

20 new iptables filters to support filtering P2P and other protocols

QoS bandwidth management

Local DNS caching daemon

PPTP client and server capability

Radio transmit power adjustment

Antenna selection

Client radio mode

Signal strength and MAC addresses of radio clients

WDS

Added options in the Administrative web pages to enable/disable
services

Command shell from the Administrative web pages

Replaced openssl with maxssl to free up 1 MB of flash

Roaring Pengiun PPPoE module

Additional features planned for inclusion in the firmware are:

SNMP support

Kismet dronea remote sniffer

Remote monitoring package

Dynamic DNS configuration

Shorewall firewall

NoCat-like captive portal

Snort intrusion detection engine

Complete IPSec client and server support

802.1X for client radio mode

Simplified web interface

Support for a dynamic download so that developers can update in
packages rather than in a complete firmware reflash.

You can obtain the latest Sveasoft
firmware from its FTP site: Figure 6-13,
the firmware version in the upper-right corner is now a non-Linksys
version.

Figure 6-13. Sveasoft firmware main configuration screen

The Sveasoft firmware offers another nice
feature: the ability to select the receive and transmit antennas, as
well as the ability to increase and decrease the transmit power of
the radio card. In the web-based configuration, click on Wireless,
and then on Advanced Settings. As shown in Figure 6-14, the last three options allow TX and RX
antenna selection, and you can now increase the milliwatt output of
the WRT54G radio card up to a maximum of 83 mW from the default of
28.

Figure 6-14. Sveasoft Advanced wireless configuration settings

If you have two WRT54G units, a Linux box with a Prism card and the
HostAP driver, or an access point running the OpenAP/LinuxAP
distributions (see Section 6.3.4
later in this chapter), you have the option of setting up WDS between
your access points. If you choose to use a Prism card, it must have
station firmware Version 1.50 or higher. See Chapter 4 for details on how to determine your
station firmware version.

WDS is an 802.11 specification for using an 802.11 wireless
connection as a distribution system. A special data frame with four
addresses is defined for WDS. This allows layer 2 bridging of packets
between two addresses. In other words, your access points continue to
serve clients, but can also communicate with each other over a
bridge. You can use this to set up a second access point that has no
wired connection, only the bridged connection to another access
point. This is most useful for extending the range of your network.

There are some caveats for using WDS. Your access points must use the
same SSID, the same channel, and the same WEP keys (if
you're using WEP). Currently, using WPA to encrypt
WDS communications is not possible. Unless you use WEP, all of your
bridged packets sent between the access points will be sent in the
clear, and you could easily fall victim to a classic
"man in the middle" attack where
one of your MAC addresses is spoofed.

Another side effect of WDS will be decreased throughput. If both of
your access points are serving clients while they are communicating
via the WDS bridge, you will lose throughput due to increased radio
utilization for WDS.

We did not have two WRT54G units with which to test this WDS, but we
were able to set up a WDS link between our WRT54G running the
Sveasoft code, and a notebook with a Prism card and the HostAP
driver.

In order to set up the WDS link, we needed to install the
bridge-utils package. On our Mandrake 9.2
system, this was installed using urpmi
bridge-utils; Red Hat and Fedora users should be
able to similarly use the rpm installation, and Debian users can do
apt-get install bridge-utils.

It took some fits and starts to get WDS working between the WRT54G
and our Mandrake box running HostAP. Figure 6-15
shows the WDS configuration screen in the Sveasoft firmware. Here, we
entered the MAC address of the Prism card on the Mandrake system and
assigned the WDS bridge an IP address and subnet mask.

Figure 6-15. Sveasoft WDS configuration

However, when we first attempted to set this up and clicked on Save
Settings on the WRT54G, our Prism card lost wireless communication
with the Linksys. We were not able to bring up a bridge at that
point. Later, as we continued to troubleshoot, we were able to figure
out why: the MAC address we obtained from the WRT54G was
not the MAC address that the WRT54G assigned to
the WDS bridge.

On our WRT54G, the wireless MAC address is 00:06:25:B2:6B:D5. We
entered this initially in the WDS configuration for the Prism card.
However, once we obtained a console login on the Linksys, we found
that the WDS interface was actually given a MAC address of
00:06:25:B2:6B:D7. Once we set up WDS for the Prism card with this
interface, we were able to communicate over the WDS link.

Once the WDS commands were entered for the Prism card, it took approximately 30 seconds for the WDS link to begin working. Don't give up if you can't ping across the link immediately.

In order to set up the WDS link on the Prism card running HostAP, we
entered the following commands:

# iwpriv wlan0 wds_add 00:06:25:B2:6B:D7
# Creates a WDS interface
# brctl addbr br0                 # Creates a bridge interface
# brctl addif wlan0               # Adds wlan0 to the bridge
# brctl addif wlan0wds0            # Adds the WDS interface to the bridge
# ifconfig wlan0 0.0.0.0          # Zeros out TCP/IP for wlan0
# ifconfig wlan0wds0 0.0.0.0        # Zeros out TCP/IP for the WDS interface
# ifconfig br0 192.168.255.2        # Assigns TCP/IP to the bridge interface

Note that you must have your Prism card in either managed or master
mode for this to work. If you are in managed mode, you are
essentially acting as a client to the bridge, and you must add
another Ethernet or radio interface to make the bridge useful. If you
are in master mode, your HostAP access point can continue to serve
other clients while still participating in the WDS bridge.

The Sveasoft firmware enables many
other interesting features, including Quality of Service (QoS) for
bandwidth management, among other things. Those features are really
outside the scope of this book, but one feature that is very handy is
the SSH daemon.

To set up the SSH daemon, navigate to the Administration tab, and
click on Management. Scroll down to the section titled SSHD. First,
click on the radio button to Enable SSHD. Scroll down and click on
Save Settings. Navigate back to the SSHD section and similarly enable
Password Login. Click on Save Settings again. Reboot the WRT54G.

You can now use ssh to log in to the router using
root as a username and the administrative
password that you set in the web interface. (You
have changed your administrative password from
the default, haven't you?)

6.3.2.2 Wifi-Box firmware

The Wifi-Box firmware distribution was
developed by Augustin Vu. It is also now based on the Linksys
2.0 firmware release, and the project web page is found at
http://sourceforge.net/projects/wifi-box.

As we previously discussed, this project has much in common with the
Sveasoft firmware, because many of the stated end goals of the
project are similar. The current implementations, however, differ
somewhat in their feature sets.

The Wifi-Box software includes the following features:

Radio transmit power adjustment

Antenna selection

DHCP server can assign static DHCP addresses

Supports Class A and Class B subnets

Local caching DNS server

SNMP daemon

Support for VPN PassthroughIPSec, PPTP, L2TP

Server Profiles for multiple IP forwarding

Telnet daemon

Remote wake on LAN support

Web-driven reboot and restart services commands

Enhanced status pages

Additional features planned for inclusion in the firmware include:

WDS bridging

SSH daemon

QoS bandwidth management

IPSec client and server

PPTP client

You can download the firmware from the SourceForge web site. As of
this writing, the most current version is
code_2.02.pre1-wfb.zip. Use the
unzip command to extract the single
.bin file contained in the compressed download.

The procedure for installing the Wifi-Box
firmware is identical to flashing any other firmware to the WRT54G
(see Section 6.3.2 and Section 6.3.2.1).
You can use the web interface, or, if you have already tried the
Sveasoft firmware, you can set the boot_wait
option in the Administration tab and flash the router via tftp on the
next reboot.

As you can see from Figure 6-16, the only noticeable
difference to the Wifi-Box firmware is again in the upper-right
corner of the main screen.

Figure 6-16. Wifi-Box firmware main configuration screen

The current Wifi-Box firmware has fewer enhancements to the wireless
side of the router and more added features in the TCP/IP department.
Wifi-Box does include the antenna selection and radio transmit power
adjustments in the same location as Sveasoft: Click on the Wireless
tab and select Advanced Wireless Settings.

One feature that will appeal to anyone already running MRTG, Cacti,
or any other SNMP-based network data gathering tool
is the inclusion of an SNMP daemon. To configure SNMP, click on the
Setup tab and then select SNMP. The documentation is incomplete, and
there is no help file for this page, so it is unclear if the SNMP
daemon supports SNMP v1, v2, v3, or a combination of these.

The Security tab adds new VPN settings to allow passthrough of the
three most widely used VPN protocols. In the Applications &
Gaming tab you can define Server Profiles that allow you to forward
many commonly used ports to different servers on the LAN side of the
WRT54G.

In the Administration section, you can enable the Telnet daemon. Here
you can also click to reboot the router or restart all services on
the router without a reboot.

All in all, the Wifi-Box firmware is a nice upgrade from the standard
Linksys firmware. As of this writing, it appears that the Sveasoft
firmware has more wireless features enabled, and it also does have
the advantage of a working SSH daemon. Both firmware packages are
worth investigating for your use.

6.3.2.3 OpenWrt firmware

The OpenWrt firmware project is taking a
completely different approach. Its firmware is not based on the
Linksys code at all, and its statement of goals at http://openwrt.sourceforge.net states some
very specific goals:

Create a usable and functional development environment for the WRT54G
that exposes the full capability of the 2.4.20 kernel.

Firmware must have failsafe modes so that configuration errors do not
prevent the unit from booting.

As much flash as possible should be dedicated to read/write
filesystems for installation of functional modules.

The Linksys/Broadcom/Cisco copyrighted configuration utilities are
not included.

The OpenWrt developers are hard at work on the beta version of their
firmware. As of this writing, they have not released any packages on
their SourceForge project site. Follow the directions at http://openwrt.sourceforge.net to obtain
their latest beta.

As the login file to the #wrt54g IRC channel states: "Newbies need not apply." The OpenWrt firmware is not complete. OpenWrt is still working on a development platform base. If you want a fully functional access point with all the features shipped in the Linksys firmware, this is not for you. If, however, you want to hack on a fully open source Linux distribution for the WRT54G, read on.

As with the previous firmwares, you can load the
OpenWrt
firmware by using the Upgrade Firmware option in the Administration
web pages, or, if you have loaded Sveasoft or Wifi-Box firmware, you
can set boot_wait and use the tftp client to flash
the WRT54G firmware.

OpenWrt changes the flash filesystem layout of the Linksys firmware.
It contains a small read-only squashfs
filesystem and a larger writable jffs2
(Journaling Flash Filesystem). The squashfs
partition has a failsafe boot routine, which you can trigger by
holding the reset button during boot. This failsafe mode boots
entirely from the squashfs partition, and
configures the LAN and wireless networks to 192.168.1.1. So if you
manage to munge up the jffs2 partition, you can
always recover and start over.

OpenWrt attempts to set up the networking of the WRT54G using
configuration stored in NVRAM. So your LAN, WAN, and wireless network
information should remain the same after flashing.

OpenWrt implements a Telnet daemon for
administrative access. The developers plan to have ssh available as a
package once the basic development environment is done. The
busybox environment implements telnetd by
default, so this is a simple way to proceed with development.

On the first boot after flashing, the jffs2
filesystem does not exist. You must telnet to 192.168.1.1, run the
firstboot command at this point, and then restart
the system. This initializes the jffs2
filesystem and allows you to boot completely into OpenWrt.

When fully booted, the squashfs partition is
remounted as /rom with the
jffs2 partition mounted as
/. Symlinks are made from the root filesystem to
files contained in /rom. If you want to modify
any of the files on jffs2, you must remove the
symlink and copy the file or create the file on the root partition.

OpenWrt uses VLAN interfaces to represent the LAN and WAN ports. On a
v1.x WRT54G, the following interfaces are created:

vlan1: WAN interface

vlan2: LAN interface

eth2: Wireless interface

For more detailed information on the innards of this beta version,
you should consult the README. Check out the IRC channel and the
SourceForge project pages for updates. The developers hang out on
#wrt54g, so it's the best place at the moment for
help with the firmware.

You now have a small Linux-powered router. Although the OpenWrt
firmware is still in early development, we think it has the most
potential of the alternative firmwares currently available for the
WRT54G. The Linksys-based firmware version have some impressive
features, to be sure, but OpenWrt will definitely be the most
flexible firmware distribution of the three, due to its stated
goals.

6.3.3 Other Linux-Powered Devices

Aside from the WRT54G, there are other Linux-powered devices now on
the market. Some of them appear to be even more capable internally
than the WRT54G. Some of them have serious limitations that would
make it difficult or impossible to modify the kernel source. We touch
on a few of these devices here. If you're a
dedicated hardware or kernel hacker, these boxes could use your time
and expertise.

The Linux-powered device world is constantly changing, so by the time
you read this, other wireless devices with Linux under the hood will
probably be available.

6.3.3.1 Linksys WRV54G

This is a Linksys wireless VPN router. It has nothing in common with
the WRT54G, in that the internal processor is a 266 MHz Intel ISP425
ARM-based CPU and the MiniPCI wireless card is a PrismGT 802.11G
chipset. The MiniPCI card is soldered to the MiniPCI connector for
grounding purposes. There are open source issues with the Intel
Ethernet driver for the ISP425. The Intel Access Software Library
license expressly forbids any code in the Library from being released
under the GPL or BSD licenses.

The Seattle Wireless folks have been hard at work on a WRV54G. As of
this writing, however, there is no alternative firmware available,
and the firmware has not yet been hacked. You can find all of their
current information at http://seattlewireless.net/index.cgi/LinksysWrv54g.
Linksys has released the source code, and the various versions are
available at http://www.linksys.com/support/opensourcecode/wrv54g.

6.3.3.2 Dell TrueMobile 1184

The Dell TrueMobile 1184 was released in early
2003. It has a Prism 3 802.11b chipset inside and runs a 2.2 Linux
kernel. It appears that Dell contracted with another vendor to
develop this product, and when it was released, there was no
acknowledgment that the device was Linux based, nor was there any
source code released.

Dell was persuaded by a user to release the source code. However,
since that time it has been discovered that the released source is
not actually the correct source for the internal ARM processor or
Ethernet chipset.

As of this writing, there does not yet appear to be a viable solution
to run any custom Linux kernels on the Dell hardware. Dell has since
discontinued this unit, and information and source code are no longer
available on the Dell web site. You can follow the Dell 1184 threads
at the LinuxAP mailing list for more information: http://ksmith.com/pipermail/linuxap-dev/2003-July.
Lastly, if you follow this threaded discussion, it appears that the
Dell is so difficult to work with, any development has been abandoned
to look for easier hardware to hack: http://ksmith.com/pipermail/linuxap-dev/2003-October/000522l.

6.3.4 Running Linux on Non-Linux Devices

Ever since 802.11b access points began shipping, people have been
taking them apart to find out what makes them tick. In many cases,
especially with early models, the internals were i386-compatible
chips, which made the challenge of attempting to run Linux on these machines
impossible to ignore. There are some serious caveats to running Linux
on any of these devices:

These systems need a small kernel. 2.4 series kernels, even stripped
to the bare bones, just take up too much space on a device that has 2
or 4 MB of RAM. 2.2 series kernels are then the choice for all of the
following distributions.

With some of these devices, there isn't enough room
to store a usable Linux system on the flash, so the root filesystem
must be kept on an NFS server. While this isn't out
of the question, it does mean you must have an NFS server running.

The minimal amount of RAM in these systems means that application
space is very limited. It's possible to run things
like telnetd, but sshd or any other larger applications are out of
the question.

The cards in these access points are based on chipsets that do not
support master mode. Even though you have Linux
running on them, you are restricted to managed
or ad-hoc modes, and can't use
the AP as an actual access point.

6.3.4.1 Apple AirPort

When the Apple
AirPort 802.11b access point was first released, people naturally
opened it up to find out what was inside. The guts of the unit are an
AMD ELAN processor running at 33 MHz. The ELAN is an i386-compatible
processor that is very popular with embedded device manufacturers.

Of course someone took the challenge of getting the AirPort to run
Linux, because it runs i386 binary code. Til
Straumann has
an excellent web page detailing the steps necessary to run a Linux
2.2 kernel on the AirPort: http://www-hft.ee.tu-berlin.de/~strauman/airport/airportl.

The AirPort has only 4 MB of flash RAM, so you must boot and load
software from a network share to make Linux run. To do this, you need
a tftp server, NFS server, and DHCP server. In addition, you must
reflash your AP with boot code that makes it look for the Linux
software on the network. This is not easy to set up, so we recommend
that you read completely through the web page listed in the previous
paragraph before attempting to run Linux on your AirPort or RG-1000.

6.3.4.2 Orinoco RG-1000

The Lucent Orinoco RG-1000 is internally
identical to the Apple AirPort. Seattle Wireless uses Linux-powered
AirPorts and RG-1000s extensively in its citywide wireless network.
More information on its projects can be found at http://www.seattlewireless.net/?AirportLinux.

Seattle Wireless AirportLinux is based on the code by Til Straumann
for the AirPort, with some modifications. While both of these
distributions are fun hacks, they are not nearly as practical as
using vanilla PC hardware or flashing a Linksys router. They both
require a dedicated server to boot from. If you have such an
environment, great! You can pick up used RG-1000 units on Ebay for
very little money.

6.3.4.3 Eumitcom WL11000

While you will never find a consumer product with this name on
it, this motherboard was the basis for these early models of 802.11b
access points:

US Robotics (USR 2450)

SMC EZconnect (2652W)

Addtron (AWS-100)

There have been two Linux distributions developed for these access
points. They are both still available, although the first, OpenAP,
does not appear to be under active development. OpenAP is available
from http://opensource.instant802.com. As stated,
it runs only on this single hardware platform. It is increasingly
difficult to find these access points, but if you have one, this is a
fun little project.

In order to flash these access points, you need a linearly mapped
memory card. The OpenAP site recommends a MagicRAM Industrial SRAM
Memory card that is 2 MB in size and readable at 3.3 V. You must also
connect a null modem cable to the RS-232 serial port on the access
point, and a terminal program to communicate with the Linux
distribution.

For information and complete instructions, see the Getting
Started page on the OpenAP web site: Section 6.2 earlier in this
chapter. While LinuxAP is designed to run on the Soekris hardware
platform, and indeed can be made to run on any Intel-compatible
small-board PC, it also supports the WL11000-based access points. You
can find LinuxAP at http://linuxap.ksmith.com. This site also
hosts an active mailing list at http://linuxap.ksmith.com/mailman/listinfo/linuxap-dev,
and a recent posting of the LinuxAP FAQ can be found in the mailing
list archives: http://ksmith.com/pipermail/linuxap-dev/2004-February/000675l.