WLAE-AG300N Ethernet Bridge

 Uncategorized  No Responses »
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.

Pros:

  • 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.

Cons:

  • 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.

Quirks:

  • Default IP is 192.168.11.100. 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.

PMS Autostart on a Headless System

 Uncategorized  No Responses »
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:


#!/bin/bash

### BEGIN INIT INFO
# 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
### END INIT INFO

PMSUSER=pmsuser
PMSDIR=/home/pmsuser/pms
BACKPWD=`pwd`

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

  'stop')
        # 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"
        else
                kill $p
        fi
    ;;

  'restart')
        # restart commands here
        $SELF stop
        sleep 5
        $SELF start
    ;;

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

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

cd $BACKPWD

OpenVPN Setup

 Uncategorized  No Responses »
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 [email protected]
# John Malkowski vpsnoc.com 01/04/2010
# Adjusted and used as an example for Debian by Harald Kubota 2011-01-09

ip="the.ip.address.on.the.server"

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
./clean-all
source ./vars
echo -e "\n\n\n\n\n\n\n" | ./build-ca
./build-key-server server
./build-dh
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="
# client $i
log /tmp/openvpn.log
verb 3
client
remote $ip 1194
dev tun
comp-lzo
ca ca.crt
cert $i.crt
key $i.key
route-delay 2
route-method exe
#redirect-gateway def1
#dhcp-option DNS 10.8.0.1"

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

done

opvpn='
log /tmp/openvpn.log
verb 3
dev tun
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
ca ca.crt
cert server.crt
key server.key
dh dh1024.pem
push "route 10.8.0.0 255.255.255.0"
#push "redirect-gateway"
comp-lzo
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
group nogroup
daemon'

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

# Enable IP forwarding
echo 1 > /proc/sys/net/ipv4/ip_forward
#iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -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.