Posted on

Getting ready for Berlin …

(Blogged via flickr)

Ich glaube, mein genetisch modifizierter DockStar ist soweit fertig; ja, gut, sieht bißchen überwuchert aus, aber b. a. w. soll er ja auch das Rückgrat meiner Berliner (Übergangs-) Wohnung werden, dieser »Winzcomputer«.
Am gelben Ethernetkabel hängt Port 1 der FritzBox (Speedport W900V aka •T••-Modell der 7150), welche über den UMTS-Stick am DockStar und den ovpn-Tunnel darüber ‘ne Verbindung zu einer FB mit ISDN zu Hause hält. Gut, die rd. 300 ms Latenz (gemessen in Gütersloh; vielleicht wird’s ja in Berlin sogar besser) sind nicht soo dolle, aber immerhin: ich habe ‘Festnetz’ (1x DECT, 1x ISDN), ganz mobil :)
Ein kurzer Versuch steht noch aus, ob ich darüber auch direkt meine 04755er SIP-Nummer bedienen kann … Fürchte allerding, daß Zocken mit der PS3 über diese Anbindung unspaßig sein wird … Anyway, jetzt wird eingepackt, auf daß ich zum Tatort in der Hauptstadt bin :) (Hmm, und gegen 22 Uhr heißt’s dann wohl, noch was zu Essen zu finden in der Ecke von Mitte …)

Kamera: Vignette Vignette for Android

Posted on

Hausgemachte Probleme …

Eine Passage eines Golem.de-Beitrages möchte ich nicht unkommentiert lassen (Hervorhebung von mir):

Die fehlerhafte Anzeige sorgt dafür, dass sich der iPhone-Besitzer über plötzliche Verbindungsabbrüche wundert, obwohl die Signalqualität laut iPhone-Anzeige eigentlich gut ist. Tatsächlich ist die Signalqualität aber schlecht und es kommt zu den vor allem in den USA berichteten Verbindungsabbrüchen. Aufgrund eines besseren Ausbaus des Mobilfunknetzes in Deutschland fiel das Problem hierzulande weniger deutlich auf als in den USA, wo die meisten iPhone-Kunden gezwungenermaßen im Netz von AT&T telefonieren.

 
Kritisiert worden ist dieses Zwangsbundling an einen Mobilfunkanbieter ja schon mehrfach, auch von mir; aber hier sieht mah IMHO auch sehr schön, warum das einfach keine gute Idee ist. Selbst im »gelobten GSM-Land« (im Vergleich mit den USA) ist nicht jeden Netz überall gleichgut ausgebaut. Zwar hat die Telekom wohl einiges seinerzeit getan, um das erste Apple-Telefon gut versorgen zu können bzw. genauer: den Kunden eine akzeptable Leistung auch und grade ob der technischen Unzulänglichkeiten jenes Gerätes zu bieten. Aber es gibt meiner Erfahrung nach dennoch Gegenden, wo man sich gewöhnlich aufhalten kann und ein anderes Netz bessere Leistung brächte. Dem Nutzer die Freiheit zu nehmen, auf seine Bedürfnisse – und eben nicht die von Apple – abgestimmte Lösungen kombinieren zu dürfen, hat mich beim iBrick seinerzeit abgeschreckt und da Apple diese Philosophie bis heute nicht geändert hat – siehe iPhone 4 –, bleiben Produkte dieser Firma für mich auch weiterhin unkäuflich.

Posted on

Write once … install nowhere

Großartig; ich habe Suns Java 6 installiert, the latest and greatest (und doch schon wieder alt), und was ist? Narf.

Habe ja lange nicht mehr über Java gemeckert, jetzt ist mal wieder Zeit. Dicker #fail jedenfalls, was mir da heute wieder über den Weg lief; ich wollte »SIPFlow Standard version 2.0.0« installieren, um meine Probleme mit dem SIP-Krampf der FritzBoxen mal besser dokumentieren zu können. Ist Java-Krams, aber geschenktem Gaul und so … Aber schon über die Installationsroutine geht’s nicht hinaus, denn »Java 1.5« ist schon jahrelang Geschichte, statt 1.6 kam IIRC gleich 6 und das scheint für den Entwickler von SIPFlow zu viel des Guten(?) zu sein.
Für die eigentlich angezeigten Flüche ist’s mir zu heiß, denkt Euch einfach einen wütend schipfenden Rohrspatz ;)

Posted on

Liebe AVM, …

… 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*.

Posted on

SIP – Geißel der Menscheit?

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?

Posted on

DockStar debianisieren per NFS-Root, ohne Consolenzugriff

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 …