Category: Geeks & Co.

Lange habe ich mich ja gegen diese eierlegenden Wollmilchsaumodemrouteraccesspoints mental gewehrt, weil ich wenig bis keinen Sinn darin sah, gut funktionierende und am jeweiligen Wunschzielort problemlos aufstellbare Einzelgeräte ((V)DSL-Modem, PPPoE-Router, ISDN-DECT-Anlage, Netzwerkswitches) durch eine potentiell nicht so leistungsfähige, weniger ausgereifte und – Hauptargument – im Keller beim DSL-Anschluß vollkommen deplazierte Komplettanlage wie ein Speedport W900V (Fritz!Box Fon WLAN 7170 plus DECT-Station), Speedport W920V oder, jetzt stärker am Markt vertreten durch die 1&1-Angebote, Fritz!Box Fon WLAN 7240/7270 (aka »1&1 HomeServer« (7240) bzw. »1&1 HomeServer +« (7270) zu ersetzen.
Heute bin ich ins Grübeln gekommen. Denn, echter Mehrwert, die DECT-Basen der 72×0 bieten, zusammen mit dem recht günstigen (für ein DECT-Mobilteil) AVM Fritz!Fon MT-D, sog. »HD-Audio«, realisiert über VoIP (SIP) und den Codec G.722. Klar, derlei gab’s auch schon länger im Siemens-Gigaset-Lager, einige der »IP-Basen« konnten in Verbindung mit einigen Gigaset-Mobilteilen auch schon seit längerem HD-VoIP, aber mir zumindest waren diese Gerätschaften immer zu teuer, zumal ich eine hochfunktionale Gigaset-Infrastruktur auf ISDN-Basis mit der SX353isdn schon habe … Mein Weg ist/war bislang, zwischen ISDN-Amt und ISDN-Anlage einen Asterisk zu stellen, der dann die VoIP-Welt auch den DECT-Telefonen meiner Gigaset-Basis/-Basen eröffnent. Und mit 80 kBit/sec ISDN-VoIP war die Sprachqualität eigentlich auch immer ISDN-like.
Mit dem Aufkommen von recht günstigen/zwangsweise einbezogenen (Festnetz-) Flatrates ließ ich VoIP VoIp sein, jetzt, rund zwei Jahre später, scheint sich tatsächlich etwas zu tun; nicht nur, daß die Deutsche Telekom beginnt, ISDN-Technik abzureißen und ISDN-Dienstmerkmale per NGN-IAD bereitzustellen (allerdings ohne Kostenvorteil für den Endkunden, ggf. sogar mit dem Nachteil fehlender Call-by-Call-Option), nein, es gibt mit HD-Codecs endlich – neben Video-per-SIP – einen Mehrwert bei VoIP. Bislang, freilich, nur im engsten Early-Adopter-Kreise, denn HD-Telefonie geht m. W. ausschließlich über VoIP und nur zwischen wenigen Endgeräten überhaupt bislang. Wer ein solches Gerät schon besitzt, AVM stellt SIP-Ziele zur HD-Telefonie-Demonstration bereit.
Konfigurationstip für Asterisk: Bei den entsprechenden Gegenstellen (hier: FBF 7240 inbound, AVM outbound) explizit G722 erlauben, dann klappts auch mit dem Sternchen ;)

