Author: wusel

… ich bin grade etwas unentspannt. Ich habe zwei SpeedPort W900V, umgefritzt auf (GT) Firmware-Version 29.04.70 bzw. (B) 29.04.80. Gut, vielleicht nicht ganz die Verwendung, wie Gott AVM sie vorsah, aber notfalls hätte ich auch zwei »echte« 7170 da, um den Gegenbeweis anzutreten, daß es nicht an der Hardware/Hardware-mit-nicht-vorgesehener-Software liegt …
Die FB GT ist von der Firmware erweitert, auf ihr läuft nämlich u. a. noch Asterisk und OpenVPN. Über OpenVPN hält sie (über T-VDSL, worüber ein Tunnel ins DC läuft) einen Tunnel zu einem Server in einem DataCenter aufrecht. Über diesen Tunnel werden Pakete zur FB B geroutet:

# traceroute 193.26.120.30
traceroute to 193.26.120.30 (193.26.120.30), 30 hops max, 38 byte packets
1 192.168.44.9 (192.168.44.9) 42.956 ms 43.792 ms 46.191 ms
2 dockstar-4.vpn.uu.org (192.251.226.178) 201.827 ms 203.244 ms 199.464 ms
3 dhcp-14.berlin.uu.org (193.26.120.30) 215.253 ms 204.320 ms 201.604 ms

Der Rückweg funktioniert auch:

# traceroute 192.168.44.8
traceroute to 192.168.44.8 (192.168.44.8), 30 hops max, 38 byte packets
1 gw.berlin.uu.org (193.26.120.17) 0.878 ms 0.603 ms 0.562 ms
2 gw-dockstar-4.vpn.uu.org (192.251.226.177) 166.290 ms 158.050 ms 169.237 ms
3 192.168.44.8 (192.168.44.8) 199.720 ms 191.813 ms 199.749 ms

Die Hardware in B ist einfacher, derzeit der umgefrizte SpeedPort, der an einem Linux-Server (Seagate DockStar unter UBIFS-Debian-Lenny) mit USB-3G-Modem (Huawei E160) hängt. Der DockStar macht DHCP sowie hält einen OpenVPN-Tunnel zum besagten Rechner in einem DC:

# netstat -nr
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
192.251.226.254 193.26.120.17 255.255.255.255 UGH 0 0 0 lan
195.71.106.44 193.26.120.17 255.255.255.255 UGH 0 0 0 lan
193.26.120.16 0.0.0.0 255.255.255.240 U 0 0 0 lan
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 lan
0.0.0.0 193.26.120.17 0.0.0.0 UG 0 0 0 lan

Bei der FritzBox in GT ist das etwas komplexer:

# netstat -nr
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
192.168.44.9 0.0.0.0 255.255.255.255 UH 0 0 0 tun1
192.0.2.46 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
192.251.226.30 192.168.5.2 255.255.255.255 UGH 0 0 0 lan
192.251.226.176 192.168.44.9 255.255.255.252 UG 0 0 0 tun1
192.0.2.40 192.0.2.46 255.255.255.248 UG 0 0 0 tun0
193.26.120.16 192.168.44.9 255.255.255.240 UG 0 0 0 tun1
192.168.5.0 0.0.0.0 255.255.255.0 U 0 0 0 lan
192.168.44.0 192.168.44.9 255.255.255.0 UG 0 0 0 tun1
192.168.45.0 192.168.44.9 255.255.255.0 UG 0 0 0 tun1
192.0.2.0 192.0.2.46 255.255.255.0 UG 0 0 0 tun0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 lan
0.0.0.0 192.168.5.253 0.0.0.0 UG 0 0 0 lan

Tja; eigentlich hängt die FB B als SIP-Nebenstelle an der FB GT. Nur leider funktioniert bei der Kommunikation weder bei Rufaufbau von der FB B über die FB GT ins D2-Netz (über T-ISDN an FB GT) noch bei der Anwahl der MSN der FB GT, die für den SIP-Client der FB B reserviert ist, die Tonkommunikation von FB GT zu FB B; alles, was vom DECT-Mobilteil der FB B gesendet wird, kann auf der anderen Seite des Anrufs der FB GT empfangen werden …
Ton kommt also nur, egal, in welche Richtung der Verbindungsaufbau stattfindet, von FB B zur FB GT durch. Man davon abgesehen, daß die IP-Adresse, von der aus die SIP-Pakete verschickt werden, etwas zufällig scheint (die Konfiguration wurde entsprechend angepaßt), fällt im tcpdump auf dem Tunnelterminator in der Mitte folgendes auf:

23:43:33.525597 IP 193.26.120.30.5060 > 192.168.44.8.5060: UDP, length 1098
23:43:33.587540 IP 192.168.44.8.5060 > 193.26.120.30.5060: UDP, length 422
23:43:33.827940 IP 193.26.120.30.5060 > 192.168.44.8.5060: UDP, length 387
23:43:33.998078 IP 193.26.120.30.5060 > 192.168.44.8.5060: UDP, length 1259
23:43:34.136540 IP 192.168.44.8.5060 > 193.26.120.30.5060: UDP, length 325
23:43:34.144963 IP 192.168.44.8.5060 > 193.26.120.30.5060: UDP, length 856
23:43:34.147179 IP 192.168.44.8.7078 > 193.26.120.30.7078: UDP, length 252
23:43:34.151491 IP 192.168.44.8.7078 > 193.26.120.30.7078: UDP, length 252
23:43:34.183467 IP 192.168.44.8.7078 > 193.26.120.30.7078: UDP, length 252
23:43:34.215715 IP 192.168.44.8.7078 > 193.26.120.30.7078: UDP, length 252
23:43:34.240745 IP 192.168.44.8.7078 > 193.26.120.30.7078: UDP, length 252
23:43:34.273582 IP 192.168.44.8.7078 > 193.26.120.30.7078: UDP, length 252
23:43:34.333663 IP 192.168.44.8.7078 > 193.26.120.30.7078: UDP, length 252
23:43:34.384559 IP 192.168.44.8.7078 > 193.26.120.30.7078: UDP, length 252
23:43:34.411361 IP 192.168.44.8.7078 > 193.26.120.30.7078: UDP, length 252
23:43:34.440857 IP 192.168.44.8.7078 > 193.26.120.30.7078: UDP, length 252
23:43:34.473160 IP 192.168.44.8.7078 > 193.26.120.30.7078: UDP, length 252
23:43:34.503695 IP 192.168.44.8.7078 > 193.26.120.30.7078: UDP, length 252
23:43:34.528700 IP 193.26.120.30.5060 > 192.168.44.8.5060: UDP, length 1259
23:43:34.529783 IP 192.168.44.8.7078 > 193.26.120.30.7078: UDP, length 252
23:43:34.561528 IP 192.168.44.8.7078 > 193.26.120.30.7078: UDP, length 252
23:43:34.574796 IP 193.26.120.30 > 192.168.44.8: icmp 288: 193.26.120.30 udp port 7078 unreachable
23:43:34.604628 IP 192.168.44.8.5060 > 193.26.120.30.5060: UDP, length 856

Sprich: FB GT möchte die FB B auf UDP Port 7078 ansprechen, bei FB B lauscht da aber schein’s nixe. Das würde dann auch erklären, warum kein Ton von FB GT zur FB B geht … Was ich aber auch überhaupt nicht ralle: warum sind da keine UDP-Pakete von der 193.26.120.30 (FB B) zur 192.168.44.8 (FB GT)? Einen Routingfehler kann ich eigentlich ausschließen:

dockstar-4:~# ip route show
10.64.64.64 dev ppp0 proto kernel scope link src 10.171.175.224
192.251.226.177 dev azrael proto kernel scope link src 192.251.226.178
192.251.226.30 dev ppp0 scope link
193.26.120.16/28 dev eth0 proto kernel scope link src 193.26.120.17
193.26.120.0/24 via 192.251.226.177 dev azrael
192.251.226.0/24 via 192.251.226.177 dev azrael
192.168.0.0/16 via 192.251.226.177 dev azrael
0.0.0.0/1 via 192.251.226.177 dev azrael
128.0.0.0/1 via 192.251.226.177 dev azrael
default dev ppp0 scope link 

Irgendwie macht das alles keinen Spaß *sigh*.

Hachja. Sagt mal. kann es sein, daß SIP eine echte bescheidene Erfindung ist? In Vorbereitung meiner Übersiedlung nach Berlin baue ich mir derzeit meine Netzanbindung (samt Telefonie, versteht sich) zusammen, und da ich den dortigen Hardwareaufwand minimal halten will, kommt vor Ort ein Speedport W900V, umgefritzt auf eine DECT-7170 (i. e. eine 7150, IIRC), zum Einsatz, welche über OpenVPN-Tunnel mit dem Gegenstück in Gütersloh, welche am heimischen ISDN hängt, kommunizieren soll. Die FritzBox in Berlin hängt als »Telefoniegerät am Anschluss “LAN/WLAN”« an der FritzBox in Gütersloh. Während das Raustelefonieren in beide Richtungen (also Hören und Sprechen) schon klappte, als die FB-GT nicht zur FB-B durchkam, hatte ich eben Spaß dergestalt, daß ich »in Berlin« zwar einen Anruf auf die Gütersloher Nummer annehmen konnte, Sprache vom »Gütersloh« anrufenden Handy allerdings kam nicht nach »Berlin« durch.
Nunja; wie ich dann feststellte, gab es Routingprobleme von »Berlin« nach »Gütersloh«. Warum aber die spigelbildliche Tonverbindung nicht funktionierte: keine Ahnung. Warum überhaupt die Rufannahme klappte: keine Ahnung.
Jedenfalls super zu debuggen:
GT nach B

# traceroute 193.26.120.30
traceroute to 193.26.120.30 (193.26.120.30), 30 hops max, 38 byte packets
1 192.168.44.9 (192.168.44.9) 47.611 ms 47.318 ms 43.141 ms
2 dockstar-4.vpn.uu.org (192.251.226.178) 214.321 ms 199.393 ms *
3 dhcp-14.berlin.uu.org (193.26.120.30) 201.338 ms 203.731 ms 198.400 ms

B nach GT

dockstar-4:~# traceroute fbw900v-2.uu.org
traceroute to fbw900v-2.uu.org (192.168.5.248), 30 hops max, 40 byte packets
1 gw-dockstar-4.vpn.uu.org (192.251.226.177) 319.574 ms 320.259 ms 320.401 ms
2 albert-vdsl2.uu.org (193.26.120.250) 359.448 ms 359.602 ms 359.728 ms
3 * * *
4 * * *

Falls sich jemand über die Zeiten wundert: »dockstar-4« ist mittles USB-UMTS-Stick und o2-SIM (200 MB-Angebot, bei dem u. a. auch VOIP erlaubt ist :-)) online, das Netz per OpenVPN-Tunnel aus dem Rechenzentrum in Gütersloh erreichbar. Nach Hause, ins 192.168.5er Netz geht’s aus dem DC ebenfalls per OpenVPN-Tunnel (partiell sogar per OpenVPN-in-OpenVPN …).
Gut, nachdem nun auch das bidirektionale Routing klappt …

dockstar-4:~# traceroute fbw900v-2.uu.org
traceroute to fbw900v-2.uu.org (192.168.5.248), 30 hops max, 40 byte packets
1 gw-dockstar-4.vpn.uu.org (192.251.226.177) 179.566 ms 189.495 ms 189.391 ms
2 albert-vdsl2.uu.org (193.26.120.250) 238.676 ms 278.454 ms 288.244 ms
3 192.168.5.248 (192.168.5.248) 308.005 ms 447.815 ms 447.787 ms

