Mithilfe von OpenWRT befreien Sie den knuffigen kleinen Router TP-Link TL-MR3020 von seiner proprietären Firmware und bauen ihn zum Allround-Server fürs heimische Netz um.

Die Firma TP-Link [1] aus China produziert Router verschiedenster Leistungsklassen. Den TL-MR3020 (Abbildung 1) vermarktet der Hersteller als “Mobile Router”, da er klein und leicht ist. Allerdings unterstützt er kein 3G (siehe Kasten “Die Hardware”), das lässt sich aber über den USB-Port nachrüsten.

Attraktiv ist der Router also vor allem für jene, die kein 3G brauchen oder sowieso schon einen UMTS-Stick haben und deshalb nicht in einen teuren UMTS-Mobile-Router investieren wollen. Hier soll aber nicht die “normale” Nutzung des Routers im Mittelpunkt stehen, sondern dessen Ausbau zu einem Mini-Server.

Dazu ersetzen wir die vorhandene Firmware durch OpenWRT [2], eine auf Kleinstgeräte spezialisierte Linux-Distribution. OpenWRT besitzt ein Paketmanagementsystem, das jenem der klassischen Distributionen in Nichts nachsteht, und so stehen den eigenen Vorstellungen nur die Grenzen der Hardware entgegen.

Abbildung 1: Der TL-MR3020 von TP-Link (links) ist nicht größer als ein Handteller. Der Mini-USB-Hub von Pearl rechts daneben dient Erweiterungszwecken.

Auftakt

Der TL-MR3020 eignet sich aus zwei Gründen für unsere Zwecke gut: Einerseits kostet er mit 30 Euro nicht die Welt – falls Sie ihn einmal “bricken”, dann tut das dem Geldbeutel nicht zu sehr weh. Andererseits baut der Hersteller keinerlei Hindernisse ein, welche die Installation einer fremden Firmware verhindern.

Laden Sie also die passende OpenWRT-Version herunter [3] und verbinden Sie sich gemäß der knappen, doch ausreichenden Anleitung des Routers mit der Weboberfläche des Geräts. Dort laden Sie die neue neue Firmware per Upload im Webformular auf den TL-MR3020 (Abbildung 2).

Abbildung 2: OpenWRT laden Sie als Firmware-Update über die originale Weboberfläche auf den TL-MR3020.

Dabei handelt es sich um den einzigen wirklich kritischen Schritt bei der ganzen Sache. Ein fehlerhaftes Firmware-Image sendet den Router ins Nirvana – nur wer löten kann, hat noch eine Chance. Lesen Sie deshalb vor dem Einspielen unbedingt noch einmal die einschlägigen Artikel im OpenWRT-Wiki [3] durch und beachten Sie die entsprechenden Hinweise.

Nach der Installation von OpenWRT steht zunächst die Basiskonfiguration an, insbesondere des Netzwerks. Als nächstes kommt das Einrichten einer Reihe von Softwarepaketen, welche die USB-Unterstützung von Datenspeichern (USB-Sticks oder Festplatten) nachrüsten. Dadurch kann der Router dann von einem externen Datenträger starten. Auf dem so erweiterten Root-Dateisystem landen dann weitere Softwarepakete aus dem OpenWRT-Repository für den eigentlichen Anwendungszweck.

Erster Kontakt

Nach dem Firmware-Upgrade und dem Neustart des Geräts verbinden Sie Ihren PC oder Laptop per Kabel mit dem Router, konfigurieren das Netzwerk (normalerweise sorgt der Netzwerkmanager dafür) und melden sich per Telnet auf der Adresse 192.168.1.1 an (auf dem Router läuft ein DHCP-Server, der den PC oder Laptop mit einer geeigneten Adresse versorgt).

Abbildung 3: Geschafft: Die erste Anmeldung an OpenWRT steht an.

An dieser Stelle setzen Sie ein Passwort für root. OpenWRT schaltet dann aus Sicherheitsgründen den Telnet-Server ab und fährt den SSH-Server hoch. Als nächstes passen Sie die Netzwerkkonfiguration so an, dass der Router im heimischen Netzwerk arbeitet, anschließend kommt zusätzliche Software auf den Rechner. Details zum Konfigurationssystem von OpenWRT lesen Sie im Kasten “OpenWRT konfigurieren” nach.

Da wir den Router als Server im Heimnetz nutzen wollen, sieht die Netzwerkkonfiguration so aus wie in Listing 1 (/etc/config/network) und Listing 2 (/etc/config/wireless) gezeigt. Die Zeilen 9 bis 15 von Listing 1 konfigurieren das WLAN-Interface. In Listing 2 sorgt die Zeile 19 dafür, dass der Server sich als WLAN-Client ins Netz integriert, nicht etwa als Access-Point beziehungsweise Router.

