BIRD manuel auf DD-WRT einrichten

Wenn man die Buffalo DD-WRT Version einsetzt und Routing (RIP, OSPF, BGP) aktiviert und sich danach nichts tut, sollte man mal mittels SSH Kontrollieren ob überhaupt ein Routing-Dienst läuft. Dazu muss man erst mal raus finden welcher dienst überhaupt laufen sollte. Das geht ganz einfach. In der Konsole versuchen „zebrad“ oder „bird“ aufrufen. Schlägt letzterer an muss man wie folgt vorgehen um den BIRD „manuell“ einzurichten.

Als erstet den Router-Modus zurückstellen auf „Gateway“, nicht das einem die Einstellungen aus der WebGUI in die Suppe spucken. Anschließend erstellt man das Verzeichnis /tmp/bird und die Datei /tmp/bird/bird.conf. Diese Datei gestaltet man nach seinen Wünschen und startet dann den BIRD.

mkdir /tmp/bird
vi /tmp/bird/bird.conf
bird

Eine Beispiel-Config findet man hier: Routing unter Ubuntu

Um das ganze zu automatisieren, muss die Config-Datei im NVRam hinterlegen.

nvram set zebra_conf="$(cat /tmp/bird/bird.conf)"
nvram commit

Beim Systemstart muss mittels des Startup-Skriptes das Verzeichnis und die Config-Datei angelegt werden.

mkdir /tmp/bird
nvram get zebra_conf > /tmp/bird/bird.conf

Den BIRD nicht beim Systemstart starten. Leider schießt die ServiceKontrolle/ProcessMonitor den BIRD automatisch ab wenn er da ist und ein Interface hochfährt (oder sich allgemein was ändert). Da die Speichervariablen (die ich noch nicht ermitteln konnte) keinen BIRD-Start vorsehen, wird er leider nicht nach gestartet.
Der richtige „Ort“ zum startet den BIRD ist daher das Firewall-Scriptes. Das wird immer ausgeführt, sobald sich an den Interfaces was ändern und ganz wichtig, es ist das letzte Skript.

if [ -ne $(pidof bird) ]; then
bird
fi

Das IF-Statement verhindert nur, dass der BIRD nochmal gestartet wird, wenn er schon existiert.

Auto-Reconnect für DD-WRT

Aus irgendeinem, mir noch nicht ganz nachvollziehbaren Grund, erkennt der pppd manchmal nicht, dass das ppp-Interface down ist und keine Verbindung mehr besteht. Um das zu beheben muss man normalerweise das WebInterface aufrufen und „reconnect“ drücken. Das kann man auch automatisieren.

Als erstes erstellt man eine Datei unter /tmp/connection_tracker.sh

#!/bin/sh

if [ $(ping -c 1 $(nvram get wan_ipaddr)|grep -c from) -lt 1 ]; then 
  logger -t connectiontracker nvram get wan_ipaddr unreachable
  killall redial; 
  killall pppd; 
  sleep 5 
  pppd file /tmp/ppp/options.pppoe >/dev/null; 
  logger -t connectiontracker reconnect wan nvram get wan_ipaddr successfully 
fi

Was macht das Script? Es versucht die IP des WAN-Interfaces zu pingen. Ist das Down gibt es keinen Treffer. „grep“ wertet die Rückgabe des ping Befehls aus und zählt die Zeilen. Gibt es weniger als einen Treffer (also Null) wird der redial und pppd gestoppt und neu gestartet.

Anschließend fügt man eine NVRAM-Variable hinzu. Gibt es die Variable wird sie überschieben, Ansonsten wird sie angelegt.

nvram set rc_custom="$(cat /tmp/connection_tracker.sh)"
nvram commit

Über den Startup-Script/Command muss diese Datei nun immer angelegt werden.

nvram get rc_custom>/tmp/connection_tracker.sh

Über einen zusätzlichen Cron-Job die Überprüfung alle 15-Minuten durchführen.

*/15 * * * * root /tmp/connection_tracker.sh

DD-WRT im Einsatz – ein Fazit

Vor gut einem Monat durfte ich meine lokale Netzwerkstruktur ein wenig wenig umbauen. Dabei habe ich meinen alten Netgear Router rausgeschmissen. Ich wollte ein bisschen was „professionelleres“. Nach kurzer Suche bin ich auf Geräte-Serien gestoßen, die nativ mit DD-WRT unterstützen (ein kommerzieller Ableger der OpenWRT-Firmware). Hängen geblieben bin ich bei zwei Buffalo-Geräten:

  • WHR-HP-G300N (400 MHz/32MB Ram)
  • WZR-HP-AG300H (680 MHz/128MB Ram)

Beide Geräte werden ab Werk mit DD-WRT ausgeliefert. Die Hardware-Ausstattung ist für meine Verhältnisse üppig und reicht für den Home und Medium-Office Bereich. Auch wenn beide „eigentlich“ DD-WRTv24Sp2 einsetzten unterscheiden sich die tatsächlich eingesetzten Firmwares doch stark. Sie unterscheiden sich vor allem im Release-Date und den verfügbaren Features. Der kleinere G300N vermisst zum Beispiel CIFS Support, OpenVPN, beschreibbaren Speicher (JFFS2) usw.  Dazu kommen Unterschiede in den ausgelieferten Software-Versionen. Beim G300N kommt BIRD als Routing-Daemon zum Einsatz, beim AG300H wird Quagga angeboten. Man könnte beide Geräte auch auf die offizielle DD-WRT Version zurück flashen, diese hingt der „Buffalo“ Version jedoch im Release hinterher (keine Ahnung was das für Auswirkungen hat). Leider bietet Buffalo die Sourcen der DD-WRT Software nicht zum download (oder ich hab den Link noch nicht gefunden) so muss man mit einigen „Eigenheiten“ leben. Dazu gleich mehr. Neben einem Farbbranding und ein paar Funktionseinschränkungen entspricht die Buffalo Version von DD-WRT der frei verfügbaren DD-WRT-Version.

Als erstes fällt beim Einsatz von DD-WRT auf, dass man nicht für einen Idioten gehalten wird. Man kann den Assistenten wegklicken! Nach der Änderung des Passwords  darf man auf Wunsch gleich loslegen ohne sich durch einen Nerf-Dialog zu klicken. Standardmäßig ist Telnet und HTTP als „Fernwartung“ aktiviert. Das kann man aber einfach umkonfigurieren. SSH und HTTPS werden angeboten. Beide Varianten haben kleine Haken. HTTPS verwendet „fest“ eingebrannte selbst signierte Zertifikate (und ich würde wetten, dass die priv Keys nur pro Version-Build unterschiedlich sind). Will man dieses austauschen muss man gleich eine eigene Firmware einspielen da der /etc Bereich read-only gemounted ist. SSH bietet hingegen die Möglichkeit die Zertifikate zu ändern. Standardmäßig logt man sich dort hingegen als root ein. Da ist Vorsicht bei den Passwörtern geboten!

Neben diesen beiden „Fehlern“ fällt nur noch der Umstand auf, dass die Konfigurationsoberfläche stark auf den Betrieb eines Gateway-Routers ausgelegt ist. Hat man sich damit einmal abgefunden und verstanden, dass das br0-Interface (intern werden Birdges verschaltet) immer „das Interne“-Interface ist, entfaltet sich eine Konfiguationsvielfalt, die man sonst nur bei hochpreisigen Konkurrenten findet. Ein Beispiel: um auf den WAN – Port (eth1) zwei VLANs zu konfigurieren braucht es 3 Klicks. Will man WAN-VLAN1 ins br0-Netz bridgen ist das ein weiterer Klick. Will man nun das WLAN aus dem br0 nehmen und auf WAN-VLAN2 bridgen geht das mit unter 5 Klicks. Ohne auch nur ein mal das SSH-Terminal zu nutzen. Auf diesem Niveau geht es weiter. Statische Routen, sehr detaillierte Interface-Konfigurationen, fast alle Services und diverse Hilfseinstellungen lassen sich über das WebInterface bequem und umfangreich konfigurieren.

Ich hab den SSH-Zugang dennoch häufig genutzt. Das hat drei Gründe:

  • Die Zeit die man zum Konfigurieren braucht: alle Einstellungen erfordern das Schreiben in den NVRam, das anschließende auslesen dieser Informationen und das durchstartet des betroffenen Dienstes. Da DD-WRT aber nicht „weiß“ welcher Dienst betroffen ist, wird alles durchgestartet. Beispiel: ändert man an der PPPoE Einstellung etwas, werden mal ebend alle Dienste durchgestartet auch der Routing-Dienst (BIRD/ZEBRA). Der Router ist erst mal eine Weile beschäftigt. Wird ein Routing-Dienst eingesetzt und befindet man sich außerhalb der direkten Router-Netze muss man erst mal warten, bis  die Routing-Tabellen wieder stehen. Wenn man weiß was mach macht, kann man auf der Konsole in aller Ruhe an der Config-File rum fuschen. nur den betroffenen Dienst durchstartet und wenn alles wie gewünscht funktioniert, alles in den NVRam speichern.
  • Einige exotische Einstellungen kann man „nur“ über die Konsole machen. Das WebInterface bietet zwar die Möglichkeit 3 Skriptes zu hinterlegen (StartUp, FirewallUp,ShutDown) und direkt Konsolen-Befehle auszuführen, mir fehlt hier aber das Feedback. Ich hab die Skriptes immer erst im Terminal ausprobiert und dann als Skript hinterlegt.
  • Einige Eingabemasken führen quasi eins zu eins auf ein Config-File für einen Dienst. Startet man dann durch und hat einen Syntax-Fehler bekommt man keine Rückmeldung. Auch hier gilt: erst auf der Konsole ausprobieren und dann hinterlegen.

Bei den ganzen Konfigurations-Möglichkeiten sollte noch erwähnt werden, dass alle Interfaces frei konfigurierbar sind. Selbst wenn das WebInterface dann ein wenig zickt. Es werden alle Ethernet und WLan Ports einzeln an das OS gemeldet. Im Falle des AG300H (DualBand) muss man den 2.4Ghz Adapter getrennt vom 5GHz konfigurieren (auch im WebInterface). Einzig die internen LAN-Ports werden durch eine nicht konfigurierbaren Hardware-Switch verschaltet. So muss man ein wenig aufpassen was man am eth0-Port macht.

Was bleibt abschließend zu sagen? Ich bin vom Funktionsumfang der Firmware sehr positiv überrascht. Es wird einem fast alles geboten, was man so braucht. Für alles andere gibt es das SSH-Terminal.  Der WNR3500 war wohl mein letzter nicht WRT Router gewesen sein.