… sollte ja auch die bidirektionale VoIP-Kommunikation zwischen den FritzBoxen funktionieren. Aber was ist? Egal, was ich als Ton am Handy, welches die Festnetznummer anruft, welche auf das »Telefon«, aka die FritzBox Berlin, geleitet wird, einspeise: nichts kommt auf dem DECT-Mobilteil in »Berlin« an. Ton aus »Berlin« hingegen kommt super (ok, mit rd. 250ms Minimallatenz, also deutlich verzögert) auf dem »Gütersloh« anrufenden Handy an … Any clues?

Von Dirk Tostmann auf die Idee gebracht, versuche ich mich derzeit an einem Prototypen für das Umflashen eines DockStars zu einem »kleinen« SheevaPlug. Ich habe im Folgenden versucht, meine Schritte zu dokumentieren, die Idee dazu stammt, wie gesagt, von Dirk. Die nachfolgenden Schritte habe ich mittlerweile an einem zweiten DockStar ausprobiert — ohne die Console bemühen zu müssen.
Aber dennoch, auch um mich abzusichern: DON’T TRY THIS AT HOME (YET)! IT MOST CERTAINLY WILL BRICK YOUR DOCKSTAR DEVICE! Sollten einzelne Schritte fehlschlagen, z. B. das Booten der NFS-Root nicht funktionieren, ist es notwendig, die serielle Schnittstelle des DockStars zu aktivieren. You have been warned …
Ablauf:

1. Umgebung vorbereiten: uImage von sheeva.with-linux.com holen, auf dem TFTP-Server ablegen (hier als »sheeva-2.6.34-uImage«, ggf. anpassen).
2. NFS-Rootumgebung bereitstellen auf einem vom DockStar erreichbaren NFS-Server. Ich nehme dazu wieder das Debian-Lenny-Archiv; zum uImage passende Modules von sheeva.with-linux.com holen und in der NFS-Root ablegen; ebenfalls das uImage nach $NFSROOT/boot packen.
   Die Datei $NFSROOT/etc/fstab korrigieren (alles auskommentieren), $NFSROOT/etc/mtab zur Sicherheit löschen. In $NFSROOT/etc/network/interfaces die Zeilen mit eth0 auskommentieren; das Netzwerk ist bei NFS-Root schon konfiguriert, wenn die init-Skripte loslaufen (nette Falle BTW ;)). Evtl. auch $NFSROOT/etc/resolv.conf anpassen, wenn man einen lokalen Nameserver hat (Fritz!Box z. B.).
3. UBIFS erzeugen und in NFS-Root ablegen; ich habe hierzu ebenfalls das Lenny-FS genommen (um ehrlich zu sein: die NFS-Root nochmal kopiert) und insbesondere dort etc/network/interfaces angepaßt, sodaß eth0 per DHCP versorgt wird. Auch etc/hostname und etc/hosts habe ich dort angepaßt, schon um Unterschiede zur NFS-Root zu sehen.
   Erzeugung des UBIFS (im Unterverzeichnis ubifs-root-fuer-DockStar); im Ubuntu 10.04-Paket sind alle erforderlichen Binaries drin, wer auf Debian Lenny arbeitet, braucht das mtd-utils-Paket aus Debian Testing):

   cat <<eof >ubi.cfg
   [ubifs]
   mode=ubi
   image=ubifs.img
   vol_id=0
   vol_size=200MiB
   vol_type=dynamic
   vol_name=rootfs
   vol_flags=autoresize
   eof
   mkfs.ubifs -r ubifs-root-fuer-DockStar -m 2048 -e 129024 -c 4096 -o ubifs.img -x zlib
   ubinize -o ubi.img -m 2048 -p 128KiB -s 512 ubi.cfg

   Die Datei ubi.img dann ins / des NFS-Roots kopieren.

