Weitere Informationen

Hrmpft.
Monday, July 12, 2010, 21:31 - Geeks & Co., Painseeker, Technologien, GSM/GRPS/UMTS/..., VoIP
Trotz Tunnel: die Fritz!Box zu Hause mag nicht mir dieser hier spielen :(
Ich finde ja die Fritz!Boxen mitterweile richtig cool, nur eine Sache nervt: dieser SIP-Registrar ist (zumindest in der alten Version, und – never change an running system – ein Update wollte ich nicht kurz vor knapp noch machen) nervig. Ich verbinde die Netze extra per OpenVPN, damit kein NAT-Gedöns Probleme machen könnte, und was ist der Dank? Genau: keine SIP-Verbindung. Naja, immerhin bei »echten« SIP-Anbietern kommt 'ne Verbindung zustande, direkt wäre aber cooler und billiger ;)

Aber man kann wohl nicht alles haben, und im Grunde funktioniert die AVM-Software ja angenehm unkompliziert und störungsarm — sollte man auch nie unterschätzen …

Liebe AVM, …
Friday, July 2, 2010, 15:02 - Geeks & Co., Technologien, GSM/GRPS/UMTS/..., VoIP, Linux
… 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*.

SIP – Geißel der Menscheit?
Thursday, July 1, 2010, 00:34 - Geeks & Co., Painseeker, Technologien, GSM/GRPS/UMTS/..., VoIP, Linux
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?

Bye, Bye, Sky!
Friday, October 23, 2009, 17:40 - Servicewüste, VoIP
So, das war der zweite Lockanruf von, wie durch Rückruf ohne ausgehende Nummer verifiziert (»Willkommen bey Sky! Schön, daß Sie zurückruf*klack*«), Sky; es wird der letzte gewesen sein, der klingelt: 
exten => $MSN/040809071742,1,Playback(tt-allbusy)
exten => $MSN/040809071742,n,Playback(demo-echotest)     ; Let them know what's going on
exten => $MSN/040809071742,n,Echo	                  ; Do the echo test
exten => $MSN/040809071742,n,Playback(demo-echodone)     ; Let them know it's over
exten => $MSN/040809071742,n,Hangup
Have fun, Automatischer (Massen-?) Anrufer von Sky, gerne eröffne ich Dir die Möglichkeit der Bewußtseinserweiterung per Selbstgespräch … Asterisk to the rescue ;)

Serviceoase
Tuesday, October 13, 2009, 17:21 - Fundstücke, Geeks & Co., Verschiedenes, Hausautomation, Technologien, VoIP
Ts, da habe ich gar keine Rubrik für hier im Blog: ich möchte nämlich ein Unternehmen mal ausdrücklich für seinen Support loben!

Wie schon berichtet, habe ich meinen Ritto-TwinBus der Gegensprechanlage (Haustür <->Wohnung) per Arzberger TFE5 an eine Fritzbox angeschlossen und kann nun auf jedem MFW-fähigen Telefon den Türruf annehmen und ggf. die Tür öffnen — kein lästiges aus-dem-ersten-Stock-sprinten mehr für nichts und wieder nichts (Drücker, Nachbarskinder bevor die eigenen aus der Tagesschule da sind, Leute, die sich in der Klingel geirrt haben, …), genial.

Lieder gibt es bei der Anbindung der TFE5 mit Firmware V1.1 noch ein paar Probleme, insbesondere im Zusammenspiel mit der Fritzbox:
  1. Da die Fritzbox ca. 2 Sekunden auf Nachwahlziffern wartet, es sei denn, man sendet # am Ende der Rufnummern, was der TFE5 bislang nicht kann, verzögert sich auch jede externe Anwahl
  2. Der Ton des Mikrofons an der Haustür ist trotz maximaler Verstärkung in den Gigaset-DECT-Geräten seeeehr leise, leiser jedenfalls als im Ritto-Haustelefon
  3. Eine Anwahl der Haustür ist – entgegen meiner vorigen Erfolgsmeldung – genausowenig möglich wie eine Annahme des Haustürgesprächs am Ritto-Haustelefon
Mit diesen Punkten hatte ich mich an die Info-Adresse der Fa. Arzberger gewandt – und heute Antwort erhalten: Zu 1. und 2. bringt die aktuelle Version V1.3 der TFE5-Firmware Verbesserungen, so können nun auch * und # von der TFE5 gewählt werden, ferner kann das Warten auf eine telefonseitige Gesprächsannahme von 10 auf, IIRC, 13 Ruftöne verlängert werden. Für die Lautstärke wird eine andere Einstellung vorgeschlagen, welche ich ASAP ausprobieren werde. Nur für die Anwahl der Haustür über den TFE5 gibt es derzeit keine Lösung gensausowenig wie für die Unmöglichkeit der parallelen Nutzung des Wohntelefons, wie es der TwinBus eigentlich vorsehen würde. Letzteres scheitert daran, daß der TFE5 wegen der analogen Tk-Schnittstelle aktiv BUSY, RINGING usw. am Ton auf der Leitung erkennen muß, dies kostet Zeit und ist somit nicht transparent machbar (es könnten mehrere Sekunden des Tons von der Türsprechstelle zum Telefon verloren gehen heißt es). Daher belegt der TFE5 mit dem Belegen des a/b-Ports auch den TwinBus, was für andere Sprechstellen am TwinBus bedeutet, daß sie nicht mehr zum Zuge kommen können; faktisch besteht sofort ein Gespräch zwischen Türsprechstelle und Tk-Anlage – daher hört man auch das lustige Tuuuuut, Tuuuuut draußen. Nicht ganz schön und ich habe auch noch keinen Weg gefunden, das über den steuernden Asterisk zu unterbinden, aber aushaltbar.

Ich warte nun auf das V1.3-ROM, mit dem die Sache zumindest in meiner Konstellation noch deutlich besser laufen sollte. Und ich bin froh, daß es noch Hersteller gibt, die auf Kundenanfragen auch reagieren.


Weiter