Nach einem beherzten Neustart findet sich das Gerät (hoffentlich) unter der konfigurierten Netzwerkadresse. Falls nicht, hilft der Notfall-Modus: Während des Bootens drücken Sie die WPS-Taste, sobald diese anfängt zu blinken. Wenn die LED-Lampe schneller blinkt, dann lassen Sie sie wieder los. Jetzt befindet sich das Gerät im sogenannten Failsafe-Modus, auf der vorgegebenen Adresse 192.168.1.1 läuft jetzt der Telnet-Daemon. Mit dem verbinden Sie sich und nehmen die notwendigen Korrekturen vor. Allerdings steht in diesem Modus auf dem Router kein DHCP-Server zur Verfügung: Sie müssen Ihrem eigenen Rechner per Hand eine passende IP-Adresse zuweisen.

# /etc/config/network -----------------
 config interface 'loopback'
    option ifname 'lo'
    option proto 'static'
    option ipaddr '127.0.0.1'
    option netmask '255.0.0.0'
 config interface 'wifi'
         option proto 'static'
         option ipaddr '192.168.3.100'
         option netmask '255.255.255.0'
         option gateway '192.168.3.1'
         list dns '192.168.3.1'
         list dns '8.8.8.8'

# /etc/config/wireless ---------------
 config wifi-device  radio0
    option type     mac80211
    option channel  11
    option macaddr 90:f6:52:e6:d7:b2
    option hwmode  11ng
    option htmode  HT20
    list ht_capab  SHORT-GI-20
    list ht_capab  SHORT-GI-40
    list ht_capab  RX-STBC1
    list ht_capab  DSSS_CCK-40
    # REMOVE THIS LINE TO ENABLE WIFI:
    # option disabled 1
 config wifi-iface
    option device     radio0
    option network    wifi
    option mode       sta
    option ssid       'meine-ssid'
    option encryption psk2
    option key        'geheim'

$ uci get system.slider.handler

Abbildung 4: Über die Weboberfläche von OpenWRT lassen sich auch Konfigurationsdaten abfragen.

Mehr Software

Das ursprüngliche Firmware-Image enthält nicht alle Komponenten, die für den Betrieb eines Root-Dateisystems auf USB-Stick notwendig sind. Hier gilt es nachzurüsten. Dank die erfolgreich absolvierten Netzwerkkonfiguration kommt der Mini-Router bereits ins Internet, und über das komfortablen Paketmanagementsystem bereit das Nachinstallieren von Software keine Probleme.

Dreh- und Angelpunkt ist das Kommando opkg, das Sie als root ausführen. Mit dem Aufruf opkg update aktualisieren Sie zuerst einmal die Paketliste. Anschließend installieren Sie die angegebenen Pakete mit dem Kommando

# opkg install Paket ...

Suchen Sie etwas Bestimmtes, hilft das Subkommando list, das eine Paketliste samt Kurzbeschreibungen auswirft.

Für die USB-Installation benötigen Sie in erster Linie eine Reihe von Kernelpaketen (Listing 3). Den USB-Stick (im Listing /dev/sdb – das müssen Sie gegebenenfalls anpassen) partitionieren und formatieren Sie am besten an Ihrem PC. Nützlich ist neben einer Root-Partition noch eine Home-Partition und vor allem Swap-Space.

# Root-Dateisystem auf USB-Stick einrichten
# Basis USB-support (USB 1.1 and USB 2)
opkg update
opkg install kmod-usb-uhci kmod-usb-ohci kmod-usb2
insmod uhci
insmod usb-ohci
insmod usbcore
insmod ehci-hcd
# USB-Storage (FAT benötigt zusätzliche Module,
# das kann man aber später nachrüsten
opkg install kmod-usb-storage block-mount kmod-fs-ext4 kmod-scsci-core
# USB-Stick vorbereiten (auf dem PC)
# -> Partitionieren mit drei Partitionen (root,home,swap)
#    fdisk /dev/sdb usw.
# -> Partitionen mit ext4 bzw. swap formatieren
#    mkfs.ext4 /dev/sdb1
#    mkfs.ext4 /dev/sdb2
#    mkswap    /dev/sdb3
# Root auf USB vorbereiten (kopiert altes Root-Dateisystem)
mkdir -p /mnt/usb
mount /dev/sda1 /mnt/usb
tar -cvf - -C /overlay . | tar -xf - -C /mnt/usb
umount /mnt/usb

Danach stöpseln Sie den Stick an den Router an und ändern die Konfiguration der Mountpoints in der Datei /etc/config/fstab. Wichtig sind hier die Zeilen 10 bis 16 aus Listing 4. Die letzten Zeilen von Listing 3 kopieren das gesamte Root-Dateisystem auf den Stick. Hier lohnt es sich, gleich ein Backup anzulegen. Das System bootet übrigens auch ohne den eingesteckten Stick: In diesem Fall ignoriert es einfach die nicht vorhandenen Devices.

# Mountpoints konfigurieren
config global automount
   option from_fstab 1
   option anon_mount 1
config global autoswap
   option from_fstab 1
   option anon_swap 0
config mount
  option target       /overlay
  option device       /dev/sda1
  option fstype        ext4
  option options       rw,sync
  option enabled       1
  option enabled_fsck  0
config mount
   option target       /home
   option device       /dev/sda2
   option fstype       ext4
   option options      rw,sync
   option enabled      1
   option enabled_fsck 1
config swap
   option device       /dev/sda3
   option enabled      1

Nach einem Reboot mit angeschlossenem Stick steht endlich mehr Plattenplatz bereit. Zusätzlich installierte Pakete landen jetzt direkt dort. Insgesamt ist das Root-Dateisystem auf einem USB-Device sehr praktisch: Es erlaubt einerseits die Konfiguration mit den gewohnten Editoren an einem PC, und auch das Hin- und Herkopieren von Daten (zum Beispiel für Backups) fällt leicht.

An dieser Stelle ist die Basiskonfiguration bis auf ein paar Kleinigkeiten (etwa den Hostnamen) erledigt. Das weitere Vorgehen hängt vom Einsatzzweck des Routers ab. Via Paketmanagement holen Sie sich die benötigte Software und konfigurieren diese. Das Vorgehen unter OpenWRT unterscheidet sich dabei nicht von jenem unter anderen Distributionen.

Knöpfe und LEDs

Den TL-MR3020 als Mini-Server können Sie vollständig per Secure Shell oder Webinterface steuern. Einfacher geht es aber über die vorhandenen Buttons. Der ursprüngliche WPS-Taster eignet sich dabei zum Auslösen einzelner Aktionen, während der Schiebeschalter an der Seite mit seinen drei Positionen das Umschalten zwischen verschiedenen Betriebszuständen übernimmt. Dazu weiter unten mehr.

Die LEDs dienen dabei quasi als Ausgabegerät. Hier sind drei unterschiedliche Zustände möglich: An, aus oder blinkend. In Kombination mit den Buttons kann man hier nette Features bauen. Technisch gesehen steuert man die LEDs über Dateien unterhalb von /sys/class/leds, für die WPS-LED ist dies etwa das Verzeichnis /sys/class/leds/tp-link:green:wps. Die Macher von OpenWRT haben aber die gesamte Komplexität gekapselt, Sie müssen im Normalfall nur noch die Konfiguration in der Datei /etc/config/system anpassen (Listing 5, Zeilen 13 bis 35).

# Konfiguration von LEDs und Buttons
config system
   option hostname 'jupiter.bablokb-local.de'
   option timezone 'CET-1CEST,M3.5.0,M10.5.0/3'
config timeserver 'ntp'
   list server '0.openwrt.pool.ntp.org'
   list server '1.openwrt.pool.ntp.org'
   list server '2.openwrt.pool.ntp.org'
   list server '3.openwrt.pool.ntp.org'
   option enable_server '0'
config led 'led_usb'
   option name 'USB'
   option sysfs 'tp-link:green:3g'
   option trigger 'usbdev'
   option dev '1-1'
   option interval '50'
config led 'led_wlan'
   option name 'WLAN'
   option sysfs 'tp-link:green:wlan'
   option trigger 'phy0tpt'
config led 'led_lan'
   option name 'LAN'
   option sysfs 'tp-link:green:lan'
   option trigger 'netdev'
   option dev 'eth0'
   option mode 'link tx rx'
config led 'led_wps'
        option name 'wps'
        option sysfs 'tp-link:green:wps'
        option trigger 'default-on'
config button
        option button 'wps'
        option action 'released'
        option min '3'
        option max '6'
        option handler 'halt'
config button
        option button 'wps'
        option action 'released'
        option min '0'
        option max '2'
        option handler 'logger wps pressed 0-2s'
config slider 'slider'
        option handler '/usr/sbin/handle_slider'

Im Normalfall koppelt OpenWRT die LED-Aktivität an die Betriebszustände einzelner Komponenten, wie des Netzwerks oder der USB-Schnittstelle. Diese Vorgaben können Sie aber nach Ihren Wünschen frei anpassen.