Ich habe lange Zeit die Linux-basierenden kleinen Alleskönner von AVM, die Fritz!Boxen, ignoriert; zu Unrecht, wie auch ich nun zugeben muß.
Bedingt durch »äußere Umstände« stehe ich vor der Aufgabe, ich erwähnte derlei wohl schon, eine MSN des heimischen ISDNs ein paar Kilometer entfernt bereitzustellen. Rauslösen einer MSN aus einem Vertrag sieht das bundesdeutsche Regulativ nicht vor, also nimmt der Linuxer seine eierlegende VoIP-Milchsau, Asterisk, und googelt mal ein wenig. Ein ISDN<->ISDN-Gateway hatte ich mir ja schon vor Jahren gebaut und damit auch ISDN-Anrufe per SIP oder IAX2 $sonstwohin geleitet; das Problem bislang war nur, daß ich vermeiden wollte, am Zielstandort auch »dickes Serverblech« hinzustellen …
Also flugs die verstaubenden eBay-Schüsse vom Typ 5140 und 7170 rausgekramt, die ich mir vor ein paar Jahren mal zugelegt hatte. »So’ne Fritz!Box kann doch ISDN extern und intern sowie SIP, da muß doch was gehen …«
Und ja, es geht was, so eine 7170 mit der aktuellen Firmware ist schon ein kleines Kommunikationszentralenwunder, bietet sie doch Fax2Mail, bis zu drei Anrufbeantworter, ISDN Amt und ISDN intern plus 2-3 analogen Anschlüsse, z. B. für ein »echtes« Fax. SIP-Accounts kann sie auch noch verwalten, Bandbreite im Zaum halten bei VoIP-Nutzung — und dabei ist sie nebenbei auf Wunsch noch ADSL2+-Router mit 4x Fastethernet und WLAN … Kurz: Eigentlich ideal für das entfernte Office.
Also flugs die 7170 per SIP an Asterisk gekoppelt, Wahlregeln in der 7170 eingerichtet, so daß die fragliche MSN auf dem internen ISDN zu liegen kommt, das angeschlossene ISDN-Telefon konfiguriert und noch Wahlregeln im Asterisk hinterlegt, sodaß ein Auruf, der per HFC-PCI-Karte und zapata auf der fraglichen MSN ankommt, per SIP an die 7170 geschoben wird => fertig ist die Laube, das ISDN-Telefon an der 7170 klingelt, Verbindung steht, alles geil.
Hmm. Was aber, wenn nun ein Anruf statt über die neuen Nummern über die alte ISDN-MSN geführt werden soll? Derlei ist etwas schwieriger zu machen, um nicht zu sagen, von der Fritz!Box-Firmware so nicht vorgesehen. Man kann Zielrufnummern routen, aber scheinbar nicht in Abhängigkeit der abgehenden MSN andere Wahlpläne selektieren. Gut, der Fall steht auch nicht auf der Anforderungsliste, aber ich sorge gerne vor; mal sehen, vielleicht findet sich dafür ja auch noch eine Lösung …
Angestachelt von den Möglichkeiten, habe ich mich mit der Fritz!Box Fon mal weiter auseinandergesetzt; es gibt dort ja schon seit Jahren eine sehr aktive Community, die die Möglichkeiten der FBF (Fritz!Box Fon) durch Add-Ons und Firmwareergänzungen bis hin zu -modifikationen erweitern. Und so, wenig überraschend eigentlich, stieß ich auch auf einen OpenVPN-Server für die FBF; bequem auf USB-Stick oder notfalls per Web-Download installiert, fährt das kleine Schätzchen dan einfach hoch und meldet sich nach kurzer Zeit an einem zentralen OpenVPN-Server an.
Kein großes Ding jetzt eigentlich, das können andere Geräte auch. Richtig »kühl« wird’s aus meiner Sicht durch die Kombination der Dienste: die FBF kann statt über das öffentliche Netz über den OpenVPN-SSL-Tunnel die Verbindung zum Asterisk aufnehmen, was einer – meines Wissens – effektiven Verschlüsselung des VoIP-Traffics gleichkommt. Da kann Wolfgangs Truppe noch so sehr mit der TKÜV rumspielen, diese Kommunikation bleibt Ihnen erst einmal vorborgen. Wenn ich das richtig verstehe – ich habe noch nicht getraced –, kann man Asterisk ferner instruieren, daß die Kommunikation, z. B. wg. NAT, nur über ihn läuft; dadurch sollte die Kommunikation definitig im Tunnel bleiben.
Sicher, dies ist jetzt keine ultra neue Entdeckung; ich finde es aber hinreichend erstaunlich, daß ich mit zwei in der Welt verteilten Fritz!Boxen und einem zentralen Asterisk-Server alleine schon einen sicheren VoIP-Kanal quer durch’s Netz bauen kann. (Sprich: dadurch, daß OpenVPN direkt auf der FBF läuft, braucht’s keine komplexen Aufbauten mit zusätzlichem OpenVPN-Gateway mehr.).
Zudem bietet die aktuelle Firmware für die 7170 (zumindest im AVM-Branding) die Möglichkeit, direkt an der 7170 (und 72×0) SIP-Telefone zu registrieren; als SIP-Telefon kann z. B. auch eine andere Fritz!Box Fon dienen. Auch hier sollte ein Routing durch einen OpenVPN-Tunnel funktionieren (noch nicht getestet im Versuchsaufbau). Ggf. können zwei FBF auch untereinander direkt einen OpenVPN-Link aufbauen, um die Latenz und Fehleranfälligkeit durch einen zentralen Hop zu vermeiden. (Etwas mehr Konfigurationsaufwand, aber technisch simpelst machbar.)
Richtig lustig – ich habe das im Weitverkehrsnetz aber noch nicht getestet – wird es dann, wenn man Asterisk mittels chan_capi und FBRCAPI die »ISDN-Karte« einer FBF über das Internet – via OpenVPN-Tunnel auch verschlüsselt – zugänglich macht: das Internet als ziemlich langer PCI-Bus bzw. USB-Kabel, interessanter Gedanke. Mit der Latenz von 2ms im OpenVPN-Tunnel im LAN klappt das ganz gut, ob es mit 40 bis 80 ms im wirklichen Netz auch noch funktionieren wird, wird man sehen.
Leider, möchte ich fast sagen, sind viele der Möglichkeiten mittlerweile in Deutschland gar nicht mehr nachgefragt, denn in Zeiten, wo nahezu jeder mit DSL-Zugang auch eine Telefonie-Flatrate hat, erübrigt sich das Untertunneln von NATs und Schalten direkter VoIP-Verbindungen aus Kostengründen. Und mangels der Planung terroristischer Anschläge fehlt es mir auch sonst etwas an Einsatzpotential; was bleibt, wäre ein Unterwandern der Vorratsdatenspeicherung – ziviler Ungehorsam dem Wolfgang und seinen Schergen also.

