Smashing OpenWRT Embedded for fun

A prelude:

Great news. After I had a talk with a friend of mine, Roie, whose basically a guru at all things embedded-related I decided to start working on some embedded devices for some projects. At first I took a glance at PC Engines WRAP devices but these are basically just your regular x86 embedded boxes so I ordered for the office to play with. The embedded wrap should be plain fun and profit cause this wouldn’t require any special kernels or re-compiliation of any software cause we’re kept on our usual environment (x86).

To the fun stuff – the linksys wrt54g model is a router which is based on linux and the mips embedded architecture which means more fun for me
With the wrt you get a huge 4mb of flash to put all your favorite linux tools and crafts including the kernel and the whole nine yards, and to do that we can reset linksys’ official firmware with a version of OpenWRT which is a firmware that provides us with a familiar linux environment on the router, meaning shells, daemons and the rest of it. It even has a tiny web interface to configure the basic stuff like WAN and LAN settings.

So you’re asking yourself now what? what do I do with all this linux? Well endless possibilities are upon you. From captive portal hotspot-in-a-box solutions to vpns, routing daemons like bgp and rip to war driving tools like kismet and aircrack and all of those on that 200Mhz with 16mb of ram box.

Being Practical

The OpenWRT folks has provided us with a cross compiler and a build environment to firstly, customize my own image to put on the router and to build my own packages and compile from source my own software or simply port it so that I can run software I like on the mips box.
This is very useful cause the custom images of OpenWRT are split to PPPoE and PPTP images though what if I wanted to have both
of these options available on one image? I can simply ‘make menuconfig‘ and choose the packages and firmware options that I want.

That’s regarding the customization. The cross compiler is another issue. Theoretically you could put some development tools on the linksys box and just download and compile whatever software you want to run on it locally but with that processing speed (slow) and hardly any room for practical development we’re facing a problem. The solution is cross-compiliation which means I can download the software sources to my own debian desktop and compile it locally with a tool that makes the binary run on the mips (and not on my x86 ofcourse).
This does take a bit of tweaking with setting up the development environment and files but is do-able none the less.

A modification to the environment variables is required:

export PATH=/home/liran/Programming/openwrt/whiterussian/openwrt/staging_dir_mipsel/usr/bin:  
/Programming/openwrt/whiterussian/openwrt/staging_dir_mipsel/mipsel-linux-uclibc:  
/home/liran/Programming/openwrt/whiterussian/openwrt/staging_dir_mipsel/bin:$PATH  
export AR=/home/liran/Programming/openwrt/whiterussian/openwrt/staging_dir_mipsel/bin/mipsel-linux-uclibc-ar  
export AS=/home/liran/Programming/openwrt/whiterussian/openwrt/staging_dir_mipsel/bin/mipsel-linux-uclibc-as  
export LD=/home/liran/Programming/openwrt/whiterussian/openwrt/staging_dir_mipsel/bin/mipsel-linux-uclibc-ld  
export NM=/home/liran/Programming/openwrt/whiterussian/openwrt/staging_dir_mipsel/bin/mipsel-linux-uclibc-nm  
export CC=mipsel-linux-uclibc-gcc  
export CPP=mipsel-linux-uclibc-cpp  
export GCC=mipsel-linux-uclibc-gcc  
export CXX=mipsel-linux-uclibc-g++  
export RANLIB=mipsel-linux-uclibc-ranlib  
export ac_cv_linux_vers=2.4.30  
export LDFLAGS="-static"  
export CFLAGS="-Os -s"

And editing the Makefile is usually necessary. The resulted file is a stripped down binary with statically linked libraries to run on the
mips box. Then the build process continues as usual.

References: