Thursday, November 27, 2014

Use 802.11n on Asus RT-N16 with OpenWrt

(If you come from OpenWrt's official wiki, skip forward to the section "802.11n" for your answer.)

Overview

It took me a while to figure out how to setup 802.11n in OpenWrt on Asus RT-N16 so I figured I'd share the process, hopefully to save somebody's time.

Background

I've used dd-wrt for a long time (on 4 wireless routers over the years). However, my network setup is getting more and more complex. While dd-wrt allows some customization, the inconsistency between GUI and the command-line configuration made it very hard for me to maintain. For example, editing the DHCP static address table from the GUI is a tedious process because it doesn't sort so it's very hard to detect duplication. I could edit the configuration file directly but the GUI does not reflect my changes correctly. Saving from the GUI can easily overwrite my manually edited config files.

Choosing Alternatives

Therefore, I started to look for an alternative. Besides dd-wrt, Tomato and it's family, and OpenWrt are the other two high-profile router firmware development efforts. And both lineages provide very customizable environment.

However, there are two things I'm looking for.

1. I am looking for a project that's still actively maintained, especially after Heart Bleed, Shell Shock, and Poodle. (Note that these vulnerabilities don't necessarily compromise home routers, but in my environment, I'd rather not take the chance.) While a repository system allows individual package upgrade, I want the base developers to still be around.

2. I'm looking for a project that's owned by a team rather than individuals. In the WRT history, there have been many brilliant individuals that made crucial advances for everyone. However, it has happened a few times when these individuals moved on, their projects died, too.

Therefore, I ended up choosing OpenWrt.

Installation

It was quite straightforward to switch to OpenWrt from dd-wrt, as instructed in the official guide.

Securing the admin access was obvious. However, it took me a while to realize that I also needed to reboot my Cable Modem for it to reset its DHCP. If you are also doing this, I suggest you open all installation guides in the browser first before you flash your new firmware. I had to use my phone to check the guides before my internet was up.

802.11n

This took me a while because the guide is not very obvious. Anyway, after some trials and errors, broadcom-wl was the only one that worked for me (thanks to Stratos about the dependency nas. I already had that so I didn't realize that dependency).


  1. # opkg update
  2. # opkg install kmod-brcm-wl wl wlc
  3. # rm /etc/config/wireless
  4. # opkg install nas
  5. # reboot
Then login to shell again to edit /etc/config/wireless . This is mine.

config wifi-device  wl0
        option type     broadcom
        option channel  1
        option txantenna 3
        option rxantenna 3
        option txpower '20'
        option plcphdr 'auto'
        option frameburst 1
        option disabled 0
config wifi-iface
        option device   wl0
        option network  lan
        option mode     ap
        option ssid     YOUR_SSID
        option key      YOUR_KEY
        option wmm      1
        option encryption 'psk2'
        option disabled '0'
I added plcphdr and frameburst after reading this discussion thread.

Another strange thing to work around is that after reboot, while a client can connect to the router with 802.11n, the DHCP failed to issue IPs. I had to turn the wifi off and on for it to work properly.

# wifi down
# wifi up
I did not spend time debugging. Instead, as a temporary workaround, I added that to /etc/rc.local, which now looks like this:

# Put your custom commands here that should be executed once
# the system init finished. By default this file does nothing.
# workaround for Broadcom proprietary driver problem
/sbin/wifi down
/bin/sleep 1
/sbin/wifi up
exit 0

Update: badineu in the comment mentioned that he also needed to manually select the wifi frequency. You may also have to do so if, for some reason, it's not already properly set.

Sunday, October 12, 2014

Arduino IDE 1.5.8 on Banana Pi

I use Arch Linux on Banana Pi. In my previous post, I used a workaround to compile Arduino code on an x86_64 platform and then copy the *.hex file to upload to Arduino from Banana Pi. While i7-4770 is very fast, it's also very power hungry. I dug a little bit and managed to get Arduino IDE 1.5.8 running on my Banana Pi.

If you want to install Arduino 1.0.5-1, Arch Assualt Repo has an almost working version. To make it work, you'll need to install java-rxtx, and replace /usr/share/arduino/lib/librxtxSerial.so with a symlink to /usr/lib/librxtxSerial.so , and also RXTXcomm.jar -> /usr/share/java/rxtx/RXTXcomm.jar

Now, this is how I got version 1.5.8 working (thanks to this post for a pointer):

Use the following PKGBULID (modified from its AUR for x86 and x86_64) to build and install a package:

# Maintainer: Lauri Hakko # Contributor: PyroPeter # Contributor: darkapex pkgname=arduino-beta epoch=1 pkgver=1.5.8 pkgrel=1 pkgdesc="Arduino SDK Beta release" arch=('armv7h') url="http://arduino.cc/en/Main/Software" options=(!strip) license=('GPL') depends=('avr-libc' 'libusb-compat' 'java-runtime') install="arduino.install" conflicts=('arduino' 'arduino-toolchain') provides=('arduino') source=("http://downloads.arduino.cc/arduino-${pkgver//_/-}-linux32.tgz" 'arduino' 'arduino.png' 'arduino.desktop') md5sums=('289b1e3ad64f29db3ed13b06880dce40' '5e385c8cba80ca1b4227b162e4cad5cd' '9e36d33891d5e68d38ec55d1494499a5' 'eebc4d6495864bea99ad057af801afb9') package() { cd "$srcdir/arduino-${pkgver//_/-}" # arduino excutable should accept arguments sed -i 's/^java .* processing.app.Base$/\0 "$*"/' arduino mkdir -p "$pkgdir"/usr/{bin,share/{doc,applications,pixmaps}} # copy the whole SDK to /usr/share/arduino/ cp -r . "$pkgdir/usr/share/arduino" # at least support the FHS a little bit: install -m755 "$srcdir/arduino" "$pkgdir/usr/bin/arduino" ln -s /usr/share/arduino/reference "$pkgdir/usr/share/doc/arduino" # desktop icon install -m644 "$srcdir/arduino.desktop" "$pkgdir/usr/share/applications/" install -m644 "$srcdir/arduino.png" "$pkgdir/usr/share/pixmaps/" }

This version won't run because /usr/share/arduino/hardware/tools/* are compiled for x86. We need those files compiled for Arm7. Let's remove /usr/share/arduino/hardware/tools now.

Download a pre-compiled version 1.5.4 by UDOO folks (big thanks for their efforts!). Go to their download page, click on Driver & Tools, and click on Arduino IDE for UDOO. Unpack the archive. We only need arduino/hardware/tools . Move it to /usr/share/arduino/hardware/tools

Since 1.5.8 above expects avr tools in /usr/share/arduino/hardware/tools/avr, and Arch installs it separately, so we need to make another two symlinks.

$ ln -s /usr/bin /usr/share/arduino/hardware/tools/avr/
$ ln -s /etc /usr/share/arduino/hardware/tools/avr/

There's one more file we need to replace: arduino/lib/libastylej.so . I just installed astyle from archlinuxarm.org and do a symlink libastylej.so -> /usr/lib/libastyle.so

That's it.

Friday, October 10, 2014

Control Arduino IDE 1.5.8 with command line

My workbench for Arduino development does not have enough space for a high power PC so I use lower power Arm devices (Raspberry Pi, Banana Pi, and Yun Shield) instead. However, Arduino IDE 1.5.x is not well supported yet (Raspbery Pi has a working version but not the other two, which I prefer. UPDATE: I figured it out.), and several Makefile solutions are still buggy against 1.5.x's libraries.

My temporary solution is to outsource the compiling to the more powerful machine (my i7-4770 running Arch 64 finishes compilation almost instantly, as opposed to 40 seconds on Raspberry Pi), and grab the compiled *.hex file back to these Arm devices to upload to Arduino via the USB serial connection.

As of October 4, 2014, Arduino IDE 1.5.8 has a buggy command line parameter passing, so I cannot compile the code remotely without doing a remote X session, and I want to avoid having to run an X server on these Arm devices (although Banana Pi actually runs X quite well). Therefore, I use the following hack to trigger the compiling via the command line.

$ DISPLAY=:0 xdotool search --name "Arduino 1.5.8" windowactivate --sync windowfocus mousemove --window %1 10 30 click 1

xdotool searches for a window whose title contains "Arduino 1.5.8", activates the virtual desktop it's on, focuses on the window, moves the mouse cursor to coordinates (10,30) relative to the application window (where the "Verify/Compile" button is) and then clickes on it to trigger the compilation.

For some reason sending ctrl+r doesn't work for me. If anyone knows why, I'd love to know.

$ # this doesn't work
$ DISPLAY=:0 xdotool search --name "Arduino 1.5.8" windowactivate --sync windowfocus key ctrl+r