Auch die Konfiguration der Schalter ist einfach. Zum einen müssen Sie das Event-System des Kernels so konfigurieren, dass er für die Buttons entsprechende Events auslöst. Hierzu editieren Sie die Datei /etc/hotplug2.rules und entfernen das Caret (das “Dach”) vor dem String ^Buttons. Da es sich hier um eine Ausnahmeliste handelt, aktivieren Sie durch das Entfernen die Events für die Buttons. Ab jetzt führt das System für jeden Button-Event alle Skripte im Verzeichnis /etc/hotplug.d/button aus. Dabei sind die Variablen BUTTON und ACTION gesetzt.

Ein Beispiel, das auch das Zusammenspiel mit den LEDs demonstriert, zeigt Listing 6. Dieses Skript wirkt nur für den WPS-Taster (Zeile 22) und sorgt dafür, dass die WPS-LED drei Sekunden blinkt (Zeilen 6 bis 8 und 10). Dann erlischt es für weitere drei Sekunden. Lassen Sie die Taste los, schaltet das Skript die LED wieder ein (Zeile 19).

#!/bin/sh
# Button-Events verarbeiten
set_led_blink() {
# Blinken einschalten (1s an / 0,2s aus)
  echo timer > /sys/class/leds/tp-link\:green\:wps/trigger
  echo 1000 > /sys/class/leds/tp-link\:green\:wps/delay_on
  echo  200 > /sys/class/leds/tp-link\:green\:wps/delay_off
# nach drei Sekunden abschalten
  sleep 3
  echo none > /sys/class/leds/tp-link\:green\:wps/trigger
# nach drei Sekunden wieder anschalten
  sleep 3
  set_led_on
}
set_led_on() {
# LED anschalten
  echo default-on > /sys/class/leds/tp-link\:green\:wps/trigger
}
if [ "$BUTTON" = "wps" ]; then
  if [ "$ACTION" = "pressed" ]; then
    set_led_blink &
  else
    set_led_on
  fi
else
  exit 0
fi

Anstatt jetzt jedes Skript einzeln im Button-Verzeichnis abzulegen und dort wie im Listing 5 den Status des Schalters abzufragen, lohnt es sich, ein generisches Button-Skript aus dem OpenWRT-Fundus [4] herunterzuladen. Danach konfigurieren Sie die Schalter ganz einfach analog zu den LEDs in /etc/config/system.

Dort ist der WPS-Button als Ausschalter konfiguriert: Lassen Sie ihn nach mindestens drei und maximal sechs Sekunden los, dann fährt das System herunter (Zeilen 37 bis 42 in Listing 5). Hier erschließt sich auch der Sinn des Programms aus Listing 6, denn die LED des Buttons blinkt während drei Sekunden und geht dann für drei Sekunden aus – Sie müssen also nicht mitzählen, um das System herunterzufahren.

Ebenso könnten Sie den WPS-Taster auch nutzen, um mit kurzen Klicks eine andere Aktion zu starten. Listing 5 konfiguriert hier in den Zeilen 44 bis 49 zu Demonstrationszwecken einen Log-Eintrag.

Der Schiebeschalter

Der Schiebeschalter des TL-MR3020 macht aus zwei Gründen etwas mehr Arbeit: Erstens sieht der Kernel im Schiebeschalter nicht einen, sondern zwei Buttons, denn um dessen drei Zustände abzubilden, braucht es zwei Bits. Jede Änderung des Schalters löst also zwei Events aus, die zwar sequenziell bei den Verarbeitungsskripts ankommen, aber gemeinsam ausgewertet werden müssen. Zweitens bekommt das Event-System nur Änderungen mit.

Um also beim Booten den Status des Schiebeschalters abzufragen – etwa zur Konfiguration der Netzwerkumgebung – gilt es ein kleines Skript zu bemühen. Dieser Aspekt ist im OpenWRT-Wiki jedoch nur andeutungsweise dokumentiert. Listing 7 zeigt, wie es geht: Das Skript hinterlegt den Status der beiden Buttons BTN_0 und BTN_1 in entsprechend benannten Dateien unter /var/run. Das Skript läuft zum Systemstart einmalig, gestartet aus /etc/rc.local.

#!/bin/sh
# Auslesen des Sliders (aka BTN_0/BTN_1)
# rmmod verwendet underscores, bei insmod sind es Striche!
rmmod gpio_button_hotplug                         # Kernel-Modul entf.
echo 18 > /sys/class/gpio/export                  # export BTN_0
echo 20 > /sys/class/gpio/export                  # export BTN_1
cat /sys/class/gpio/gpio18/value > /var/run/BTN_0 # Status BTN_0
cat /sys/class/gpio/gpio20/value > /var/run/BTN_1 # Status BTN_1
echo 18 > /sys/class/gpio/unexport                # unexport BTN_0
echo 20 > /sys/class/gpio/unexport                # unexport BTN_1
insmod gpio-button-hotplug                        # Kernel-Modul laden

Das Skript in Listing 8 dagegen läuft bei jedem Button-Event. Es aktualisiert den Button-Status im Verzeichnis /var/run. Zusätzlich startet es ein Verarbeitungsskript. Die zusätzliche Magie in den Zeilen 10 bis 12 sorgt dafür, dass nur ein Verarbeitungsskript anläuft. Die Wartezeit vor der Verarbeitung (Zeile 21) sorgt dafür, dass alle relevanten Button-Events auch eingetroffen und verarbeitet sind. Die Zeilen 16 und 17 holen das Verarbeitungsskript aus der Konfigurationsdatei /etc/config/system. Das Verarbeitungsskript startet dann in Zeile 22.

#!/bin/sh
# Events des Sliders verarbeiten
. /lib/functions.sh
DELAY=5
LOCK=/var/run/slider.lock
# --- Update ausführen (asynchron) ---
run_handler() {
  # nur starten, falls nicht schon aktiv
  if ! mkdir "$LOCK" 2>/dev/null; then
    logger "update-script läuft schon"
    exit 0
  fi
  # Verarbeitungsskript aus der /etc/config/system lesen
  config_load system
  config_get handler slider handler
  logger "handler-script: $handler"
  logger "warte $DELAY Sekunden auf alle Events"
  sleep $DELAY
  eval $handler                   # Handler ausführen
  rm -fr "$LOCK"
}
# --- Hauptprogramm ------------------
logger "Verarbeite Event '$ACTION' für $BUTTON"
# WPS-Button ignorieren
if [ "$BUTTON" = "wps" ]; then
  exit 0
fi
# Update Button-Datei gemäß Event
if [ "$ACTION" = "pressed" ]; then
  echo "1" > "/var/run/$BUTTON"
else
  echo "0" > "/var/run/$BUTTON"
fi
              # asynchron ausführen
run_handler & # (Event-Verarbeitung nicht blockieren)

Ein Beispiel für ein solches Skript zeigt Listing 9. Es liest den Status des Schiebeschalters und konfiguriert das Netzwerk um. Die eigentlichen Netzwerkdateien liegen nur als symbolische Links vor; die Umkonfiguration besteht also darin, die Symlinks auf die neuen Konfigurationsdateien zu legen.

Dabei enthält zum Beispiel /etc/config/network.AP die Konfiguration für das Netzwerk, wenn der Slider auf AP steht. Sinnvollerweise starten Sie das Verarbeitungsskript auch einmal beim Systemstart (in /etc/rc.local, nach dem Auslesen des Slider-Status).

#!/bin/sh
# Verarbeitungsskript für den Slider
logger "Führe $0 aus"
# Status des Sliders auslesen
if [ `cat /var/run/BTN_0` = "0" ]; then
  slider="WISP"
elif [ `cat /var/run/BTN_1` = "0" ]; then
  slider="3G"
else
  slider="AP"
fi
logger "Status des Sliders: $slider"
# Alte Symlinks entfernen
rm /etc/config/dhcp
rm /etc/config/network
rm /etc/config/wireless
# Neue Symlinks setzen
ln -s dhcp.$slider     /etc/config/dhcp
ln -s network.$slider  /etc/config/network
ln -s wireless.$slider /etc/config/wireless
# Netzwerk und DHCP neu starten
/etc/init.d/network restart
/etc/init.d/dnsmasq restart

Fazit

Damit ist die Hardware erklärt, Sie müssen “nur” die einzelnen Komponenten verbinden. Ausführliche Informationen dazu – etwa, um einen UMTS-Stick zum Laufen zu bringen oder für die Implementierung spezieller Netzwerkszenarien – finden Sie im OpenWRT-Wiki.

Der kleine Router kann nicht jeden Anwendungsfall abdecken. Aber die Mechanismen, die dieser Artikel beschreibt, gelten so oder zumindest ähnlich auch für andere Geräte, auch solche andere Hersteller. Am oberen Ende des Leistungsspektrums stehen dabei die QNAP-NAS-Geräte, die sogar nativ mit OpenWRT ins Haus kommen. Hier macht allerdings die Fülle der vorkonfigurierten Dienste eigene Anpassungen deutlich schwieriger.