Linux on Linksys Wi-Fi Routers
One enterprising individual ported the entire OpenSSH toolchain to the Linksys box. Unfortunately, the size of the OpenSSH binary means that many standard Linksys functions must be removed to make room. Plus, the resulting RAM requirements are at the limits of available memory. What is needed is an SSH server with a small memory footprint, and the Dropbear server fits the bill nicely. Matt Johnson designed the Dropbear SSH dæmon specifically to run in memory-constrained systems such as the Linksys.
The standard Linksys Linux implementation lacks many of the normal files needed for multiuser Linux systems. Two of these—passwd and groups in the /etc directory—are required by the vast majority of Linux applications. In order to run the Dropbear server, we need to add these files to the Flash build.
By creating a passwd file with a root entry and no password and a matching groups file, we can make Dropbear almost happy enough to run. These files are copied to the /etc directory of the Flash image and are read-only on the Linksys.
When running, Dropbear also needs to access a private key that is used for SSH handshaking and authentication, as well as a known_hosts file containing the public keys of approved client machines. Generating the private key with the dropbearkey program is a snap, but storing it on the Linksys is a bit trickier.
The WRT54G contains a hash map of key name and value pairs located in nonvolatile storage called nvram. The bundled nvram utility and API allows us to read and write to this memory area. The Dropbear private key and our public key ID from id_rsa.pub in our home .ssh directory are stored in nvram and copied to /var in the RAM disk on system start.
We compile Dropbear with support for key-file authorization and now have a secure way to log in to the Linksys. If you need password login, the Dropbear code can be patched to read the system password from nvram and to add the ability for password logins as well.
After adding such utilities as SSH and telnetd, you soon find your Linksys firmware image bumping the limits of the Flash storage space on the device. What you need is a filesystem with better compression than cramfs offers, one that is compatible with the Linksys Linux kernel.
The default cramfs filesystem compresses data in 4K blocks, but compressing on 4K boundaries limits the compression ratios that can be achieved. If we could find a filesystem that compressed larger blocks of data but mapped correctly to the page size in the OS, we would be able to put far more data and applications in the firmware.
Phillip Lougher's squashfs filesystem compresses in 32K blocks and is compatible with the 2.4 and 2.6 kernels. If we could move the Linksys firmware from cramfs to squashfs, we might have enough room for a VPN client and server in the system.
The Linksys kernel is a customized 2.4.20 source tree modified by Broadcom. Broadcom is a leading 802.11g chip maker and is responsible for the CPU and radio chips in the WRT54G. The squashfs tar file contains patches for the 2.4.20 through 2.4.22 kernels. Unfortunately, none of these applies cleanly to the Broadcom kernel tree, so a bit of hand editing is necessary. The patch with the fewest errors is the 2.4.22 version, which misses only one hunk when applied. By reading the patch file and finding the missing hunk, you can patch the missing code manually. You also can find a WRT54G-specific squashfs patch on the Sveasoft Web site.
The Linksys WRT54G Source Tree
When you unpack the GPL source from Linksys, a directory structure is created below the main WRT54G subdirectory. Here is an explanation of the important parts.
The main tarball directory is /WRT54G. The main Makefile lives in /release/src. After unpacking the source, read the README file here for instructions on how to compile it.
All of the applications packaged with the Linksys unit are built from /release/src/router. If you want to add applications, do it here and modify the Makefile in this directory. This Linux kernel source tree has been modified by Broadcom, the manufacturer of the wireless chips and CPU in the WRT54G. Add your kernel modifications or patches here, /release/src/linux/linux.
You need to create a symlink from /opt to the brcm directory here, /tools/brcm. Two of the subdirectories under brcm must be added to your PATH. See the README file above for more information.
Patches and updated source code can be downloaded from Sveasoft. See Resources for more information.
The next step is to edit the Broadcom kernel startup code and add a check for squashfs. The do_mount.c file contains nearly identical code and can be used as a guide when patching the startup.c file in the arch/mips/brcm-boards/bcm947xx subdirectory.
After patching the kernel, the router Makefile must be patched to generate a squashfs image and the Linux kernel configuration must be set to include squashfs support.
This is well worth the effort, however. On recompile you should find some 500K free bytes, compared to the stock cramfs filesystem.
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
|Non-Linux FOSS: Seashore||May 10, 2013|
- Dynamic DNS—an Object Lesson in Problem Solving
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Using Salt Stack and Vagrant for Drupal Development
- New Products
- A Topic for Discussion - Open Source Feature-Richness?
- Drupal Is a Framework: Why Everyone Needs to Understand This
- Validate an E-Mail Address with PHP, the Right Way
- RSS Feeds
- Readers' Choice Awards
- Tech Tip: Really Simple HTTP Server with Python
- BASH script to log IPs on public web server
5 min 36 sec ago
3 hours 41 min ago
- Reply to comment | Linux Journal
4 hours 13 min ago
- All the articles you talked
6 hours 37 min ago
- All the articles you talked
6 hours 40 min ago
- All the articles you talked
6 hours 41 min ago
11 hours 6 min ago
- Keeping track of IP address
12 hours 57 min ago
- Roll your own dynamic dns
18 hours 10 min ago
- Please correct the URL for Salt Stack's web site
21 hours 22 min ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?