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