Category: Geeks & Co.

Klar, ich transformiere langsam aber stetig in einen Dinosaurier; und, alles in allem, habe ich die virtuelle Umarmung von Linux, schon ob der noch kruderen kommerziellen Alternativen, nie bereut. Und so werde ich auch damit klarkommen, irgendwie, daß vconfig deprecated ist und man nun das grottenolm-grausam dokumentierte ip[route[2]] nehmen soll. Und ich werde sicherlich auch irgendwann rausfinden, wie ip als vconfig-Ersatz funktionieren mag:
albert:~# man ip | grep -i vlan
albert:~# man ip | grep -i "virtual lan"
albert:~# man ip | grep -i 802.11
albert:~#
(Nötigenfalls werde ich wohl fremdes Skriptwerk assimilieren — as usual: use the Source, Luke ;))

Spannend; lt. Flickr ist belegt das HTC Magic Rang 2 von 40 HTC-Geräten, das Nokia N95 noch immer Rang 1 von 71 aller Kameras von Nokia (Rang 2 das E71, Rang 16 das N78). Und während die (unskalierte …) Nutzerkurve für das HTC Magic (Vodafones erstes Android-Gerät) steil nach oben geht, fällt die für das 2+ Jahre alte N95 ziemlich steil. Allerdings, in Zahlen sieht das ganz anders aus:

Ist im anderen Posting leider untergegangen; das Problem mit dem internen S[sub]0[/sub] der Fritz!Box ist, daß, offensichtlich anders als beim externen, hier ein sehr aggressiver AVM-propietärer Daemon drauf lauscht und auch schon mal gerne sich in die CAPI-Kommunikation einmischt. Was (bislang zumindest) hervorragend geht, ist ein Gespräch per IAX zum Asterisk auf einer Fritz!Box schicken, diese leitet jenen dann auf den internen S[sub]0[/sub] per Dial(CAPI/ISDN-INT/${EXTEN}).
Was nicht geht, ist das Abgreifen von Anrufen, die vom internen S[sub]0[/sub] (oder der internen DECT-Basis z. B. beim Speedport W900V über den internen S[sub]0[/sub]) ausgehen; zwar bekomme ich einen solchen Anruf weitergeleitet, muß aber damit rechnen, daß, während z. B. ein entfernter Asterisk den Ruf noch aufbaut, lokal schon ein Besetztzeichen eingespielt wird. Lustigerweise wechselt das teilweile wieder zum Klingelton, wenn’s »drüben« wirklich klingelt …
Kurzum: das ist faktisch nicht einsetzbar. Da mein Hauptziel aber auch nicht die komplette Ersetzung der AVM-Daemons war, löse ich derlei über eine SIP-Verbindung Fritz!Box zu Asterisk (wobei das derzeit zu einem zentralen Asterisk erfolgt, aber auch lokal funktionieren müßte). Einziges Manko, was mich etwas stört: als »gelernter« ISDN-Nutzer fällt mir natürlich sofort die »Ziffernsammelpause« auf, die die Fritz!Box bei einer Nummer ohne abschließendens »#« in Sekundengröße einlegt. Ich schätze, Analog-Nutzer vermissen da nur das Piep-Pieeep-Piiiep des MFV und stören sich nicht an der Sekunde Stille — ich bin nicht ganz glücklich, aber gut, so ist es nun einmal. (Irgendwann hole ich mir auch noch mal so einen Bakelit-Fernsprecher aus den 50ern; wobei: wo kann ich den noch anschließen, IIRC kann Pulswahl kein aktuelles Gerät mehr?)
Naja, und nachdem sie so dermaßen im Preis gefallen ist, habe ich mir heute Mittwoch eine »Dlink Horst-Box Professional« bestellt. Mal schauen, was mit Schäzchen alles zu machen ist –. immerhin mit »Asterisk on Board« ;)

Ein ganz klein wenig bin ich jetzt doch stolz ;) Naja, whatever: auch wenn es etwas länger gedauert hat als gedacht, meine Kopplung mehrerer Fritz!Boxen zu einer Art verteilten Telefonanlage funktioniert nun endlich.
Wenngleich man schon viele lustige Sachen mit einer Fritz!Box alleine machen kann, eines nervt doch: selbst wenn man über Rufumleitung > Parallelruf einen Parallelruf via SIP startet, kommt die A-Rufnummer leider nicht mit. Derlei hätte ich aber gerne, denn ich möchte etwas wie eine »abgesetzte Nebenstelle« realisieren: bin ich grade nicht im Office, sollen die Anrufe – so transparent und so kostengünstig wie möglich – an einem anderen Ort – nennen wir’s mal Homeoffice – signalisiert und beantwortbar gemacht werden.
Und nachdem schon jahrelang vorgearbeitet wurde, habe ich es nun aufgegeben, mit AVM-Bordmitteln mein Ziel zu erreichen zu versuchen und kurzerhand auch auf die relevanten Fritz!Boxen Asterisk ausgerollt — mit bislang sehr angenehmen Ergebnis.
Vielleicht ein Wort vorab zu Infrastruktur: ich selber setze seit knapp 20 Jahren auf ISDN, weil es einfach damals die überlegene Technologie war und in vielerlei Hinsicht meines Erachtens auch heute, im Zeitalter von NGN-Telefonie, noch aus Anschlußsicht ist. Somit habe ich natürlich zu Hause ISDN, AFAIK noch »echtes« ISDN und keine NGN-ISDN-Emulation … Der S[sub]0[/sub] zieht sich – selbstverlegt – durch alle drei Etagen der Wohnung, der NTBA ist im Keller. Daneben gab es mal einen zweiten, von Asterisk & HFC-Karten gespeisten, S[sub]0[/sub], der liegt aber seit ein paar Jahren aufgrund von mangelder Stabilität still. Am S[sub]0[/sub] hängen ein SX353isdn – eine Gigaset-ISDN-DECT-Anlage – sowie ein A/B-Wandler für den Anschluß des obligatorischen Faxgerätes (HP OfficeJet 5600Series). Sowie, neuerdings, ein Speedport W701V (auf AVM-Oberfläche umgeflasht, also eine 7170 ohne internen S[sub]0[/sub]) als Remote-CAPI-Lösung – die im Asterisk-Server eingebaute HFC-Karte lief mit bristuff wieder nicht stabil :( –, außerdem noch ein umgefritzter Speedport W900V als »Mittler« zwischen ISDN und SX353isdn (Wunschvorstellung wäre gewesen, daß jener W900V CAPI-Endpunkt für T-ISDN einerseits und CAPI-Endpunkt für den internen S[sub]0[/sub], also die ISDN-Geräte im Haus, andererseits wird; dazu später mehr).
Das »Office« ist über Alice-DSL (AliceComfort, weil ich ja ISDN als Telefonie-Schnittstelle sowie zwei »Amtsleitungen« haben möchte) erschlossen, den Netzabschluß bildet ein Alice-IAD, an wessen S[sub]0[/sub]-Ausgang sich der netzseitige S[sub]0[/sub]-Eingang einer Fritz!Box 7170 anschmiegt. Telefonie ermöglicht ein Sinus 43 aus der Bucht, an welches per DECT sich weitere Mobilteile hängen können. Die analogen Ports der Fritz!Box sind nicht in Benutzung; evtl. kommt hier später noch ein Fax hinzu, was für die Betrachtung der Telefonie aber nicht relevant ist.
Für meine Anwendung das Kernproblem der Fritz!Boxen ist, daß sie auf SIP aufbauen, einem im NAT-Umfeld nicht trivialen Protokoll, ferner gerne mal mit ihrer öffentlichen IP rausgehen (was natürlich als Router hinter einem Router eher keine wirklich öffentliche IP liefert), selbst bei Routing über einen Tunnel :( Und wahrscheinlich gab es hinsichtlich der technischen Optionen Vorgaben der Netzbetreiber, was sie als Feature eher doof fänden, daraus resultieren meines Erachtens vermutlich einige Einschränkungen.
Nun denn, die Lösung, wie so oft, lautet hier Asterisk, denn dankenswerterweise kann man auch auf den linuxbasierten Fritz!Boxen auf die CAPI zugreifen und da AVM es genauso macht, gibt es bei viellen Anwendungen gar keine Probleme. Remote-CAPI allerdings ist auf Serverseite problematisch, da ein Server nur eine Remote-CAPI über das fbrcapi.ko-Modul ansprechen kann; somit war der nächste logische Schritt, es mit Asterisk auf der Fritz!Box zu versuchen. Wie schon geschrieben, mit der aktuellen Firmware-Version ….70 sind die Pakete von »dynamic« unter c2a2b2.com zielführend. Da man eine solche Fritz!Box wohl zuvor schon mit den Pseudo-Images von The-Construct.com um u. a. dropbear (und, in meinem Fall, OpenVPN zur Fernadministration und besser kontrollierbarem VoIP-Routing) erweitert hat, ich die Fernadministration bzw. -konfiguration der Logfiles dank sshfs auch kein Thema mehr.
Die gewählte, ersteinmal funktionale, Lösung ist … etwas komplex. Die Zielsetzung war:

• Anrufe auf der Office-Nummer sollen auf einer MSN im Homeoffice inkl. orginaler A-Rufnummer signalisiert werden und angenommen werden können.
• Anrufe auf einer bislang im Homeoffice genutzten MSN sollten parallel, möglichst, aber nicht zwingend, wieder mit korrekter A-Rufnummer, im Office signalisiert werden und angenommen werden können.
• Möglichst auch aus dem Homeoffice sollte eine Rauswahl mit der Office-Nummer, z. B. für Rückfragen, Beantwortung von Nachrichten auf dem Office-Anrufbeantworter, möglich sein.

Für die simple Weiterleitung eines Anrufes Office->Homeoffice ud umgekehrt bietet die Fritz!Box-Oberfläche schon den sog. Parallelruf an; das funktioniert über’s Festnetz wie über SIP – leider aber eben auch im letzten Fall mit Rufnummer des absetztenden Anschlusses und nicht der des Anrufers von außen. Außerden müßte man hier unterschiedliche MSNs verwenden, da sonst ein Anruf von außen auf der Office-MSN dort als auch an der Homeoffice-MSN signalisiert würde. Durch den eingegenden Anruf auf der Homeoffice-MSN wird aber die Weiterleitung an die Office-MSN getriggert, wie wiederum … Ja, das’ doof. Auch doof, daß ein Anruf von Familienmitgliedern von zu Hause auf der Office-MSN zum klingeln der Homeoffice-MSN führt. Da wird man dann irgendwann wahnsinnig ;)
Rauswahl über den neuerdings vorhandenen SIP-Registrar in der 7170-Firmware bzw. schon die Kopplung zweier Fritz!Boxen über OpenVPN-Verbindungen tat bei mir irgendwie nicht; tcpdump zeigte, daß die Antworten der fernen Fritz!Box auch über den OpenVPN-Tunnel mit deren offizieller IP ankamen. Ich hab’ das dann irgendwann einfach sein gelassen, auch die Kopplung des zentralen Asterisk an eine solche Fritz!Box scheiterte (»chan_sip.c:12537 handle_response_register: Got 404 Not found on SIP register to service 620@192.0.2.17, giving up«) — ich habe dann die Keule rausgeholt und Asterisk installiert.
Dreh- und Angelpunkt ist mein zentraler Asterisk-Server, der für die Fritz!Boxen gleichzeitig OpenVPN-Server ist; hier finden im Groben die Routingentscheidungen statt, die Fritz!Boxen sind im Grunde nur CAPI-IAX-Gateway. Anrufe von außen auf den Fritz!Boxen kommen auf dem Asterisk per CAPI an und werden, je nach lokaler Konfiguration, per IAX2 an den zentralen Asterisk (ast-1) weiterverbunden (insbes. im Falle der Office-Fritz!Box):
[from-amt]
exten => 5000000,1,Dial(IAX2/ast-1/2000000,30) ; peercontext=from-office in iax.conf
exten => 5000000,n,Hangup
Für den Parallelruf sondere ich lokale MSNs aus (Anrufe, die per IAX reinkommen und vom lokalen S[sub]0[/sub] stammen, werden sofort mit Hangup() beantwortet) und übergebe ansonsten über Dial(IAX2/FBW900V-1-out/${EXTEN}) an den Asterisk der heimischen W900V:
[from-office]
exten => 2000000/05241200000,1,Hangup
exten => 2000000,1,NoOp,${CALLERID(all)}
exten => 2000000,n,NoOp,${CALLERID(rdnis)}
exten => 2000000,n,Dial(IAX2/FBW900V-1-out/2000000,,rt) ; peercontext=from-ast-1
exten => 2000000,n,Hangup
Diese wiederum hat einen recht simplen Kontext an dieser Stelle:
[from-ast-1]
exten => _0X.,1,Dial(CAPI/ISDN-AMT/${EXTEN},55,Tt/bd)
exten => _0X.,n,Hangup
exten => _Z.,1,Dial(CAPI/ISDN-INT/${EXTEN},55,Tt/bd)
exten => _Z.,n,Hangup
ISDN-AMT ist hier der externe, ISDN-INT der interne S[sub]0[/sub]; die Weiterleitung per IAX2 funktioniert unter Beibehaltung der orginalen CallerID, die dann auch auf den ISDN-/DECT-Endgeräten (nahezu) korrekt angezeigt wird (»Anruf von 0800000000 auf 2000000«; richtiger wäre natürlich die Office-MSN).
Der Weg Homeoffice-MSN -> Office läuft analog, nur daß ich hier a) derzeit keinen A-Rufnummern filtere und b) der Signalisierung und der Rufabgriff auf ast-1 über Remote-CAPI schon erfolgt, nicht über IAX und die W900V:
[from-capi-amt]
exten => 2000000,1,Dial(IAX2/FB-OFFICE-out/5000000,25)
exten => 2000000,n,Hangup
Da der Kontext [from-ast-1] auf der Office-FB nahezu identisch zum schon gezeigten ist (nur für die Rauswahl wird eine andere als MSN gesetzt, daß die Office-MSN nicht die erste MSN des Anschlusses ist, welche bei einer ungültigen/leeren Abgangsrufnummer vom ISDN-Netz zwangsweise gesetzt würde), schenke ich mir Auflistung und Erklärung ;)
Trickreich ist dann der Wunsch Nummer 3: mit der Office-MSN raustelefonieren können. Dies liesse sich einmal per SIP realisieren (neben anderen bietet z. B. auch sipgate.de an, eine spezielle Nummer für CLIP zu setzen – wenngleich die eigentliche, dem SIP-Zugang zugeordnete, Rufnummer auch mit übertragen wird), aber wenn ich doch nun schon verbundene Asteriske habe, geht das auch so: die W900V, an deren internem S[sub]0[/sub] die heimischen Telefone hängen, bekommt einen SIP-Account auf ast-1 und verbindet sich mit diesem. Als Internetrufnummer habe ich in der Fritz!Box-Oberfläche hier »90« eingetragen. Generische Wahlregeln gibt es keine und da die Fritz!Box relativ intelligent entscheidet, ob es über Festnetz oder IP rausgeht, muß man nur die abgehende Rufnummer nach Wunsch konfigurieren:

Ob ein Gespräch über Festnetz oder Internet geführt wird, entscheidet FRITZ!Box Fon anhand der gehenden Rufnummer. Die Regel dabei ist einfach: Ist die Abgangs-MSN eine Internet- oder eine VoIP-fähige Festnetznummer, wird das Gespräch über das Internet aufgebaut. Alle anderen Rufe werden über das Festnetz geführt. Für Geräte ohne Abgangsrufnummer kann in der Box eine Hauptrufnummer (Festnetz oder Internet) hinterlegt werden.

 
Die Gigaset-DECT-Basis im SX353isdn ermöglicht es, vor jeder Wahl die abgehende MSN auszuwählen; hier habe ich einfach eine weitere, nämlich die »90« mit dem Namen »Office«, konfiguriert und kann nun entweder ein Mobilteil permanent auf Abgangs-MSN 90 stellen (und damit die Wahl über SIP zu ast-1 in den Kontext from-office forcieren (in SIP-Kontext wird die CallerID auf “90” gesetzt), wo es per exten => _X./90,1,Dial(IAX2/FB-OFFICE-out/${EXTEN},55,rt) weitergeht) oder fallweise über das heimische ISDN (mit heimischen MSNs) oder den Office-ISDN-Anschluß (mit der Office-MSN ausgehend) telefonieren.
(Kostenmäßig ist der Aufwand übrigens zweckfrei; beide ISDN-Anschlüsse sein Teil jeweils eines DSL-Komplettpaketes inkl. Festnetz-Flatrate. Einzig für Rückrufe auf Mobilfunknummern wäre es ein Kostenthema; wichtiger ist aber die korrekte rausgehende Rufnummer, um nicht wieder externe Rückrufe auf die Homeoffice-Nummer, an der kein Anrufbeantworter (mehr) hängt, zu erzeugen.)
Nun wird sich zeigen müssen, wie stabil das Setup ist und wie sich das qualitativ macht …