4. DockStar normal booten, IP per DHCP geben lassen. Einloggen per SSH (root, stxadmin). Dann:

   cd
   mount -o rw,remount /
   wget http://plugapps.com/os/pogoplug/uboot/blparam
   chmod 755 ./blparam
   export PATH=/sbin:/usr/sbin:/bin:/usr/bin:/root
   blparam orgbootcmd='nand read.e 0x800000 0x100000 0x300000; setenv bootargs $(console) $(bootargs_root); bootm 0x800000'
   blparam netmask=255.255.255.0
   blparam ipaddr=192.168.5.235
   blparam serverip=192.168.5.2
   blparam arcNumber=2097
   blparam mainlineLinux=yes
   blparam bootargs_end=:::DB88FXX81:eth0:none
   blparam tftpboot='tftp 0x800000 sheeva-2.6.34-uImage ; setenv bootargs $(console) root=/dev/nfs rw rootdelay=5 nfsroot=192.168.5.245:/nfs/DockStar_tmp ip=$(ipaddr):$(serverip)$(bootargs_end) ; bootm 0x800000'
   blparam bootcmd='run tftpboot'
   blparam mtdparts='orion_nand:0x100000@0x0(u-boot),0x400000@0x100000(uImage),0x2000000@0x500000(rootfs),0xDB00000@0x2500000(data)'
   blparam tftpboot='tftp 0x800000 sheeva-2.6.34-uImage ; setenv bootargs $(console) root=/dev/nfs rw rootdelay=5 nfsroot=192.168.5.245:/nfs/DockStar_tmp ip=$(ipaddr):$(serverip)$(bootargs_end) $(mtdparts) ; bootm 0x800000'

   Hier die Daten natürlich dem eigenen Umfeld entsprechend anpassen. Achtung, in dieser Konfiguration hat der NFS-Root-gebootete DockStar *kein* Default-Gateway!

5. Dann beherzt einen Reboot des DockStars durchführen.
6. Nach kurzer Zeit sollte er wieder erreichbar sein (ping aus dem gleichen Netz auf, hier, 192.168.5.235, sollte beantwortet werden), dann wieder einloggen (root, root). Der ssh-Client wird wegen falscher Keys meckern, dann entsprechend den alten löschen. (Alternativen wie eine .ssh/options überlasse ich dem geneigten Leser ;)).
   Auf dem nun per NFS-Root laufenden DockStar mal die Flashaufteilung ansehen:

   debian:~# cat /proc/mtd
   dev: size erasesize name
   mtd0: 00100000 00020000 "u-boot"
   mtd1: 00400000 00020000 "uImage"
   mtd2: 0fb00000 00020000 "root"

   Sieht gut aus. Nun wird’s haarig ;)

   route add default gw 192.168.5.2
   wget http://http.us.debian.org/debian/pool/main/m/mtd-utils/mtd-utils_20090606-1_armel.deb
   dpkg -i mtd-utils_20090606-1_armel.deb
   flash_eraseall /dev/mtd2
   ubiformat /dev/mtd2 -s 512 -f /ubi.img -y
   flash_erase /dev/mtdblock1
   flash_eraseall /dev/mtd1
   cat /boot/uImage > /dev/mtdblock1
   wget http://plugapps.com/os/pogoplug/uboot/blparam
   chmod 755 ./blparam
   ./blparam
   ./blparam bootargs_ubi='ubi.mtd=2 root=ubi0:rootfs rootfstype=ubifs'
   ./blparam newbootcmd='nand read.e 0x800000 0x100000 0x300000 ; setenv bootargs $(console) $(mtdparts) $(bootargs_ubi) ; bootm 0x800000'
   ./blparam bootcmd='run newbootcmd'

7. Nach dieser Prozedur sollte der nächste Reboot in ein Debian auf dem DockStar führen, welches als UBIFS im Flash läuft …
8. Login war bei mir aufgrund des gewählten Filesystemarchivs root, root; man sollte dementsprechend auf dem neuen System – ggf. ist nochmal wieder ein Meckern von ssh wegen der ssh-Keys zu umschiffen – noch folgendes tun:
   • Passwort von root ändern (»passwd«-Befehl)
   • Keys für ssh neu machen, z. B. so:

     rm /etc/ssh/ssh_host*
     ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key -N ""
     ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key -N ""

   • /etc/hostname, /etc/hosts anpassen

No animal was harmed during these procedures … No liability assumed, your mileage may vary, standard disclaimers apply …