Tja. Asterisk läuft ja, und damit könnte ich dann ja auch mal all’ die lustigen kostenlosen Accounts, die sich so in den Hype-Jahren des VoIPens angesammelt haben, zusammen- und in meinen neuen Asterisk eintragen.
Erstaunlicherweise läuft auch Sipgate mit diesem Asterisk 1.4 (aus Ubuntus Jaunty-Package) auf Anhieb, Sipgate zeigt meinen Asterisk (und die Fritz!box) als registriert an, Anrufe auf meiner ganz frischen Gütersloher Rufnummer werden auch brav an beide Geräte signalisiert — in der ersten Asterisk-Installation klappte trotz keinem NAT das Verbinden mit Sipgate nicht wirklich.

Mal gucken, welche VoIP-Anbieter denn den Frühsommer 2009 erlebt haben:

• Sipgate — alive an’ kickin’
• Monduno — sold ‘n closed, wie’s aussieht. Schade, da hatte ich eine 032-Rufnummer …
• K-DSL — alive an’ kickin’; meine Rufnummer aus dem Ortsnetz 04755 ist von einem T-Com-Anschluß dort (DSL-/NGN-Alternativen gibt es im Glasfaser-Ausbaugebiet nicht) bis heute nur komplett – mit Vorwahl – aus jenem Ortsnetz zu erreichen
• Free World Dialup — Pulver.com hat den Dienst letztes Jahr kostenpflichtig gemacht. Oder mittlerweile eingestellt; genaues gibt’s über Technorati jedenfalls nicht zu erfahren, weil: »Sorry, we’re having technical difficulties with our tag articles« und »blurbs are temporarily unavailable. Please try again later!« Das Web2.0 in der Wartungslücke … ¹
• Web.de — da hatte ich mal ‘nen VoIP-Zugang, und die müßten auch noch Web.Cent von mir dort haben; nach Einstellung des VoIP-Dienstes, Grund für meine Mitgliedschaft, stritten wir uns ein wenig über eine Vertragsbeendigung (zwecks guter Minutenpreise war ich halt »Clubmitglied« geworden) und trennten und letztlich grade noch außergerichtlich.
• AOL — tja, lange Freude an dem kostenlosen VoIP-Account dort hatte ich nicht; man orientierte sich neu und schob die VoIP- (und später die anderen Kunden) ab. Schade, vom Namen her hätte ich da Qualitäts-VoIP erwartet. Tja.
• iaxtel.com — »503 – Service Not Available«; schade, das war, meiner Erinnerung nach, ein lustiger klebe-VoIP-Wolken-zusammen-Dienst. Dann kann der Kram aus der aktuellen extensions.conf wohl auch wech …
• Gizmo5 — alive an’ kickin’; allerdings hat der SIP-Test mit einem Freund in Hamburg irgendwie seit nunmehr zwei Jahren, in denen ich den Gizmo5-Account habe, nicht stattgefunden ;)

Also, irgendwie … ein ernüchterndes Fazit. Viele Dienste, auch »der Ersten Stunde«, gibt es schon gar nicht mehr; für mich hat mit dem Wechsel auf einen Laufzei-T-tarif mit inkludierter Festnetz-Flatrate das Interesse an Asterisk/VoIP nachgelassen, da das Kostenargument nicht mehr da war: Das Komplettangebot der T-Com war günstiger als T-ISDN und T-DSL-16k einzelnd, wobei letzteres noch keine Gespräche umfaßte … Für 0,00 EUR im Festnetz (teilweise mit Fremdnetz-Aufschlag von 0,02 Cent/Minute oder so) telefonieren — das geht auch über VoIP, kostet aber extra, der Kostenvorteil ist mithin dahin.
Und mit den regulatorischen Entscheidungen zu den Roaming-Kosten in der EU fällt auch der letzte Einsatzzweck, nämlich günstiger als über die raffzahnigen Mobilfunkprovider im Ausland erreichbar zu sein — über einen auf Asterisk-Basis selbst gebauten Call-Back- oder Call-Through-Dienst. Ob das der Grund ist, warum United Mobile die Grätsche gemacht hat? Ich weiß es nicht; außer in speziellen Fällen sehe ich aber heute kaum noch Anwendungsfälle für die eigene PBX — zumal vieles eine kleine Fritz!Box – samt Gateway zum ISDN-Netz und ISDN-Endgeräten – schon »einfach so« mitbringt.
_____