JFTR: Ich bun nun einen entscheidenden Schritt weiter. Nachdem ich mit doch einiger Mühe Asterisk auf meiner (Pseudo-) Fritz!Box 7170 (eines »umgefritzten« Speedport W900V, welcher als einer der wenigen Speedports einen internen S0 hat, andererseits recht günstig, z. T. günstiger als die 7170, in der Bucht zu erstehen ist; der W900V entspricht am ehesten wohl einer Kreuzung aus AVMs 7150 (die erste DECT-Fritzbox) und 7170 (in- wie externer S0, 2x (7170: 3x) analog intern, 4-Port-Switch) an den Start bringen konnte — letztlich durch einen IPPF-Post; die Hinweise bei Backenhörnchen und Magenbrot tun’s nicht für die Firmware-Version 29.04.70.
Und an dieser Stelle der dezente Hinweis, daß, wie woanders auch jüngst festgestellt, bei Änderungen an der capi.conf zumindest mit der eingesetzten Version ein simpler “reload” in der Asterisk-Konsole auf der Fritz!Box nicht ausreicht: den lieben Asterisk einmal stoppen und wieder neu starten hilft da Wunder ;)
Schön ist, daß es nun möglich ist – zumindest funktionierte es in den ersten Tests, trotz gegenteiliger Andeutungen im Configfile –, von einem zentralen Asterisk aus (auf x86-Hardware) Anrufe (via IAX2-Protokoll) inkl. der initialen rufenden Nummer auch auf der Fritz!Box auf dem internen ISDN-Bus (und, im Falle der W900V, sogar an der integrierten DECT-Basis) korrekt zu signalisieren.
Das ist für mich relativ wichtig, da ich Parallelrufe benötige für zwei Nummern an zwei räumlich getrennten externen S0-Bussen. (MSN 1 soll lokal und auf MSN 2 am anderen Standort klingeln; MSN 2 lokal und auf MSN 1 des anderen Standortes; am Standort von MSN 2 nutze ich derzeit den Fritz!Box-Paralleruf (auf lokale MSN & per SIP zum Standort 1), der aber leider die initiale Nummer frißt. Außerdem bedeutet ein Anruf von Standort 1 auf MSN 2, daß dieser Anruf via SIP wieder zu Standort 1 signalisiert wird und mithin andere Endgeräte an Standort 1 klingeln.)
Jetzt muß ich also nur noch dafür sorgen – Asterisk kann derlei ja –, daß bei Anrufen aus Standort 1 an MSN 2 (die ja an Standort 2 lokalisiert wird) die Weiterleitung von MSN 2 zu Standort 1 unterbleibt, das sollte jetzt nicht so schwer sein.

Das schnell zu den Akten … ich schrieb im Vodafone-Blog zum twittermon-Artikel:

