fonera, openwrt und IPv6

Friday, July 20. 2012

Kann man mit einem Passwort einen WLAN-Router hinrichten? Kommt drauf an, was man als nächstes macht, so die nahe liegende Antwort - aber ich habe doch gar nichts gemacht.... - wie aus dem Support-Bilderbuch.
Das Opfer war mein altgedienter Linksys WRT54GS, mit openwrt White Russian an Bord seit Jahren stabil. Für einen Flachmann, der es nicht anders konnte, lief das Funknetz immer noch mit WEP. Jetzt umgestellt auf WPA, ein richtig schön langes Passwort vergeben - und drei Tage später stirbt das WLAN im laufenden Betrieb, der Linksys lässt sich auch nicht mehr über das Webinterface ansprechen und macht seltsame Spratzeltöne. Alles neu booten und resetten hilft nichts: das Ding ist hin.

In der Tüte kramend taucht ein alter fonera (fonera 2100A, wirklich alt) auf, der sich, eingestöpselt, gleich ein firmware-update zieht. Passwörter und alles sind verschollen, eine Büroklammer auf den winzigen Resetknopf an der Unterseite, langes Halten, Strom aus, an und mit weiter gedrücktem Reset booten lassen: jetzt ist die firmware wieder Version 0.7.0 r4, die Passwörter sind fonera-default admin/admin bzw. root/admin und ich kann mich ans rooten machen.

Zunächst mal auf einem WLAN-Client ein passendes subnet fuer den Zugriff auf's webinterface:  
ifconfig eth1:1 192.168.10.20

Dann ssh aufmachen, hier funzt es mühelos mit BingoBommels step1.html/step2.html - Lösung:
zwei kleine HTML-docs auf dem Rechner anlegen, step1.html: 

<html>
<head>
</head>
<body>
<center>
<form method="post" action="http://192.168.10.1/cgi-bin/webif/adv_wifi.sh" enctype="multipart/form-data">
<input name="wifimode" value="/usr/sbin/iptables -I INPUT 1 -p tcp --dport 22 -j ACCEPT" size="68" >
<input type="submit" name="submit" value="Submit" onClick="{this.form.wifimode.value='&quot;;' + this.form.wifimode.value +';&quot;'}" />
</form>
</body>
</html>
 
und step2.html:
 
<html>
<head>
</head>
<body>
<center>
<form method="post" action="http://192.168.10.1/cgi-bin/webif/adv_wifi.sh" enctype="multipart/form-data">
<input name="wifimode" value="/etc/init.d/dropbear" size="68" >
<input type="submit" name="submit" value="Submit" onClick="{this.form.wifimode.value='&quot;;' + this.form.wifimode.value +';&quot;'}" />
</form>
</body>
</html>
erst das eine, dann das andere doc im Browser oeffnen, je auf den submit-Button klicken und fertig.
Jetzt geht ssh root@192.168.10.1, user root, Passwort admin.

Und um das permanent zu machen, jetzt in der ssh-shell:

mv /etc/init.d/dropbear /etc/init.d/S50dropbear
vi /etc/firewall.user

da gibt es, unter der Überschrift ### Open port to WAN zwei auskommentierte Zeilen, da je die Kommentar-Hashes löschen. ("i" aktiviert den edit-Modus, ESC :wq speichert und beendet vi. Mehr vi-commands googlen)
Schliesslich wollen wir der Kiste noch abgewöhnen, sich irgendwelchen code von "zu hause" herunterzuladen und auszuführen, dazu:
 
vi /bin/thinclient
und dort eine  Zeile auskommentieren, eine Zeile ergänzen, so dass dort steht:
# . /tmp/.thenclient.sh
cp /tmp/.thinclient.sh /tmp/thinclient-$(date '+%Y%m%d-%H%M') 
 
Speichern, und die Kiste ist gerootet. 
Weiter geht's mit telnet, ich habe mich da an diese Anleitung gehalten, Varianten zum Vergleich. Und auf deutsch.
Es wird jetzt ein spezieller Kernel installiert, um Schreibschutz aufzuhaben, und im zweiten Schritt der Redboot Boot Loader der Kiste neu konfiguriert. Diese Schritte müssen ungestört ablaufen, sonst ist die Kiste hin.
 
root@OpenWrt:~# cd /tmp
root@OpenWrt:~# wget http://ipkg.k1k2.de/hack/openwrt-ar531x-2.4-vmlinux-CAMICIA.lzma
root@OpenWrt:~# Connecting to ipkg.k1k2.de[85.10.200.90]:80
openwrt-ar531x-2.4-v 100% |**************************|   512 KB    00:00 ETA
root@OpenWrt:~# mtd -e vmlinux.bin.l7 write openwrt-ar531x-2.4-vmlinux-CAMICIA.lzma vmlinux.bin.l7
Unlocking vmlinux.bin.l7 ...
Erasing vmlinux.bin.l7 ...
Writing from openwrt-ar531x-2.4-vmlinux-CAMICIA.lzma to vmlinux.bin.l7 ... [w]
root@OpenWrt:~# reboot
 