Als kleine externe Notiz an mich, sollte ich nochmals einen Asterisk mit ISDN und dem Zaptel-Kram unter Ubuntu bauen wollen:

1. Zaptel-Gedöns muß erst gebaut werden, siehe Hinweis zu 8.04 hier.
2. Fix für Zaptel unter Kernel 2.6.28 (die Kernel-Spielkinder schlugen mal wieder was karpott): hier.
3. Es gibt nun zwei zaphfc-Treiber:

   root@ast-1:~# genzaptelconf -d -c de -v
   Unloading zaptel modules:
   [...]
   Generating '/etc/zaptel.conf and /etc/asterisk/zapata-channels.conf'
   Note: generated /etc/asterisk/zapata-channels.conf not included in zapata.conf
   To fix: echo '#include zapata-channels.conf' >>/etc/asterisk/zapata.conf
   Reconfiguring identified channels
   Zaptel Version: 1.4.11
   Echo Canceller: MG2
   Configuration
   ======================
   SPAN 1: CCS/ AMI Build-out: 0 db (CSU)/0-133 feet (DSX-1)
   SPAN 2: CCS/ AMI Build-out: 0 db (CSU)/0-133 feet (DSX-1)
   Channel map:
   Channel 01: Clear channel (Default) (Slaves: 01)
   Channel 02: Clear channel (Default) (Slaves: 02)
   Channel 03: D-channel (Default) (Slaves: 03)
   Channel 04: Clear channel (Default) (Slaves: 04)
   Channel 05: Clear channel (Default) (Slaves: 05)
   Channel 06: D-channel (Default) (Slaves: 06)
   6 channels to configure.
   Changing signalling on channel 1 from Unused to Clear channel
   Changing signalling on channel 2 from Unused to Clear channel
   Changing signalling on channel 3 from Unused to HDLC with FCS check
   Changing signalling on channel 4 from Unused to Clear channel
   Changing signalling on channel 5 from Unused to Clear channel
   Changing signalling on channel 6 from Unused to HDLC with FCS check

   ==> Man will eines der beiden Blacklisten; welches, mag man per educated guess sich dann selbst überlegen (bei mir war’s vzaphfc, den ich erdete — YMMV).

4. Generell scheint der Hype — und die Arbeit an entpsrechenden OSS-Lösungen — um Asterisk & ISDN vorbei zu sein; die vielbesprochenen HFC-Karten — gelobt für den NT-Modus, also die Möglichkeit der Realisierung eines »internen S0« wie bei »echten« Telefonanlagen; gescholten für ihre IRQ-Last — werden zwar von verschiedenen Asterisk-Channels unterstützt (CAPI, mISDN (diskutativ tot?), vISDN (entwicklungstechnisch offensichtlich tot seit 2006), Zaptel), aber z. B. den »wunderbaren« Patch von Frank Gockel gibt’s nimmer (Details zu dessen Funktion siehe IP-Phone-Forum).
   Auch wird es zunehmend schwierig, Server zu finden, in die man die sehr günstigen HFC-PCI-Karten noch verbauen kann — andere Hersteller bieten (Mehrport-) ISDN-Karten für PCI-e an, hier verlassen wir aber in Lichtgeschwindigkeit das Preissegment rd. EUR 30,–/Karte und schlagen im mittleren bis oberen dreistelligen Bereich ein :(
   Professionelle ISDN-SIP-Gateways allerdings kosten in etwa so viel wie jene Karten; und PCI-zu-PCI-Expanderboxen schlagen auch mit wenigstens EUR 100,– zu Buche.
   Daher, as time and other resources permit:
   • Remote-CAPI der Fritz!Boxen für Nutzung als ISDN-Port an Asterisk evaluieren.
   • Evtl. mal so ein ISDN-SIP-Gateway mal in die Finger bekommen
   • ISDN entsorgen und – endlich – auf VoIP- bzw. SIP-only umsteigen. (Wäre bei einem NGN-Telefonanschluß eigentlich nur konsequent; sähen die Telefone nur nicht durch die Bank wie Spielzeug oder verunglückte Kreuzungen einer Telefontastatur und eines PDAs aus …)

*sigh* Wenn die Fritz-Firmware doch nur ein bißchen mehr Möglichkeiten zuließe, bräuchte ich für den Heimgebrauch wohl keinen Asterisk mehr.

Mal eben schnell wollte ich Anfang der Woche einen Asterisk aufsetzen, um Anrufe auf dem heimischen ISDN an einem entfernten Standort (naja, fast noch in Wurfweite, aber die Pakete werden sicherlich einmal nach Frankfurt (T-Com) und wieder zurück (Alice) laufen) entgegen nehmen zu können.
»Drüben« wird eine Fritz!Box FON (WLAN) stehen, nachdem ich mit meiner antiken 5140 und einer frisch »gebuchteten« 7170 durchaus gute Erfahrungen mit der Anbindung von ISDN-Endgeräten an ISDN- oder VoIP-Netze gemacht habe. Leider kann die FBF jetzt zwar auch SIP-Registrar spielen, aber im direkten Zusammenspiel – andere FBF per SIP an den SIP-Registrar der 7170 – gab es Probleme beim Hangup, das ISDN-/DECT-Telefon an der als SIP-Client an der 7170 registrierten FBF¹ bekam von einer Gesprächsbeendigung leider nie etwas mit :(
Also flugs die Hardwaregrabbelkiste geöffnet und einen Fujitsu-Siemens Scenic Xs als Asterisk-Hardwarebasis sowie eine HFC-basierte ISDN-Karte geschnappt, dazu dann noch ‘nen IDE-Adapter für CF-Karten und eine 8-GB-CF-Karte als Festplatte — irgendwie habe ich keine kleinen (oder überhaupt) IDE-Platten frei und für den Preis einer neuen IDE-Platte bekomme ich ja fast die doppelte Kapazität in SATA …
Ubuntu-8.10-netboot-Tree auf dem DHCP- und TFTP-Server aktualisiert, Scenic Xs eingeschaltet … und festgestellt, daß diese Box eine von denen war², die bei der Einstellung PXE irgendeinen Novell-RBL-Krempel booten wollen. Juchee; wollte ich ja auch schon jahrelang mal ergooglen, wie man sowas wohl netbootet — jaja, so geht das bei »mal eben schnell«.
Um es kurz zu machen, rd. zwei Stunden später rannte ein »rpld« auf meinem designierten neuen DHCP-Server, der dann ein Etherbook-Image bereitstellte, mit wessen Hilfe der Scenic Xs also doch PXE lernte — er bootete dann als neuer LTS-Client meiner LTS-Installation. Also fehlte nur noch der Eintrag für das Ubuntu-Installationsimage ;) Und wieder zurück zur »mal eben schnellen« Asterisk-Einrichtung,  …
… welche sich nur leider als laaangsamer als erwartet gebärdete: die CF-Karte oder ihr IDE-Adapter waren nicht DMA-fähig, und selbst nach entsprechender BIOS-Konfiguration: ohne ide=nodma in grub.conf (sorry, Ubuntu => menu.lst oder so) kam die Kiste nach der zähnen Installation nicht über’s initramfs hinaus (FS not found; der Linux-Kernel hatte noch nicht aufgegeben, sich durch die UDMA-Settings zu hangeln, was länge dauerte als der initramfs-Zwischenschritt zu warten gewillt war *sigh* Wie gesagt, mit »ide=nodma« in der grub.conf gibt’s zwar noch immer Verzögerungen, aber es bootet ohne manuellen Eingriff durch). Mentale Notiz: CompactFlash- (CF-) Karten in IDE-Adaptern => don’t even expect DMA to work :( (Gut, wäre auch vielleicht etwas viel erwartet bei dem Mangel an elektronischen Bauteilen auf einem solchen Adapter.)
Nach vollendeter Basis-Installation dann die Kür: apt-get install asterisk destar² — denn ich wollte ja auch gleich eine GUI haben, zumal diesen ISDN-Karten ohne Dateigefrickel hinzukonfigurieren können soll — nur, leider: #fail.
Nach weiteren Versuchen habe ich immerhin das Ubuntu-Paket von »GAstMan« zur Zusammenarbeit bewegen; aber da auch dies nicht wirklich mir weiterhalf … habe ich schlußendlich zapata.conf & Konsorten doch wieder mit meiner Konfigurationsallzweckwaffe – emacs – beacktert. Resultat: ein Anruf aus dem Mobilnetz auf eine bestimmte ISDN-MSN landet sowohl auf den lokal angechlossenen ISDN-Geräten inkl. AB also auch, parallel, am ISDN-Gerät der FBF 7170, die sich als SIP-Client am Asterisk angemeldet hat (das alles bislang nur im LAN getestet; notfalls muß halt noch ein Tunnel gebuddelt werden).
Tja, Asterisk zu installieren ist eben doch kein »rocket science« — aber ein (freies) Frontend, welches eine Asterisk-Installatation »versteht« und konfigurierbar macht, harrt wohl noch der Entwicklung :( Also doch alles zu Fuß; denn destar mag mir auch keine Config zeigen:

Traceback (most recent call last):
File "/var/lib/python-support/python2.5/quixote/publish.py", line 522, in process_request
output = self.try_publish(request, env.get('PATH_INFO', ''))
File "/var/lib/python-support/python2.5/quixote/publish.py", line 457, in try_publish
output = object(request)
File "/usr/share/destar/python/page_admin_viewconf.ptl", line 80, in _q_index
res = backend.createAsteriskConfig()
File "/usr/share/destar/python/backend.py", line 393, in createAsteriskConfig
c.createAsteriskConfig()
File "/usr/share/destar/python/cfg_opt_oppanel.py", line 81, in createAsteriskConfig
panelutils.createManagerConfig(self)
File "/usr/share/destar/python/panelutils.py", line 53, in createManagerConfig
c.append("manager_secret=%s" % manager.secret)
AttributeError: 'NoneType' object has no attribute 'secret'[...]

Immerhin, Anrufe auf dem ISDN für die betreffene MSN werden nun brav parallel am heimischen S0 als auch, über SIP zur entfernten FBF, am entfernten S0 signalisiert, so soll das erst mal sein. Die Kür wird dann sein, presence detection zu machen (festgemacht am BT-Handy z. B.?) und Asterisk als auch die FBF die Rufe entsprechend umzuleiten zu lassen (im Büro: ISDN-alt auf ISDN-neu via SIP; zu Hause: ISDN-neu auf ISDN-alt via SIP; weder noch: Parallelruf, ggf. auf Handy? Hach, es gibt so viele schmutzige Dinge, die man einem Telefonat mit Asterisk und SIP antun kann ;)) …
___

Also, eigentlich wollte ich ja – nach den jüngst gemachten Erfahrungen – via (o2-) HSPA einen DSL-Fallback mir bauen. Mit openvpn und olsrd klappte das schon bei zwei DSL-Leitungen sehr gut, für die Anbindung eines HSDPA-Routers (‘ner »Surf@home II«-Box von o2) mußte ich etwas tricksen (VLAN zum vom Hausrouter zwei Etagen entfernten HSDPA-Router schalten), aber es klappt – Normalzustand:

wusel@brick:~$ mtr probe-2y.0xdecafbad.net --report-cycles=30 --report
HOST: brick Loss% Snt Last Avg Best Wrst StDev
1. igor.uu.org 0.0% 30 3.0 46.2 0.8 1166. 213.9
2. azrael-vdsl.uu.org 0.0% 30 45.2 83.2 42.0 1107. 194.1
3. ns.sungurus.de 0.0% 30 43.4 78.5 42.0 1006. 175.7
[...]
10. probe-2y.0xdecafbad.net 0.0% 30 63.8 102.9 49.3 1314. 234.1

… und automatisch binnen ca. 2 Sekunden nach Wegfall der VDSL-Leitung …

wusel@brick:~$ mtr probe-2y.0xdecafbad.net --report-cycles=30 --report
HOST: brick Loss% Snt Last Avg Best Wrst StDev
1. igor.uu.org 0.0% 30 1.0 2.0 0.8 5.9 1.5
2. azrael-hspa.uu.org 0.0% 30 104.2 114.3 102.5 139.7 9.9
3. ns.sungurus.de 0.0% 30 114.1 116.4 102.3 166.2 12.3
[...]
10. probe-2y.0xdecafbad.net 3.3% 30 124.7 120.0 112.0 156.4 7.9

Der Schwenk zurück auf VDSL geschieht ebenfalls vollautomatisch, sofern die VDSL-Leitung »besser« ist als die HSPA-Strecke.
Soweit, so gut. Womit ich nun allerdings nicht gerechnet hatte – derlei hatte ich auch bei ausgedehnter always-on-Nutzung über’s Wochenende in DSL-losen Gegenden nicht – war, daß der »Surf@home II«-Router bzw. das o2-Netz stationär hier in GT-City die UMTS-Verbindung verlieren; da der »Surf@home II« auf UMTS-only eingestellt ist (bei GPRS wird keine Verbindung aufgebaut) und o2 sich im übrigen weigert, mir als Nicht-Ersteigentümer des Routers trotz Zeitablauf den Freischaltcode für andere Netze zu nennen, muß dieser Versuch als kompletter Fehlschlag gewertet werden.
*sigh* Einmal mit Profis …

May 13 13:41:57 brick kernel: [ 307.000074] usb 2-1: new full speed USB device using uhci_hcd and address 3
May 13 13:41:57 brick kernel: [ 307.165245] usb 2-1: configuration #1 chosen from 1 choice
May 13 13:41:57 brick kernel: [ 307.577830] cdc_acm 2-1:1.1: ttyACM0: USB ACM device
May 13 13:41:57 brick kernel: [ 307.580540] usbcore: registered new interface driver cdc_acm
May 13 13:41:57 brick kernel: [ 307.580548] cdc_acm: v0.26:USB Abstract Control Model driver for USB modems and ISDN adapters
May 13 13:42:19 brick NetworkManager: <info> (ttyACM0): ignoring due to lack of mobile broadband capabilties 

Unter Kernel 2.6.30 RC5 in der Ubuntu-Inkarnation ist denn, wie schon woanders beschrieben, dieser GPS-Logger (Unterschiede: 747 A+: 66 channels, 4 MB; 747 A: 51 channels, ? MB) ansprechbar.
Leider funktionierte es nicht wirklich mit »MTKBabel Version 0.7« aus dem Ubuntu-Repository:

wusel@brick:~$ mtkbabel -p /dev/ttyACM0 -d7
16:22:20 TX packet => PMTK000*32
Writing 13 bytes to device; actually written 13 bytes
16:22:20 RX packet <= GPGSA,A,1,,,,,,,,,,,,,,,*1E
16:22:20 RX packet <= GPGSV,4,1,13,08,64,063,,10,55,211,,28,48,137,20,15,40,291,*79
16:22:20 RX packet <= GPGSV,4,2,13,07,23,063,,24,17,274,,27,16,245,,21,13,316,*7B
16:22:20 RX packet <= GPGSV,4,3,13,26,11,290,,19,09,045,,25,05,067,,03,04,020,*75
[...]
16:22:26 RX packet <= GPGGA,142226.500,5153.5729,N,00823.0484,E,0,0,,69.4,M,47.3,M,,*76
16:22:26 ERROR: packet_wait() failed for packet PMTK001,0,
MTK Test OK
16:22:26 TX packet => PMTK604*30
Writing 13 bytes to device; actually written 13 bytes
16:22:26 RX packet <= GPGSA,A,1,,,,,,,,,,,,,,,*1E
16:22:26 RX packet <= GPGSV,4,1,13,08,64,063,,10,54,210,,28,48,137,18,15,40,291,*72
[...]
16:22:32 RX packet <= GPGGA,142232.500,5153.5729,N,00823.0484,E,0,0,,69.4,M,47.3,M,,*73
16:22:32 ERROR: packet_wait() failed for packet PMTK001,604,
16:22:32 TX packet => PMTK605*31
Writing 13 bytes to device; actually written 13 bytes
16:22:32 RX packet <= GPGSA,A,1,,,,,,,,,,,,,,,*1E
16:22:32 RX packet <= GPGSV,4,1,13,08,64,063,,10,54,210,,28,48,137,16,15,40,291,*7C
[...]
16:22:38 RX packet <= GPGGA,142238.500,5153.5729,N,00823.0484,E,0,0,,69.4,M,47.3,M,,*79
16:22:38 ERROR: packet_wait() failed for packet PMTK705,
MTK Firmware: Version: , Release: , Model ID:
16:22:38 TX packet => PMTK182,2,2*39
Writing 17 bytes to device; actually written 17 bytes
16:22:38 RX packet <= GPGSA,A,1,,,,,,,,,,,,,,,*1E

Sieht ein bißchen taub aus, sowohl auf Einstellung LOG als auch NAV ist der Ablauf so; bei OFF ist das Gerät aus und das Device auch weg ;)
Na, kommt Zeit, kommt bestimmt auch Funktion – als GPS-Maus sollte es so auch schnurgebunden schon mal gehen ;)

Ts, geht doch glatt ein Hype an mir im (fast) netzlosen Urlaub an mir vorbei? Oswald, danke für die Infos zu Poken; generell bin ich ja ein Freund des erst-anschauen-dann-verreissens, da aber schon die Bestellung eines Pokens heute am + in der Mailadresse scheiterte, werde ich das wohl aus der Ferne kommentieren müssen. (Es sei denn, missionpoken ändert da tatsächlich noch was.)
Generell finde ich die Idee ja interessant – wenn sie auch nicht neu ist, auf »e« wurde schon hingewiesen und IIRC haben die VNC-Entwickler in den ehemaligen Olivetti Research Labs schon vor zig Jahren ähnliche Ansätze – Active Badge – verfolgt. Was mich an Poken erst einmal als Visitenkartenersatz störte, wären die gar grauslichen Designs; ich kann mir nur wenige Entscheider vorstellen, denen ich ernsthaft einen Panda, eine Biene oder ein Alien auf ihre Pokemons, Verzeihung, Pokens drücken würde. Das mag ein Gimmick für SuperRTLs Kinder(werbungs)fernsehen oder Panfu sein, aber als Visitenkartenersatz gefällt mir keines der Designs (weshalb ich den Alien bestellt hätte, wenn man mich gelassen hätte).
Weitaus sinniger wäre meines Erachtens anstelle dieses zusätzlichen Gadgets eine Wireless-Business-Card-Anwendung für all die BT-fähigen Telefone da draußen – denn anders als einen Schlüsselanhänger, der wie vom eigenen minderjährigen Kind geklaut aussieht, hat mein Bilderbuchmanager seinen Blackberry, sein i- oder sonstiges Smartphone immer dabei.
Ach halt, das gibt’s ja schon, in Form des vCard-Standards. Zumindest von älteren zu neueren Nokia-Telefonen klappt das auch schon ganz gut – und drahtlos, sei es per Blauzahn, Infrarot oder, notfalls, über SMS …
Aber Poken bietet natürlich einen deutlich höheren Spaßfaktor:

Twittern ist ja heute eher ein Muß, und gelegentlich überkommt es mich, mobil auch mal was twittern zu wollen; bislang mache ich das per twibble über mein E71 (und der »Fair«-Flat von o2). Vor einiger Zeit klappte das Hochladen von Bildern via twibble nicht mehr, augenscheinlich ein Problem zwischen twibble und Twitpic — doof nur, daß die komplette Nachricht im Nirvana verschwand, nicht nur das Bild.
Heute, zum wöchentlichen Treffen der unanonymen Koffeiniker, habe ich beim twibble-Start den Hinweis bekommen, mein twibble wäre outdated; und wenngleich die twibble-Homepage nicht grade Vertrauen zu erwecken vermochte, ich führte das Update durch.
Und, siehe da, nun geht auch wieder der Bildupload — dafür fällt mir auf, daß – dies war allerdings auch schon bei Twitpic so – meine Updates mit Bildupload nicht vom twibble-Client kommen sondern vom Bilderdienst, jetzt also Mobypicture.
Warum beschleicht mich das dumme Gefühl, daß eine Handvoll externer Dienste nun schon meine twitter-Credentials kennt? Die Website von Mobypicture verleitet auch zum munteren Credential-Versand:

From now on, if you already have a Twitter account, you don’t have to have an account at Moby to start using it ! How does that work?
You just send an email or MMS containing a photo, a title (subject) and optional a text (body) to:

