Jan 102011
WLAE-AG300N Ethernet Bridge

I bought recently 2 of those to replace a wireless connection I used before (see here for the details). I wanted to write a bit about those as they have some quirks.


  • Quite small and light.
  • Work as wireless bridge, access point and wireless repeater.
  • Has 2 Ethernet (10/100 MBit/s) ports for 2 devices, or more if connected to switches.
  • Works in the 2.4 and 5 GHz band, so you can turn on microwaves if you operate in the 5 GHz band.
  • AOSS/WPS works as advertised: you push buttons on them, and they find each other. For bridging, it’s super-simple. Default is 5 GHz band too.
  • Operation is transparent as it should be.


  • Those are not routers and cannot do NAT.
  • The web interface is in Japanese if you buy them in Japan, and the corresponding US model has yet no firmware to download. Good thing I have Google Translate to help me with most of the text.
  • They can only use either 2.4 or 5 GHz. Important when they work as wireless repeaters.


  • Default IP is They also use DHCP if they can. I should move to another network.
  • Changing the channel is not simple. I still don’t know how to do that. Seems that this is no longer possible if I have DFS. I cannot find a way to turn this off, but then, I don’t need to as it picked the correct band anyway.
  • The docs from the Buffalo US site shows small differences between the US and JP firmware. It’s not just translated. But the English manual is a big help.
  • That manual also writes:
    This sticker shows the AirStation’s SSID, default encryption key, and WPS PIN code.  By default, encryption is disabled for AirStations sold in Asia
    That explained why initially the wireless LED was blinking orange, as that manual also said: Blinking :  AOSS/WPS error. After setting a password, the blinking became a solid green (which means: 5 GHz wireless).
  • I have 2 and both are configured identical. Using AOSS buttons, one became a master and the other one a client. I don’t know which one is which though.
  • I set up fixed IPs on both. On one of them it works just fine: no DHCP requests. On the other one, constant DHCP requests. The DHCP server I have offers a good one (identical to the one I configured manually), but it’s not being accepted. At the same time, that unit works just fine with the assigned manual IP address. When I configure it to use DHCP, it immediately grabs one and is happy with it. Looks like a bug to me.
Jan 102011

While installing and configuring Wuala to start automatically on my headless server, I figured out I can use the same mechanism for PS3 Media Server (AKA PMS). So here the init.d script for PMS:


# Provides:          pms
# Required-Start:    $network $local_fs
# Required-Stop:     $network $local_fs
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: start pms headless


case "${1:-''}" in
        # start commands here
        echo "Starting PMS..."
        cd $PMSDIR
        su $PMSUSER -c "screen -d -m $PMSDIR/PMS.sh"

        # stop commands here
        echo "Stopping PMS..."
        p=`ps -ef | grep java | grep pmsuser | grep pms | awk '{print $2}'`
        if [[ "$p" = "" ]] ; then
                echo "PMS not running"
                kill $p

        # restart commands here
        $SELF stop
        sleep 5
        $SELF start

        # status commands here
        p=`ps -ef | grep java | grep pmsuser | grep pms | awk '{print $2}'`
        if [[ "$p" = "" ]] ; then
                echo "PMS not running"
                echo "PMS running with PID $p"

        # no parameter specified
        echo "Usage: $SELF start|stop|restart|status"
        exit 1


Jan 102011
OpenVPN Setup

My provider YahooBB!, who does otherwise a good job, blocks outgoing SMTP (25/tcp) traffic. That is generally a good thing since it limits spam caused by infected home PCs, but you cannot opt-out even if you know what you are doing and have no infected PCs, and a need to send out email.

Sending out emails via email client is no issue of course. But sendmail/postfix/etc. need a relay and the YahooBB! relay only accepts emails with its own email address. I don’t even use that one.

Well, there is always a technical solution for a technical problem. In this case: my virtual server in Germany. That one can send out emails just fine, so all I need to do, is to let it relay my emails from home. I just need a VPN connection from home to that machine.

I wanted to do this many times anyway, so time to do this now.

One problem I did not expect: The virtual server I use uses OpenVZ (or something similar), which does not allow or have a tap interface for bridging. So I need to use tun (which luckily exists), and use a tunnel and a P2P or generally a routed access. Browsing along with Google searching for a rather simple example for a network-to-client connection, it turned out to be not that easy and my router which is using OpenWRT, needs the OpenVPN package first. So I build a new flash image…and lost Internet access completely. Router simply not responding anymore. It can be de-bricked via TFTP, but given the limited time I have, no time for that, so I replaced it with another spare router which already has the OpenVPN package installed. Configuring the router part was simple. Wireless performance sucked though and in the system log I found a lot messages like:

ath: DMA failed to stop in 10 ms

causing patcket loss of about 15% overall. So I ordered those. With the laggard Internet connection I now had for the time being I figured out that OpenWRT does not do a good job of making it easy to create a network-to-client VPN. Me never having done this (I used OpenSWAN long time ago, but apparently too long to remember much of it), did not help here either.

So in the end I used a point-to-point tunnel from my virtual server in Germany to my file server at home.

Turned out to be surprisingly simple with those really nice instructions I found here. While the example is for CentOS and I use Debian, but that’s easy to fix. Small minor fixes on the script side were needed. For my and everyone’s benefit, here my instructions which heavily lean on the ones from John Malkowski from vpsnoc.com.

# Quick and dirty OpenVPN install script
# Tested on Centos 5.x 32bit, openvz minimal CentOS OS templates
# Please submit feedback and questions at support@vpsnoc.com
# John Malkowski vpsnoc.com 01/04/2010
# Adjusted and used as an example for Debian by Harald Kubota 2011-01-09


aptitude install openvpn

cd /etc/openvpn/

cp -R /usr/share/doc/openvpn/examples/easy-rsa/ /etc/openvpn/
cd /etc/openvpn/easy-rsa/2.0/
chmod +rwx *

# Edit vars here. I like emacs.

emacs vars

. ./vars
source ./vars
echo -e "\n\n\n\n\n\n\n" | ./build-ca
./build-key-server server
cp keys/{ca.crt,ca.key,server.crt,server.key,dh1024.pem} /etc/openvpn/

# Repeat for every client, you can choose more meaningful names too

for i in client1 client2 client3 ; do

./build-key $i
cd keys/

# client $i
log /tmp/openvpn.log
verb 3
remote $ip 1194
dev tun
ca ca.crt
cert $i.crt
key $i.key
route-delay 2
route-method exe
#redirect-gateway def1
#dhcp-option DNS"

echo "$client" > $HOSTNAME.conf

tar czf $i-keys.tgz ca.crt ca.key $i.crt $i.csr $i.key $HOSTNAME.conf
mv $i-keys.tgz /root


log /tmp/openvpn.log
verb 3
dev tun
ifconfig-pool-persist ipp.txt
ca ca.crt
cert server.crt
key server.key
dh dh1024.pem
push "route"
#push "redirect-gateway"
keepalive 10 60
group nogroup

echo "$opvpn" > /etc/openvpn/openvpn.conf

# Enable IP forwarding
echo 1 > /proc/sys/net/ipv4/ip_forward
#iptables -t nat -A POSTROUTING -s -o venet0 -j MASQUERADE
#iptables-save > /etc/sysconfig/iptables
#sed -i 's/eth0/venet0/g' /etc/sysconfig/iptables # dirty vz fix for iptables-save
#echo "net.ipv4.ip_forward=1" >> /etc/sysctl.conf

/etc/init.d/openvpn start

That was the server part. For the client, copy the (e.g.) client1-keys.tgz package and extract into /etc/openvpn/ on the client.
A simple /etc/init.d/openvpn start will then initiate the VPN connection.

Note that the default gateway is not changed. This is a strict P2P connection. Default traffic will be not re-directed. If you want to redirect all traffic to the VPN server, then un-comment the redirect-gateway related messages. You have most likely have to set up NAT on the VPN server too. Since this is not needed in my case, I leave this as an exercise to the reader.

Jan 092011
Wuala on a Headless System

From my colleague Soren I heard first about Wuala. Did sound interesting back then. But I never found a use for it. I have a total of about 30G online storage space and hardly know how to use it. Too complex to connect to and too slow to use.

Recently when looking at PogoPlug Pro model, I found it quite intriguing as now I have a mobile Android device which could use it well. However The PogoPlug cannot be bought (via normal channels) in Japan. Or even sent to Japan. Curse you Amazon!  Buffalo to the rescue! Except theirs is not yet available. Looks promising though as it includes 2 disks already. I’ll look into this when it’s available.

If anyone wonders, what PogoPlug and Wuala have in common, then stop wondering. Not much beside the “storage” and “cloud”. They solve different problems.

Anway, that’s why I looked into Wuala again. And hey, it works quite well. Integration with Linux is great Shows up as a mounted filesystem. Speed is slow though. Time to upgrade that old ADSL into something more speedy.

Now the important message of this posting: How to make Wuala run on a headless server. The solution was found here and here. I used the latter. Works as advertised and starts up nicely in the background via screen.

What I am waiting for now is to connect to that Wuala instance from my notebook (see here in the Wuala forum).

Jan 052011
Milestone 2 in Japan

I finally succumbed to the Android wave. It was always on my “nice-to-have” list but unfortunately also on the “running-costs-are-too-high” list. The prices range from about 30000 Yen up-front and about 10000 Yen/month running costs. And 2 years contracts.

Enter the age of SIM-lock free phones available in Japan. Thanks to Expansys I got a Motorola Milestone 2. The main reason was: new enough (Android 2.2) and it has a keyboard. And being SIM-lock-free means while I am outside Japan, I can get a (cheap) local SIM card and use it. Not a big deal, but a nice-to-have.

Android is only half as much fun without 3G connections, but neither Softbank nor Docomo like different than their own handsets. They’ll punish you with a special this-ain’t-our-handset monthly flat rate of about 11000 Yen max instead of 6000 Yen.

However b-mobile has a neat solution: b-mobileSIM U300: It’s using the Docomo FOMA (3G) network, runs on 850MHz and 2100MHz (compatible with W-CDMA). Costs about 13000 Yen for 6 months for a data flat rate, so about 2200 Yen/month. That’s far less than what Docomo and Softbank charge you, but it comes with 2 caveats:

  1. No voice, only data (read: Internet ok, nothing else, e.g. voice calls, SMS, etc.)
  2. Capped at 300 kbps

The main point for me of this handset is to have Internet and email available while commuting, so I do not need to spend much time at home reading and replying to emails or checking out things on the Internet. Watching video or streaming music is not high on my list of things I want to do while traveling, so those limitations I can live with.

Google Maps is a bit sluggish. Needs patience. Quite a lot, especially when used with satellite view or Street View.