Skip to content

Linux on Wireless routers

by andy on May 9th, 2007

I spent the last two days trying to setup two wireless access points. The first one should be used as an access point (with internet uplink) and the second one should be used as an wireless bridging client (i.e. there can be normal computers connected to its lan ports).

I used LinkSys linux-enabled hardware and tried most firmwares available for this product. While doing the tests I bricked my device twice, but was able to recover. At least it works by now.

The situation
I got two rooms that should be connected over a wireless link. The first of those has an internet uplink that will be shared from both rooms. In the second room the access point should act as a wireless bridge, i.e. all devices connected to its internal switch should be visible in the network.

Possible Solutions:

OpenWRT 0.9rc6 with webif
This was the configuration that ran for the last nine month. As the density of wireless networks in my area increased this solution ran into problems (the network link got lost). Also I wanted to play with QoS and the webGUI just didn’t cut it. I wanted to use AES/WPA over the bridge, but it seems as this won’t fly with this realease. Since OpenWRT 0.9rc5 a very useful rescue mode was integrated into OpenWRT: it allows you to boot the device in a safe mode that will allow you to diagnose problems and change the configuration.

OpenWRT 0.9 with webif^2
I upgraded openwrt to the latest stable version and also installed webif^2 from x-wrt which is an enhanced GUI. It provides more options (QoS, real integrated package installation, enhanced wireless options) and feels faster that the orignial firmware. While in there I recognized some of the roots of my problems. First of all the internal DHCP server of the bridge wasn’t disabled. This led to arcane routing which slowed network traffic down. Also there were dupplicate response packets generated by the bridge: a problem that seems to be known but still unsolved.

OpenWRT Kamikaze
As the bridging problem should be kernel related I tried the OpenWrt bleeding edge ‘Kamikaze’ distribution. The name was aptly choosen. I was able to install it, but it never booted in a way that would allow network traffic. It did run in rescue mode, it seems as if the wireless network card was never detected. Overall the new system feels more UNIX-like (config files instead of NVRAM) and surely is a step into the right direction, but isn’t useable right now (did I mention the lack of documentation?).

DD-Wrt
A friend of mine recommended DD-Wrt so i tried it. Downloaded the image file, copied it onto the device and wrote it to flash with the mtd command line. Result? A brick. The router didn’t work anymore! I tried the rescue operations described on the DD-WRT site, but none worked. Finally I tried to reflash the device over tftp. Quite simple and fast, and I had an access point with the orignal LinkSys firmware.

LinkSys Firmware
I needed to reflash the device with a valid firmware (after I bricked it wit DD-WRT). The LinkSys website didn’t offer a firmware for my release (v1.1) but only for v1.0, but it still did work – well, what should I do, the device wasn’t useable anymore. It did work, but the GUI was so ugly and un-functional that I threw it away after some minutes.

DD-WRT second try
I tried flashing DD-WRT a second time, these time over the web GUI. It worked better, but still the installation process was rather broken. I was able to connect to the device on address 192.168.1.1 over telnet, but there wasn’t much else which I could accomplish. I stumbled upon the hint that you might need to master reset the device to gani full functionality, I tried this several times (as well as reflashing the router) and somehow it worked (including the webGUI).
While the GUI isn’t as flashy as webif^2 it is on the second place, but the bridging mode just works fast and stable. It is annoying that the interface wants to reboot the device upon almost every change, but as I only have to do this once I will glady take it. The offered functionaliy is on par with OpenWRT, maybe structured and documented a little bit better (i.e. the DHCP forwarding as oppossed to DHCP server was configureable through the web gui). The DD-WRT people should just copy the rescue mode and the LED signalling from the OpenWRT people.

Results
My final soluton is OpenWRT (with webif^2) on the border router/access point and DD-WRT on the wireless bridge. Why? It works and is fast.
Two days later I encounterd the hated dupplicate ICMP packets again. With even further digging I found out that 802.11 (wireless)/Network bridges only work reliable with one lan device (and not even then). So I gave up on a bridged client and moved on towards a WDS bridge. While I never came around doing this with OpenWRT (as the documentation was lacking) it was a breeze with DD-WRT. Hopefully this will work better.

  • Stumbleupon
  • Delicious
  • Google Buzz

No related posts.

From → Admin-stuff, Linux

One Comment
  1. Managed to do the same thing to mine by trying to install Kamikazi on a WRT54GL. Had to un-semi-brick it via the “wget http://192.168.1.175/openwrt.trx -O – | mtd -e linux -r write – linux” trick.

    - joat

Leave a Reply

Note: XHTML is allowed. Your email address will never be published.

Subscribe to this comment feed via RSS