(so for example: johndoe.jane@mobypicture.com)
In the background we process the message and semi register your Mobypicture account. And we post the update to Twitter for you. We will also send you a direct message on Twitter with a link and instructions to complete your registration. Completing the registration is optional but very useful if you also want to post your pictures directly to other services.
Start sharing your adventures today!

 
In Zeiten, wo Zensursula und der bundesinnere Rollstuhlfahrer augenscheinlich die Restasifizierung Deutschlands verfolgen, ist eine derart ungeschütze Weitergabe der Credentials nicht wirklich nach meinem Geschmack … Also doch lieber was Eigenes hochziehen? *sigh*

Ein kleines Update zum Projekt Painseeker HDTV-tauglicher VDR: Die auf Basis vdr-1.7.0 neu gebauten VDR-Pakete liefen nun ein paar Tage lang im Testbetrieb (wenn auch mit nur 1 DVB-S2-Karte aufgrund Anschlußmangels).
Und auch die derzeit favorisierte MediaCenter-Oberfläche, XBMC, habe ich neu gebaut bekommen aus dem xbmc-vdpau-SVN (xbmc-svn-Quellpakete nehmen, mittels uupdate auf xbmc-vdpau-Quellen hochziehen, durchbauen, fertisch) – hier leider mit nur partiellem Erfolg: während mit Nvidias Treibern in Version 180.35 und mit XBMC-SVN (ohne VDPAU-Unterstützung) diverse Test-Dateien erfolgreich, wenn auch mit bis über 90% CPU-Last, teilweisen Aussetzern und einem auf 190 Watt (von ~90 kommend) steigenden Energieverbrauch angezeigt wurden, hakt es bei bestimmten Dateien (VC-1?) nun mit Nvidia 180.37 und XBMC-VDPAU. Statt des dekodierten Videos wird der Desktop unter dem XBMC-Fenster zermarmelt und statisch angezeigt. Dafür steigt auch bei H.264-Videos die CPU-Last bei Full-HD-Darstellung nicht über 30% (der Kern rennt weiter mit nur 1350 MHz statt des Maximums von 2700). Man kann wohl nicht alles haben ;)
Weniger lustig hingegen war ein vermutetes Kernelproblem des 2.6.27-11er Ubuntu-x86-Kernels, den ich als aktuelle Basis bei meinem HDTV-VDR verwendete; weder über USB (mit lir_ttusbir) noch über eine extra verkabelte serielle Schnittstelle (lir_serial; das Asus-Mainboard hat immerhin noch einen Header für COM1; Grabbelkiste++ :-)) war eine stabile Funktion von LIRC möglich. Nach kurzer Zeit kamen über das entsprechende Kernelmodul wirre Signale, selbst wenn keine FB sendete, irrecord brach ab (keine Daten in 10 Sekunden oder sowas), ähnlich wie bei anderen.
Der Test des Technotrend-USB-IR-Empfängers – welcher wohl derzeit abverkauft wird –, der seit ca. einem Jahr von LIRC unterstützt wird, an einem anderen Ubuntu-Rechner ergab dann überraschenderweise keine dieser Probleme, auch nicht über eine längere Zeit. Der Vergleich der installierten Kernel ergab dann, daß jener Rechner mit 2.6.27-12 lief, weitere Recherchen brachten dann zu Tage, daß ich dort das »intrepid-proposed«-Repository eingebunden hatte. Nachdem ich nun auf meinem HDTV-VDR-Rechner dies ebenfalls getan habe und auf 2.6.27-13 gegangen bin, sind meine Probleme mit LIRC zumindest seriell vom Tisch …