#143 Kai ‘wusel’ Siering Says:
Juli 21st, 2009 at 1:40 am
@Carmen Hillebrand (#52):
»Offenheit bedeutet aber eben auch, daß wir durchaus konträre Positionen stehenlassen sowie Inhalte, die wir nicht teilen. Dies wird gerne von unseren Kritikern, Euch, als “fail” bezeichnet, wir bauen darauf, daß wir nur durch diese Offenheit einen Dialog haben können, auch wenn wir lieber positive Kommentare lesen würden.«
Jetzt mal ehrlich, bis auf den letzten Absatz, Stil hin oder her, mag das ja noch ein netter Blogpost sein; aber was bitte erwartet Ihr ernsthaft auf ein »Seit drei Monaten habe ich ein neues Handy, das HTC Magic mit Internetanschluss. Tolles Ding, mit wenig Knöpfen dran, das ist äußerst praktisch. Mein altes Handy hatte viel zu viele Knöpfe. […] So geht mir nichts mehr verloren und meine Handyrechnung beschert mir seitdem auch keine böse Überraschung mehr.« als Abschluß eines solchen Posts?
Das HTC Magic ist unterhalb monatlich 59,95€ nicht einsetzbar (SuperFlat Internet; SuperFlat Internet Wochenende würde mir ja reichen bei denn paar Anrufen, beinhaltet aber nur 200 MB/Monat zzgl. »0,49 Euro proMB« ab MB 201 => worst case also Privatinsolvenz, wenn so ein Always-On-Gerät mal datenhungrig wird; die Option Vodafone live! InternetFlat, die da einen o2-ähnlichen Fallschirm aufspannen würde ist, lt. Aussage des Shopangestellten, mit den SuperFlat-Tarifen nicht buchbar!) und beinhaltet dann »VideoTelefonie1« (kann das HTC Magic nicht; peinlich eigentlich), »Basiskanäle von MobileTV15« (mit dem HTC Magic nicht nutzbar) sowie »3.000 SMS und 1.500 MMS aus dem deutschen Vodafone-Netz ins deutsche Vodafone-Netz« (abgesehen davon, daß ich vorher nicht weiß, in welchem Netz die Zielnummer ist, ein tolles Angebot, 4,17 SMS und 2,01 MMS darf ich also je Stunde schicken …) — reife (zwangsweise bezahlte aber nicht wirklich nutzbare) Leistung! Vielleicht hat Frau Hamelmann ja wirklich ein unbegrenztes Telekommunikationsbudget, mich schmerzt das »Eintrittsgeld« in die mobile Kommunikation bei D2 schon, irgendwie …
Und, nur am Rande: Schon mit dem N95, und das ist mittlerweile aaaalt (hat aber noch immer eine deutlich bessere Kamera als das Magic :() und der besagten Vodafone live! InternetFlat war seit langem das Hochladen von Bildern möglich; ich hab’s mit locr gemacht, flickr & Co. gehen sicherlich auch.
Neu am Magic ist eigentlich nur die Anzahl der gleichzeig möglichen, den Akku leersaugenden, Programme (und der Komfort, wie man diese auf sein Handy bekommt), dumm ist aber die Laufzeit von, na, mit Chance 8 Stunden »always on«.
Also, mit Verlaub, ein solcher Text gehört nicht in eine Blogumgebung, damit schafft man jedenfalls keine »Offenheit« und bekommt auch nur schwerliche »positive Kommentare«, da die Story hanebüchen, ja, sorry, bullshit ist. Jedenfalls für jemanden, der nicht erst mit dieser tollen Kampange angefangen hat, das Internet mobil *zu nutzen* …

 
Die Kommentare sind mittlerweile geschlossen; eine Replik der Vodafone gab es nicht – Dialog 0.0. Gut, sicher, man mag dagegen halten, daß Vodafone/deren Marketeers nach dem 211. Kommentar zum Beitrag von Ex-Schnutinger Ute Hamelmann die ausufernde Diskussion offensichtlich morgens am 22.07.09 beendet haben, auch hier die Reißleine gezogen. Macht es das besser?
Ich finde nicht; eine Kampange im Web 2.0, die eine sogenannte »Generation Upload« adressiert, kann nicht einfach den Dialog beenden, den die Wahl des Mediums Blog impliziert. Klar, technisch kann man das. Bedeutet aber, daß der ganze – in der Pressekonferenz auch arg bemüht kommunizierte – Web-Zwo-Null-Zinnober nichts als der Versuch ist, dummdreißte Werbesprüche in einem Web-Zwo-Null-Gewand an den »Uploader« zu bringen. Im Westen also doch nchts Neues. Gut, wie kein kleines Kind auch jegliche Aufmerksamkeit – und sei es der Zorn des Elters ob der Quengelei – als Erfolg verbucht, so gilt für Werbetreibende auch eher das Motto: »Aufmerksamkeit um jeden Preis«.
[ ] Vodafone hat verstanden.
Denn Wochen nach der Pressekonferenz gibt es nach wie vor eben keine »Uploader« anziehenden Tarife. Es gibt im Vodafone-Blog täglich einen Beitrag, der sich weder mit bisherigen Geschehnissen rund um die #Vodafail-Kampagne zu auseinandersetzt noch irgendwie den Anschein erweckt, etwas anderes zu sein als die Abarbeitung der im Fünf-Wochen-Plan vorgesehenen Posts. Schade.
In Anlehnung an einen anderen Spruch – »nicht alles, was hinkt, ist ein Vergleich« – bleibt also festzustellen, daß die Wahl einer Blogsoftware (ich tippe mal auf WordPress, auch wg. <link rel="stylesheet" href="http://blog.vodafone.de/wp-content/themes/vfblog/style.css" type="text/css" media="screen" />) nicht automatisch eine Website zu einem (We-)Blog(-buch) macht. Auch hilft es wenig, »Blog« drüber zu schreiben, wenn man »Kundeninformation« meint.

*sigh* Das hat jetzt doch etwas gedauert.
Lessons learned 1: Nicht noch schnell vor’m Schlafengehen eine zweite Kiste aufsetzen mit munterem copy-and-paste der Konfiguration.
Nicht alles, was außerhalb des LANs sinnvoll ist, funktioniert genausogut innerhalb des LANs; also zum Beispiel jetzt das lokale Netz über den OpenVPN-Tunnel zu jagen ist i. d. R. kontraproduktiv und führt zu sehr selektiver Dysfunktion … Nicht wirklich hilfreich ist es ferner, diese Tunnel mit identischen (war ja nur’n schneller Test) Credentials aufzubauen und munter IP- und Socket-Adressen mit bestehenden Tunneln zu verzwurbeln. Da wird dann der Tunnel einseitig established, dank des identischen Schlüssels kommen auch Pakete an; leider auf dem falschen Tunnelendpunkt, die Kommunikation war arg einseitig.
Lessons learned 2: NAT ist böse. Also nicht so böse, wie IPv6-Protaginisten z. B. bei Heise schreiben, aber schon böse, wenn ip_conntrack lustig auf die alte T-Online-IP nattet, obwohl das schon die von (Vor-)Vorgestern ist.
tcpdump auf Fritz!Boxen hat schon was; da sieht man dann endlich, daß die Pakete, die auf dem Tunnelgegenüber rausgehen, nicht ankommen. Und wenn man dann – mit etwas Ruhe – dann darauf kommt, daß man irgendwo in der Tunnelaufbauphase wohl gucken muß, warum die Pakete, die lt. tcpdump auf dem Tunnelendpunkt von der Fritz!Box ankommen und mit korrekten Antwort-IP auch wieder in diesem Tunnel zur Fritz!Box verschwinden, letztlich nicht im Tunnel auf der FB ankommen.
Skizze? Skizze:

 LAN ppp0 RZ-LAN
[Fritz!Box_________[Router]________[Internet]________[OpenVPN-Server]
\_________________________________________________/
OpenVPN-Tunnel 192.168.5.248 zu 195....
(ovpn: ifconfig 192.168.44.8 192.168.44.9)

Eigentlich simpel das Ganze. Die Fritz!Box baut einen OpenVPN-Tunnel auf, sie hat im LAN eine RFC1918-Adresse. Der Router (angejahrtes full-blown-Linux-System, Kernel 2.4) macht für die RFC1918-Adressen ein SNAT auf die aktuelle ppp0-IP (via /etc/ppp/ip-*.local) und schickt das Paket auf Reisen über ppp0. Auf dem OpenVPN-Server hat – für dieses Szenario – jede Verbindung ihren eigenen OpenVPN-Daemon und mithin ein dediziertes Socket, sprich IP & Port. Kommuniziert wird normalerweise über UDP, fallweise auch mal über TCP. Rennt hammergeil – eigentlich. Nur die Fritz!Box, die ich zwischen T-ISDN und meinen heimischen S0-Bus gehängt habe und die nun auch lustige VoIP-Geschichet, teils zu anderen FBs, teils über einen zentralen Asterisk, macht plötzlich Probleme.
Gut, nach längeren Suchen stieß ich drauf, daß zwei Routen zum gleichen Ziel, eines directly connected, eines über den Tunnel (der über das directly connected LAN liefe) eher kontraproduktiv sind (Lesson 1).
Jetzt aber, ums verrecken tut der eine Tunnel nicht, der zum obigen Setup. (Die FB unterhält noch einen zweiten Tunnel zum zentralen Asterisk, primär um SIP durch die NAT-Welt da draußen zu bekommen, sekundär aber auch zwecks Erhöhung der Privatheit der Kommunkation. Anyway, der Tunnel rannte schon immer.)
Nach langem Gedumpe kam ich dann drauf zu verifizieren, ob denn der Tunnelaufbau überhaupt klappt oder ich vielleicht an völlig falscher Stelle debugge. Und irgendwann fiel’s mir wie Schuppen aus den Haaren: die Pakete gehen korrekt raus. Äh, halt, da stimmt doch die IP der anderen Tunnelseite nicht‽

08:42:18.273448 IP 195....10000 > 93.217.189.219.10000: UDP, length 60

Tja, leider; mittlerweile hatte es mind. 1 Zwangstrennung gegeben, aber davon wollte ip_conntrack nichts wissen:

root@router:~ # grep 189.219 /proc/net/ip_conntrack
tcp 6 137482 CLOSE_WAIT src=192.168.5.108 dst=XX.XXX.XX.XXX sport=36553 dport=443 src=XX.XXX.XX.XXX dst=93.217.189.219 sport=443 dport=36553 [ASSURED] use=1
tcp 6 101822 CLOSE_WAIT src=192.168.5.108 dst=XXX.XX.XXX.XXX sport=36398 dport=5228 src=XXX.XX.XXX.XXX dst=93.217.189.219 sport=5228 dport=36398 [ASSURED] use=1
tcp 6 94463 CLOSE_WAIT src=192.168.5.108 dst=XX.XXX.XX.XXX sport=60622 dport=443 src=XX.XXX.XX.XXX dst=93.217.189.219 sport=443 dport=60622 [ASSURED] use=1
tcp 6 137480 CLOSE_WAIT src=192.168.5.108 dst=XX.XXX.XX.XXX sport=52715 dport=80 src=XX.XXX.XX.XXX dst=93.217.189.219 sport=80 dport=52715 [ASSURED] use=1
tcp 6 322804 ESTABLISHED src=192.168.5.108 dst=XXX.XX.XXX.XXX sport=53735 dport=5228 src=XXX.XX.XXX.XXX dst=93.217.189.219 sport=5228 dport=53735 [ASSURED] use=1
udp 17 172 src=192.168.5.247 dst=195... sport=10000 dport=10000 src=195... dst=93.217.189.219 sport=10000 dport=10000 [ASSURED] use=1
[...]

Unter anderem die OpenVPN-Links standen noch munter mit der alten externen IP dort; wieso einige TCP-Verbindungen angeblich noch ESTABLISHED sein sollen, wo doch die externe IP nun ganz woanders endet – ich weiß es nicht. Tendentiell wäre das mit TCP schon aufgeflogen, da der Tunnel sich nicht hätte aufbauen können (Three-Way-Handshake); da ich aber UDP nutze, bekommt der OpenVPN-Server ein gültiges Paket von der falschen (falsch genatteten) Adresse, das reicht für den Tunnelaufbau. Pakete von der Fritz!Box kamen auch an, nur die Antwortpakete gingen an die falsche Zieladresse — was OpenVPN auch berichtete:

Jul 23 07:58:50 azrael openvpn[4711]: read UDPv4 [EHOSTUNREACH]: No route to host (code=113)

Lessons learned 3: Auch mal ‘nen Layer hochschauen. Wenn der Tunnel einseitig tut, nicht im Tunnel den Fehler suchen oder im Routing oder vermuteten Filtern, sondern auch mal ins syslog gucken …
Eigentlich war jede Info da; es hätte schneller gehen müssen, aber so ist das, wenn schon verkorkst, dann richtig :( Der Trigger für mich war die syslog-Meldung (nach Neustart des Tunnels auf der Britz!Box):

Jul 23 07:58:50 azrael openvpn[4711]: Peer Connection Initiated with 93.217.189.219:10000
Jul 23 07:58:50 azrael openvpn[4711]: Initialization Sequence Completed
Jul 23 07:58:50 azrael openvpn[4711]: read UDPv4 [EHOSTUNREACH]: No route to host (code=113)

Also Verbindung hergestellt und sofort wieder EHOSTUNREACH, wie kann das sein, zumal Pakete reinkommen?
Die Überprüfung der iptables-Einstellungen ergab … nichts; da war die korrekte IP als SNAT-Ziel eingestellt. Also ab, herausfinden, wie das NATing eigentlich funktioniert und auf /proc/net/ip_conntrack gestoßen. Nach längerem Googlen stellte sich einerseits heraus, daß sowas wohl gelegentlich vorkommt beim 2.4er Kernel, bei 2.6 wird derlei wohl wieder anders gehandhabt. Und die oft propagierte Lösung lautet: Modul entladen — was bei einem Router mit n Interfaces nur wegen der technisch unnötigen T-Online-24h-Zwangstrennung eher no go ist.
Zum Glück fand’ sich ein Lösungsansatz aus 2005 (für jemanden, der das Problem mit seinem OpenWRT-Router offensichtlich auch hat); ich habe ihn ausprobiert …

UDPTO=`cat /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout`; UDPTOSTREAM=`cat /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout_stream` ; echo 0 > /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout_stream && echo 0 > /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout && sleep 10 && echo ${UDPTOSTREAM} > /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout_stream && echo ${UDPTO} > /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout

 
… und, juhee, die alten UDP-Einträge sind futsch und wie von Zauberhand rennt der Tunnel:

traceroute to 192.168.45.1 (192.168.45.1), 30 hops max, 38 byte packets
1 192.168.44.9 (192.168.44.9) 44.464 ms 45.643 ms 45.539 ms
2 192.168.45.1 (192.168.45.1) 97.082 ms 95.747 ms 96.096 ms

Tja, reif für die Insel würde ich sagen :( Warum noch immer da TCP-Sessions als ESTABISHED stehen, wo ich das fragliche Endgerät im LAN doch schon vor ‘ner halben Stunde abgeschaltet habe — ich weiß es nicht und derzeit ist es mir auch eher egal; ein 2.6-basierter neuer Router ist schon am Betatest, insofern wird’s obige Zeile in der ip-up.local wohl für die nächste Zeit tun. NAT an sich finde ich gar nicht schlimm oder schlecht; nur, wenn sowas dazu kommt, dann wird’s haarig ;)

… alle DSL-Anbieter rein, Sack zu — und dann immer feste drauf: es trifft immer den Richtigen :(
Die klauen mir echt Lebenszeit. Aber von vorne … Vor einer Woche schrieb ich:

Um den Tag abzurunden teilte mir die Telekom heute per »Auftragsbestätigung zu Ihrem Auftrag vom 13.07.09« mit, daß sie auf meinen angeblichen Wunsch hin zum 31.07.09 mir VDSL 25 abschalten und DSL16plus schalten würden. Telefonisch geklärt und storniert, zumal ich am 13.07.09 mit keiner Vertreternase gesprochen habe — das war drei, vier Wochen vorher und es ging um einen VDSL25-Neuvertrag zu günstigeren Konditionen.

 
Die telefonische Stornierung hat wunderbar geklappt: ich bekam zwei Tage später das identische Schreiben, nur datiert vom 15.07. statt 13.07.2009 … Gut, kenne ich ja schon, die kostenlose Eintragung zu einer der 6 MSNs meines ISDN-Anschlusses dauerte auch etwas, mit chronisch identischen »Auftragsbestätigungen« falschen Inhaltes. IT muß schwer sein …
Da sich aber nichts tat, ich aber nicht nächste Woche – internettechnisch – im Dunkeln sitzen möchte, denn T-Entertain macht ohne VDSL nun mal gar keinen Sinn, also heute auf in den T-Punkt. Was für ein Spaß. Ich wollte das ja eigentlich nur stornieren, aber gut, die Leute dort leben von Abschlüssen, also durften sie sich am »Produktwechsel« T-Entertain Comfort Universal VDSL25 aus 11/2007 (T-VDSL halt mit dem Entertainquatsch und einem Universal- ISDN-Anschluß) nach T-Entertain Comfort Universal VDSL25 2009 (irgendwas bei 58 statt 73 EUR im Monat …) versuchen.
Ich mache es kurz: ging nicht. Ich bekomme hier kein VDSL25. Also, nicht neu oder als Produktwechsel von VDSL25. Geht nicht, sagt der Computer. Ist Blödsinn, er hat doch schon VDSL und will nur den neuen Tarif, schrieb nun der bedienenden Azubi im Auftrag des weiblichen »Hauptdarsteller[s]« in die Auftragsmaske. »Muß ich das weiterleiten?« – »Ja! Da müssen die sich drum kümmern.«
Den wahrscheinlichen Grund für dieses Kuriosum liefert die VDSL-Ausbaustand-Abfrage; wie auch schon auf einer Karte im T-Punkt, so zeigt auch die Abfrage online für meine Wohnung grade keine VDSL-Verfügbarkeit mehr an. Und mit per Google geschätzten 900m Kabelstrecke dürfte hier auch das Ende der technischen VDSL-Möglichkeit liegen. Warum ich nun aber mein VDSL25/2,5, wa sich ja habe, nicht verlängern, nein, in den neunen, günstigeren Tarif mitnehmen können soll, das versteh’ wer will. Ich werde also zur Absicherung mal wieder ein Einschreiben mit Rückschein an die zuständige T-Niederlassung senden, daß eine VDSL-Abschaltung einer Kriegserklärung gleich kommt, ich sie dann gar nicht mehr lieb und sie per sofort einen Kunden weniger haben. Die ISDN-Nummern gehen dann nach VoIP und 1x VDSL ersetze ich durch 2x DSL16000; Alternativen gibt’s dank fehlendem VDSL-Wettbewerb ja nicht :(

Nachdem nun der Alice-Komplettanschluß in der Praxis meiner Frau und deren Kollegin funktioniert – Anektode am Rande: Stilecht kam die Information über den Techniker-Einsatz am 15.07.09 zwischen 8 und 12 Uhr am 15.07. oder 16.07. auch per Post bei uns an; nicht ohne den Hinweis natürlich, daß eine unangekündigte Abwesenheit unsererseits Folgebesuche kostenpflichtig machen würde; ich weiß ja nicht, was sich Hansenet/Alice da für einen postalischen Dienstleister angelacht hat, er hat aber augenscheinlich Transportzeiten wie die Hamburger Behördenpost (die Information, daß ich zum Vertreter des Betreuungsbevollmächtigten ernannt wurde, ausgestellt zwei Tage vor dem Tode meines Vaters, erreichte mich postalisch schon ca. drei Wochen nach dessen Ableben; auch in Deutschland hilft bei Behördenkontakten eben nur Schwarzer Humor), zum Glück gehen die SMS von Alice zumindest zu D2 zeitnäher raus –, und im Zuge dessen auch meine heimische Telefonie »fritzisiert« wurde, wende ich mich derzeit letzten Aufräumarbeiten zu.
Beim Überprüfen alter VoIP-Verträge – ich mache ja mit VoIP eigentlich seit Ende der 90er rum – stolperte ich über eine DSL-Ausfall-Offerte einer meiner (VoIP-) Anbieter:

ISDN Dial-Backup¹ [sup]NEW![/sup]

€ 11.90 monatlich 4.8 Ct/min.

¹Sollte die DSL-Verbindung einmal gestört sein, wählt sich der Router automatisch via ISDN ein und bekommt die gleiche IP-Adresse und optional das gleiche Subnetz wie über die DSL-Verbindung zugewiesen.

 
Vielleicht bin ich ein Bandbreitenschwein; aber ich habe einen VDSL25-Anschluß, und jenen sichere ich (in Eigenregie) über HSDPA ab (Tchibo/o2) — und stelle immer bei VDSL-Unpäßlichkeit fest, daß eine maximale Geschwindigkeit von 3600/384 kBit/sec kaum reicht als 25000/2500-kBit/sec-Backup. Wie sollte das erst mit einem Backup von 64/64 kBit/sec für (max.) 16000/1024 kBit/sec aussehen‽
Auch die Kostenrechnung ist meines Erachtens interessant; für den ISDN-Zugang alleine (kein NGN bitte, denn das ist bei DSL-Ausfall i. d. R. mit weg) fallen an Telekom oder Mitbewerber wenigstens 10, eher 20, EUR im Monat an. Der Anbieter möchte für die Bereitstellung des Dienstes weitere 11,90 EUR/Monat – nutzungsabhängige Entgelte nicht inbegriffen.
Ein HSPA-Zugang kostet heute einmalig € 59,99 (Angebot Medion-Surfstick)/~€ 50,00 (Angebot Tchibo für E160); dazu kommen monatliche Raten für eine »5GB-Flatrate« von unter 20 EUR/Monat. Für einen geringeren monatlichen Obulus bekomme ich also mehr MBit/sec — wer will da noch ISDN-Backup?

Schade, schade. Dabei fing der computerisierte Tag doch gut an:

Google Voice
You are invited to open a free Google Voice account. To accept this invitation and create your account, visit https://www.google.com/[…]
If you haven’t already heard about it, Google Voice is a service that makes using your current phones much better! […]
Please note that Google Voice is only available for sign up in the US.

 
Freute ich mich initial, mußte ich leider feststellen, daß der – erst überlesene – Hinweis auf USA-only leider nach wie vor gilt — siehe Screenshot. Grmbl, und ich hätte doch auch eine USA-Nummer genommen (wär’ ja, SIP sei Dank, nicht die Erste ;)).
Und, was meint die Leserschaft: wird auch der Dienst auf Europa, insbesondere Deutschland, ausgeweitet werden? Ich bin da ja leider eher skeptisch, zumal Google in USA schon recht lange an dem Dienst schraubt … Und, eigentlich, so richtig neu ist es ja auch nicht, was Google Voice bieten soll; derlei bieten teilweise VoIP-Anbieter hier schon länger (Voice-to-Text ist imho neu) — und durch die (Wohn-)Ortsbindung von Festnetznummern auf Geheiß der BNetzA geht derlei in D ja eigentlich auch gar nicht: