DD-WRT 19xxx+OpenVPN = Meeeeeeh!

Bis gestern lief DD-WRT auf dem Linksys E2000 noch auf Build 14929. Da diese schon etwas älter war (März 2011 oder so), ging es gestern ans Upgrade auf Version 19519.
Neuere DD-WRT Builds müssen nicht mehr speziell für den E2000 angepasst werden, die neuen -nv60k.bin Versionen funktionieren auch. Allerdings kann nicht einfach auf eine solche Version aktualisiert werden. Hier muss ein Umweg über eine E2000-Mini-Build gegangen werden. Erst dann lässt sich die Firmware auf nv60k flashen. Während frühere Big-Builds (die ich bis jetzt immer installiert hatte) noch gut mit dem E2000 zusammenspielten, sind jetzige Versionen wirklich “Big”, d.h. sie sind zu groß und passen nicht mehr in den Speicher des Routers (8MB) m(
Da für meine Zwecke die OpenVPN Version reicht (Alternativ funktioniert auch “Mega”) und diese klein genug ist, fiel meine Wahl auf diese (dd-wrt.v24-19519_NEWD-2_K2.6_openvpn-nv60k.bin). Nach der Installation musste nur noch die Konfiguration und Start-Scripte wiederhergestellt werden. Zuerst schien auch alles zu funktionieren, bis ich die OpenVPN Verbindung testete. Diese wollte gar nicht erst starten, sondern warf immer wieder Fehler wie “BIO read tls_read_plaintext error: error:1408F119:lib”. Nach kurzer Suche entpuppte sich dies als Bug in der Implementierung der TLS-Verschlüsselung, welcher schon seit einigen Versionen mitgeschleift wurde. Zum Glück gibt es einen Workaround, welcher OpenVPN wieder lauffähig macht. Dazu reichte es, die Verschlüsselungsmethode in der Konfigurationsdatei des Servers mit “tls-cipher DES-CBC3-SHA” festzulegen. Ein Übersicht, welche Algorithmen funktionieren und welche nicht, gibt es hier:
http://svn.dd-wrt.com:8000/ticket/2536#comment:27
Damit konnten auch die Androiden problemlos verbinden.

VDE mit virsh und qemu… -.-

Für meine Projekt- und Bachelorarbeit habe ich mehrere VMs mit virsh und libvirt umgesetzt, was auch problemlos funktioniert hat.
Teil 2 bestand nun darin, das System in eine bestehende Umgebung, welche mit VDE Switchen arbeitet, zu integrieren. Das große Problem bestand allerdings darin, dass zwar qemu mit VDE Switchen arbeiten kann, aber die von mit verwendete VM Verwaltung virsh (noch) nicht (warum auch immer, würde vieles erleichern). Naja, da virsh im Prinzip nichts anderes macht, als die Konfiguration der VM in einem qemu Befehl umzuschreiben, konnte ich diesen mit “ps axw” nach starten der VM auslesen. Diesen konnte ich nun so umbauen, wie ich ihn brauchte. Dabei herausgekommen ist der folgende Befehl:

qemu-system-x86_64 -name VR1 /kvm/virtualwifi/images/VR1.img -net nic,vlan=0,macaddr=52:54:00:ea:db:93 -net vde,vlan=0,sock=/kvm/vde/sw-wlan.ctl -net nic,vlan=1,macaddr=52:54:00:f6:3a:b4 -net tap,vlan=1,ifname=tap-vr1-br1 -net nic,vlan=2,macaddr=52:54:00:f6:3a:b6 -net tap,vlan=2,ifname=tap-vr1-vmbridge -vnc :91 -daemonize -pidfile /kvm/virtualwifi/pid/VR1.pid -k de

Es werden drei Netzwerkkarten angelegt, die erste mit einem VDE Switch verbunden, die beiden anderen jeweils mit einem TAP Interface, welches an einer Bridge hängt (unter virsh wurde dies automagisch erledigt).
Nachteil dieser Lösung: Da die VMs als Daemon laufen, kann man sie nicht so einfach beenden. Die dreckige Methode (die ich im Moment verwende ;-)) ist ein gezieltes abschießen über die PID (Switch “-pidfile”) und kill. Es geht aber eleganter über Telnet und den qemu-monitor (müsste ich bei Zeiten mal einbauen).
Ach ja: lässt man die Parameter “vlan=x” in der Konfiguration der Netzwerkkarten weg, schmiert der Rechner bei >=2 Karten sicher ab ;-)