root@OpenWrt:~# cd /tmp
root@OpenWrt:~# wget http://ipkg.k1k2.de/hack/out.hex
root@OpenWrt:~# Connecting to ipkg.k1k2.de[85.10.200.90]:80
out.hex 100% |*******************************| 4096 00:00 ETA
root@OpenWrt:~# mtd -e "RedBoot config" write out.hex "RedBoot config"
Unlocking RedBoot config ...
Erasing RedBoot config ...
Writing from out.hex to RedBoot config ... [w]
root@OpenWrt:~# reboot
 
Die fonera bootet jetzt nicht mehr vollstaendig, sie hört auf die IP 192.168.1.254 und lauscht auf port 9000 auf eine telnet-Verbindung. In der Beschreibung stand, dies tue sie nur für 10 Sekunden, aber bei mir hielt es länger vor.
So, Ethernet-Kabel direkt von der Fonera zum Rechner, dem auch eine route in das subnet legen und dann:
telnet 192.168.1.254 9000
 
Für den nächsten Schritt, ein normales Openwrt auf der Fonera zu installieren, brauchen wir auf dem Rechner einen tftp - Server, der den Kernel und das root.squashfs serviert. Der Rechner war in diesem Fall ein Linux Mint Maya und nach etwas Probieren habe ich den atftpd installiert, wobei ich ihn für seinen kurzen Einsatz direkt aus der cli als daemon gestartet habe. Das ging nicht gleich auf Anhieb, Konfigurationshilfe war nützlich und zusätzlich war dieser Bug zu umschiffen. Es ist ratsam, mit dem atftp - client die korrekte Funktion des Servers zu testen...
Und Openwrt - Kamikaze 8.09 und Backfire 10.03 sollen beide gehen, ich habe es dann nach etwas Schwanken mit backfire 10.03.1 versucht, was letztlich auch geht. (Vielleicht haette ich dann besser gleich trunk genommen, denn mit IPv6 holperte es etwas) Die Versionen stehen nebeneinander unter http://downloads.openwrt.org/ - ich habe  openwrt-atheros-vmlinux.lzma und openwrt-atheros-root.squashfs gezogen und in das Ausliefer-Verzeichnis des atftpd, bei mir /srv/atftpd, gelegt.

So, wenn der tftp-Server läuft, geht es zurueck in die telnet-Shell der fonera und zum RedBoot -Prompt. Da wird jetzt erst mal die Verbindung gesetzt, -h ist die IP des Rechners mit dem tftpd-Server, -l (ein kleines L) die IP der kleinen Kiste. 

RedBoot> ip_address -h <192.168.1.20> -l <192.168.1.254>/24

Also das kernel image laden, memory wipen, kernel flashen. Dauert etwas:

load -r -b %{FREEMEMLO} openwrt-atheros-vmlinux.lzma
fis init
fis create -e 0x80041000 -r 0x80041000 vmlinux.bin.l7

Und anschliessend das root-file system:

load -r -b %{FREEMEMLO} openwrt-atheros-root.squashfs
fis create rootfs

So, das dauert nun nochmal einiges länger, nicht ans Kabel kommen, stattdessen Kaffe kochen oder ein bad nehmen oder so.

 

Irgendwann ist er fertig und man sieht wieder den RedBoot> - Prompt, jetzt kann man sich überzeugen, dass auch wirklich der neue kernel zum booten konfiguriert ist:

fconfig -l -n

Yo, reboot und rein in's Vergnügen:

reset

OpenWrt meldet sich, immer noch unter 192.168.1.254 mit der WebOberfläche, man wird aufgefordert, ein root-Passwort zu setzen und kann sich dann durch die Konfig-Optionen bewegen. Mit Lan und Wifi in einer Bridge vereint ist der Nutzen einer Firewall auf dem Geraet eh fraglich, bei mir schien sie vorrangig damit befasst, alle durchgehenden Pakete wegzufressen. Input, output forward auf accept zu setzen und ausser lan: alle zonen (sprich: die leere wan-zone) zu löschen scheint geholfen zu haben.

IPv6 ging anfangs auch nicht, hier half nach

opkg update
opkg install kmod-ipv6  ip 
/etc/init.d/network restart

noch das Anlegen einer route mit

ip -6 route add 2000::/3 via 2001:db8::dead:c0de metric 256

, die Seiten der OpenWrt-Docu und, als alles zu hängen schien, ein reboot nicht nur der fonera sondern auch des Lan-seitigen Rechners...

Und als Treppenwitz, der auch das anfangs angesprochene Thema, wann Sachen so kaputtgehen, aufnimmt:
als nun mit der fonera und IPv6 alles klappte, jedenfalls im Lan, war plötzlich nach aussen kein IPv6 mehr erreichbar. Der HE-Tunnel hatte sich verabschiedet, was etwa alle 18 Monate vorkommt und nach einer mail an den Support binnen Minuten gefixt wird.
 

(Page 1 of 1, totaling 1 entries)