blog@netplanet

Wer die Fritzbox zum Telefonieren verwendet, hat sicherlich auch schon dem Komfort des zentralen Telefonbuches entdeckt, das man in der Fritzbox anlegen und verwalten kann. Gerade mit der Fritzbox 7270 und mehreren DECT-Mobilteilen ist das eine wirklich angenehme Sache, da alle Mobilteile so auf das gleiche, zentrale Telefonbuch zugreifen können.

Ein Wermutstropfen des Telefonbuches ist, dass man es nicht ohne weiteres exportieren und in eine andere Fritzbox importieren kann. Will man das Telefonbuch in eine andere Box übernehmen, funktioniert das nur, wenn man die gesamte Konfiguration abspeichert und übernimmt und auch das funktioniert nur, wenn die andere Fritzbox exakt die gleiche Firmware an Bord hat, als die Fritzbox, aus der die Konfiguration kommt. Noch auswegloser wird es, wenn die andere Fritzbox aus einer anderen Modellreihe kommt, denn auch da lässt sich die Konfigurationsdatei einer anderen Box nicht importieren. Also hilft nur das Extrahieren der Telefonbuchdaten aus einer Konfigurationsdatei und das ist leider nicht ganz so einfach.

Zuerst brauchen wir einmal so eine Konfigurationsdatei. Die lässt sich (in der Fritzbox 7270) in den Erweiterten Einstellungen, dort unter System und dort dann unter Einstellungen sichern erzeugen und auf den lokalen Computer abspeichern. Ergebnis ist eine Textdatei mit der Dateiendung “.export”, die die Konfiguration der Fritzbox enthält, teilweise in Klartext, teilweise verschlüsselt (beispielsweise Benutzerdaten) und teilweise komplett codierte Bereiche. Darunter auch das Telefonbuch, das sich weiter unten in der Konfigurationsdatei in einem Block befindet, der folgendermaßen gekapselt ist:

**** BINFILE:phonebook
3C3F786D6C0 [..] 3C736572766963
**** END OF FILE ****

Professionelle Codeschnupfer erkennen zwischen den Zeilen “BINFILE” und “END OF FILE” Zeichenfolgen, die darauf schließen lassen, dass hier etwas hexadezimal codiert wurde und man ja spasseshalber diese Inhalte einmal in binäre Schreibweise konvertieren könnte. Dazu gibt es genügend Software, aber auch Dienste im Web, beispielsweise einen Universalübersetzer von Paul Schou. Man nehme also den Inhalt aus dem “BINFILE:phonebook” der Konfigurationsdatei, lasse die Zeilen “BINFILE” und “END OF FILE” weg, kopiere das Substrat in den obigen Universalübersetzer in die vierte Textbox namens “HEX” (oberste Reihe ganz rechts) und klicke auf den darunter liegenden Button namens “DECODE”. Nach wenigen Sekunden erscheint dann in der linken Box namens “TEXT” der decodierte Inhalt. Und Bingo, der decodierte Inhalt ist lesbar und nichts anderes wie in hexadezimale Schreibweise übersetzter XML-Code. Dieser XML-Code ist sogar vollständig, fast korrekt (dazu kommen wir gleich), allerdings nicht hübsch formatiert, so dass die XML-Verschachtelung nicht sichtbar ist. Das machen wir im nächsten Schritt, wenn einem diese Ansicht zum Abschreiben nicht genügt. Denn darauf läuft es leider hinaus, es gibt keine eingebaute Importfunktion für das Telefonbuch.

Wer also den XML-Code übersichtlich verschachtelt haben möchte, kopiert deshalb einfach aus dem Fenster den Code erst einmal heraus, diesen in eine Textdatei und speichert das dann ab. Diese Textdatei benennt man dann sinnvollerweise mit der Dateiendung “.xml”, um es dem nächsten Schritt leichter zu machen. Da nämlich der XML-Code einen syntaktischen Fehler und zudem am Ende des Telefonbuches noch ein Teil hat, der eigentlich gar nicht zum Telefonbuch gehört, wird es nun etwas schmutzig. Zwei Dinge sind zu tun:

1. In der ersten Zeile erscheint folgender Text:
   <?xml version="1.0" encoding="iso-8859-1">
   Diese XML-Einführungszeile ist falsch und muss folgendermaßen aussehen. Man beachte das neu hinzugekommene Fragezeichen als vorletztes Zeichen:
   <?xml version="1.0" encoding="iso-8859-1"?>
2. Im Text nach folgender Zeichenfolge suchen:
   <phonebook owner="255">
   Der Inhalt, der nach dieser Zeichenfolge folgt, sind Telefonbucheinträge von internen Geräten, beispielsweise der Anrufbeantworter oder angemeldeten Mobilteile. Da diese Einträge nicht erforderlich sind und zudem auch noch falsch verschachtelt, einfach alles ab der obigen Zeichenfolge bis zum Ende der Datei löschen, inklusive der obigen Zeichenfolge.

Nun dürfte der XML-Code korrekt sein, bitte abspeichern. Am ehesten sehen wir das, wenn wir nun einen echten XML-Editor mit Syntax-Überprüfung einsetzen. Unter Windows gibt es den kostenlos herunterladbaren Microsoft XML-Editor, der dies kann, grundsätzlich tut es aber jeder andere XML-Editor auch. Also den XML-Editor der Wahl öffnen und die XML-Datei öffnen. Ist der XML-Code korrekt, gibt es hier keine Fehler und nun können hier, wenn der Editor einigermaßen brauchbar ist, die Einträge bequem angezeigt werden:

Mit Drag’n'Drop kann man nun die einzelnen Inhalte in die neue Fritzbox und in deren Telefonbuch übernehmen. Richtig schön ist das alles nicht, aber immerhin kommt man so zumindest an das alte Telefonbuch heran. Vielleicht mag ja AVM auch mal meine Verbesserungsvorschläge lesen und zu Herzen nehmen, die eine bequemere Ex- und Importfunktion als Wunsch beinhalten.

Äh, nein, ich glaube nicht daran, dass rottenneighbor.com angeblich von einigen Providern zensiert wird. Dazu ist die Idee uralt und immer noch plump, das Risiko von eigenmächtigen Zensuren durch einzelne ISP in Deutschland nach wie vor ein viel zu heißes Eisen und überhaupt besteht dazu eigentlich gar keinen Grund. Müsste man rottenneighbor.com zensieren, müsste man noch viele andere Dinge zensieren – im Vergleich zu vielem anderen Zeug im Internet, das sicherlich genügend Politiker gefiltert sehen würden, ist rottenneighbor.com ein Fliegenschiss. Über meinen Zugang (Interoute) funktioniert rottenneighbor.com zumindest weiterhin.

Was allerdings eher Tatsachen sind, sind folgende:

1. Der Dienst ist seit Wochen gnadenlos überlastet. Zum einen rotiert die Website als beliebtes Beispiel für das ach so böse Internet gerade die Medien rauf und runter – die Redaktionen von praktisch allen Lokalblättern in Deutschland, die dpa-Nachrichten für eigene Artikel verwursten, machen sich da derzeit quasi die Schlüpfer nass vor Glück – und zum anderen liegt der Webserver in den tiefsten Tiefen der USA, der traceroute von mir braucht allein 18 Hops bis zum Webserver, der auch noch munter auf ICMP-Anfragen antwortet, was den mülligen Ansatz von rottenneighbor.com mehr als deutlich unterstreicht.
2. Man spielt am DNS herum und versucht sich an Loadbalancing. Wer aufmerksam schaut, wird nach der Eingabe von www.rottenneighbor.com erkennen, dass die Anfrage auf www.de.rottenneighbor.com umgeleitet wird und von dort aus die Antwort kommt. Allerdings ist das nur einfachstes Loadbalancing, denn der “de”-Webserver steht hinter den gleichen 18 Hops und hat eine IP-Adresse aus dem gleichen IP-Adressnetzwerk. Angenommen, sie frickeln am DNS, schalten die Umleitungen und blocken dann entsprechend auf den anderen Webservern die da noch hinkommenden Anfragen – kein neues Verhalten von Administratoren, denen das Wasser bis zum Hals steht vor Anfragen.

Was nun als einziges Theorem zurückbliebe, wäre der Verdacht, dass rottenneighbor.com dediziert einen Webserver für Deutschland betreibt. So viel Rücksichtnahme von einer mashenden Garagenband in Santa Barbara würde mein Weltbild über das Weltbild des klassischen Amerikaners allerdings gehörig auf den Kopf stellt.

Gut, Wake-on-LAN (also die Möglichkeit, von einem anderen Gerät aus einen Rechner aus dem Standby zu “wecken”) ist bei der AVM Fritzbox nichts fundamental neues, da einige alternative Softwareimplementierungen diese Möglichkeit ebenfalls anbieten. Das ist jedoch mehr oder weniger komplexes Frickelgeschäft. Allerdings ist neu, dass AVM dies nun auch selbst in der offiziellen Firmware plant. “Planen” deshalb, weil es seit einigen Tagen nun “Labor”-Versionen der zukünftigen Firmware für die Fritzbox 7170 und 7270 gibt, die eben genau dies kann.

Die AVM-Entwickler lassen sich nicht lumpen und haben endlich im Einstellungsmenü den Punkt “Netzwerk” grundlegend aufgeräumt. Die dort angezeigte Liste mit lokalen Gerätschaften lässt sich nun endlich auch editieren, so dass beispielsweise längst ausrangierte Geräte gelöscht werden oder IP-Adressen fix vergeben werden können. Und wenn man in die Eigenschaften eines Gerätes geht, gibt es auch die sagenumwobene Wake-on-LAN-Funktion. Gut, es gibt auch eine Kindersicherung. Muss man erwähnen, dass Technik keine gute Erziehung ersetzen kann?

Erster Test: Wake-on-LAN funktioniert einwandfrei. Danke, AVM.

Manchmal, wenn zum Beispiel Twitter nicht richtig funktioniert, einzelne Bilder dort nicht erscheinen oder als defekt angezeigt werden, ist Twitter gar nicht selbst schuld, was allein schon eine Neuigkeit wäre. Nein, manchmal ist jemand schuld, von dem man das gar nicht erwartet, nämlich der Buchhändler Amazon. Genauer: Der S3-Dienst von Amazon, der derzeit einige Spirenzien macht (klicken für Großansicht):

Amazon S3 ist ein Storage-Dienst des Onlinehändlers, mit dem man zwei Dinge versucht: Einerseits die notwendigen Ressourcen des eigenen Onlinehandels sinnvoll zweitzuverwerten und zum anderen etwas vom Kuchen des Online-Storaging abzubekommen. Die Idee hinter Amazon S3 ist dabei relativ simpel, denn im Grunde genommen ist es eine Art riesiger Eimer für Inhalte, die eine Website dort ablegen und in Web-Anwendungen einbinden kann, so dass das Speichern und Übertragen dieser Inhalte nicht unmittelbar die eigenen Ressourcen belastet. Aus diesem Grund empfehlen sich solche Storage-Dienste natürlich in erster Linie für Websites, auf denen es datenverkehrstechnisch zugeht, wie an einem Taubenschlag. Twitter macht dies mit statischen Inhalten, beispielsweise den Benutzerbildchen, die nicht von einem Twitter-Server geladen werden, sondern von einem S3-Server (“s3.amazonaws.com”).

Gerade weil viele Websitebetreiber auf Amazon S3 setzen und Amazon selbst S3 als Mittel zum sicheren und hochverfügbaren Speichern von Inhalten anpreist, ist es natürlich weniger prickelnd, wenn Amazon S3 selbst ausfällt, denn dann gehen, wie es sich für klassisches Outsourcing gehört, gleich bei mehreren anderen Anbietern die Lichter aus. Das ist heute passiert, was zugegebenermaßen relativ selten passiert. Aber eben eigentlich nie passieren sollte und dürfte, wenn man an die Idee von S3 glaubt.

Was mich an meiner AVM Fritzbox 7170 wirklich stört, sind die fehlenden Analysefunktionen. Ich vermisse auf ihr einen Bereich in der Webkonfigurationsoberfläche, mit der ich beispielsweise pingen könnte. Oder einfach mal aktuell den Status der DHCP-Leases abprüfen. Alles so Dinge, die Router früher alle von Hause aus mitgebracht haben und auch die Fritzbox hinter der Webkulisse kann – wenn man bei AVM eben wollen würde, dies auch in die Weboberfläche einzubauen.

Also muss ich die Fritzbox eben aufbohren. Aktuell steht SSH und WakeOnLAN auf meiner Wunschliste und da gefällt mir der Ansatz von The Construct gut. Man nimmt einen USB-Stick, lädt dort das bereitgestellte Datenpaket hoch und erzeugt dann über die Website von The Construct ein Pseudo-Image, das dann in die Fritzbox hochgeladen wird und die gewünschten Funktionen aktiviert. Das werde ich mal am Wochenende ausprobieren.

Alternativ gibt es auch die Alternativ-Firmeware vom Freetz.org-Projekt. Allerdings vermisse ich da eine Linux-DAU-Anleitung. Die Dokumentation, die Freetz auf der Website stehen hat, ist mir für meinen Linux-Kenntnisstand eindeutig zu overloaded.

Jedes vernünftige Netzwerkgerät, das heutzutage seinen Käufer findet, unterstützt mindestens 100 MBit/s auf der Ethernet-Schnittstelle. Idealerweise auf allen, also bei Routern sowohl auf der LAN- als auch auf der WAN-Seite. Und wenn dann auch das richtige Ethernet-Kabel eingesetzt wird, schafft man sogar, dass das gesprochene Ethernet auf der Strecke tatsächlich in 100 Mbit/s formatiert ist.

Bei einem Kunden habe ich mich gewundert, dass mit seinem neuen Router auf der WAN-Schnittstelle zwar 100 MBit/s angezeigt wurde, aber nur halbduplex, obwohl fullduplex wünschenwert wäre. Der Unterschied hierbei ist, dass bei halbduplex immer gesendet oder empfangen werden kann – beispielsweise auf einem Kupferkabel, während bei fullduplex beides gleichzeitig geschehen darf, beispielsweise wenn die Anbindung über zwei Glasfaserstrecken läuft, für jede Richtung eine.

Desweiteren wunderte mich, dass der eingesetzte Router auf der WAN-Schnittstelle einen sehr bescheidenen Durchsatz brachte. Ich gab mir da sogar die Peinlichkeit, den Hersteller zu fragen, ob das wirklich so sei. Nach der Antwort kam ich mir mit den gegebenen Rahmenumständen etwas dümmlich vor.

Denn an der WAN-Schnittstelle hängt nicht einfach nur ein ADSL oder ein SDSL mit 2, 6 oder 16 Mbit/s Bandbreite – sondern eine Anbindung, die nach dem nächsten Hop am X-WiN-Backbone des Deutschen Forschungsnetz hängt und das an einem Ort, der ein zentraler Knoten im X-WiN-Backbone darstellt. Mein kleiner, süßer Router, der auch noch einen IPSec-Tunnel verwaltet und sowohl von der Marke her und auch von der Stabilität einwandfrei ist, kommt da sehr schnell aus der Puste. Er raucht nicht mal. Vermutlich schafft er das noch nicht mal, weil er dafür keine Prozessorzeit hat.

Analogisch betrachtet wäre der jetzige Zustand in etwa so, wenn ich zu einem Formel-1-Rennen zwar mit Slicks antrete, die jedoch an einem Bobbycar montiert sind.

Projektverfolgung: Sehr schnell einen kräftigeren Router besorgen.

ICANN hat heute gestern in einer Pressemeldung verkündet, dass, wie der Zufall es will, doch noch ein großer IP-Adressblock für die IP-Adressvergabe zur Verfügung steht. Genau handelt es sich um 14.0.0.0/8, also ein “Class-A”-Netzwerk. Dieses Net-14 war bislang reserviert für andere Netzwerke, die mit dem Internet verbunden werden sollten. Sprich: Uralte Historie und schon seit Jahren schlicht ein geparkter Netzblock – wie übrigens noch weitere 43 (!) Netzblöcke in der gleichen Größe, die zu Urzeiten Firmen wie IBM und Daimler-Benz (inzwischen durch ständige Weitergabe der IT-Sparte gehörig zu T-Systems) vergeben wurden und die damit weitgehend nichts anfangen.

Keine Frage: Der Umstieg auf IPv6 ist sinnvoll. Je früher der Wechsel stattfindet, desto besser für das Internet und die zukünftige Adressvergabe. Das plötzliche Finden von Net-14 aber mit dem Spruch zu kommentieren, “man habe nun wieder etwas Luft zu atmen”, ist angesichts der noch riesigen Netzblöcke, die brachliegen, etwas seltsam. Wenn jetzt jede zukünftige Pressemeldung so geschrieben wird, wenn wieder plötzlich ein neues, altes Netzwerk aus der Schublade springt, macht das die Angelegenheit sicherlich nicht wenig prekärer.

Ich habe relativ schnell gemerkt, dass mein kleiner WLAN-fähiger DSL-Router mit den gestiegenen Anforderungen eines Hausnetzwerkes so langsam überfordert ist. Am Sonntag habe ich vergeblich versucht, 3,5 Gigabyte Videorohdaten vom Notebook zum PC zu übertragen, denn der DSL-Router, der mit seinem eingebauten Switch genau dazwischensteht, stürzte nach 2 Gigabyte irgendwann einmal ab. Ich muß also zuschauen, Switching, Routing und WLAN-Bridging voneinander zu trennen. Das allein schon deshalb, weil die notwendigen Übertragungsbandbreiten im LAN eher nicht weniger werden, wenn z.B. nicht nur mir im Haushalt der flexible Zugriff auf meine Musikbibliothek gefällt.

Ich werde also zuschauen, den DSL-Splitter im Keller zu installieren und dort einen einfachen DSL-Router anzuschließen. Von dort aus geht es per Powerline-Adapter ins Wohnzimmer auf einen dortigen Switch mit WLAN-AP. Am Switch ist die Playstation und ggf. fernsehtechnisches Gedöhns angeschlossen, per WLAN-AP wird dann das Wohnzimmer WLAN-technisch versorgt und ggf. Mediengerätschaften der drahtlose Zugriff ins LAN ermöglicht. Ein weiterer Powerline-Adapter steht dann in meinem Arbeitszimmer und hinter dem zusätzlich dort installierten Switch hängt dann der PC und die Docking-Station für das Notebook.

Das könnte so gefallen, denn so habe ich als größten Vorteil den DSL-Router nicht mehr in der Mitte, weil ich ihn nicht mehr als Switch mißbrauchen muss.

Zur Zeit habe ich im Büro mit einer Internet-Anbindung eines Kunden und buchstäblich mit den Elementen zu kämpfen.

Die Anbindung ist schon von Anfang an rekordverdächtig gewesen. Hauptsächlich basiert diese Strecke nämlich auf eine G.SHDSL-Strecke mit 15 Kilometern Länge, auf der wir am Ende noch eine symmetrische Bandbreite von rund 800 Kilobit pro Sekunde haben. Allein das sind schon Werte, bei der andere Firmen und anfänglich auch der Hersteller der G.SHDSL-Gerätschaften ziemlich ins Stutzen kamen. Dennoch, das läuft.

Das größere Problem ist, dass die Leitung aus bestimmten Gründen nicht direkt beim Kunden terminieren kann und quasi die letzte Meile per Funk überbrückt werden muss. Da das rund ein Kilometer ist, machen wir das per WLAN und stark gerichteten Antennen. Auch das funktioniert soweit gut – wenn nicht gerade starker Schnefall ist oder Gemüse dazwischenwächst.

Das hat relativ naturelle Gründe: WLAN (zumindest das ältere 802.11b) sendet auf dem ISM-Band zwischen 2,4 und 2,5 Gigahertz. Dieses Band ist lizenzfrei. Und das nicht einfach so, denn hier liegt der Resonanzbereich von Wasser, weshalb beispielsweise Mikrowellenherde auch Strahlungen in genau diesen Frequenzen dazu nutzen, die tiefgefrorene Schweinehälfte warmzumachen – in dem das darinliegende Wasser in Bewegung versetzt wird. Bei WLAN möchte ich das natürlich nicht unbedingt, weshalb dazwischen liegende Bäume und alle anderen Dinge, die hauptsächlich aus Wasser bestehen, teilweise schwere Funkstörungen auslösen können.

Dazu kommt dann leider auch noch, dass die Sendeleistung eines WLAN-Senders mit 0,1 Watt (!) verschwindend gering ist, mehr Sendeleistung verstößt leider gegen Lizenzbedingungen. Der effektivste Weg wäre vermutlich, einfach einen Mikrowellenherd umzubauen und auf den Mast zu schnallen, der dann einfach alles Gemüse auf der Strecke nebenbei noch wegbrät, aber ich glaube, dagegen könnten Leute sein. Spätestens irgendwelche Straßenbauarbeiter, die in der Nähe mit dem Steiger auf Laternenmasten steigen und Birnen auswechseln wollen und nebenbei einfach so weggekocht werden.

So muss dann leider ein Ahornbaum, der ziemlich genau in der Funkstrecke wächst, demnächst kontrolliert einen Ast entbehren. (Darum wird sich natürlich ein fachlich versierter Gärtner kümmern!) Die Blätter allein sind es wohl nicht, aber nach einem Regen dauert es einige Stunden, bis die Funkstrecke merklich besser wird. Das liegt wohl daran, dass die Feuchtigkeit, die noch auf den Blättern liegt, erst verdunsten muss, bis es dann wieder läuft.

Schade irgendwie, die Lösung mit dem Mikrowellenherd hat seinen Charme…

Seit einigen Wochen habe ich der bisher eher lästigen und vor allem teuren Inhouse-Verkabelung im Privathaus mit Ethernet den Kampf angesagt und setze Powerline-Adapter nach dem HomePlug-Standard ein, die ein Netzwerk über das normale Stromnetz bilden. Und ich muss sagen: Es funktioniert absolut idiotensicher. In meinem Fall sind es zwei Powerline-Adapter von Zyxel, genau die Modelle PL-100, die noch mit einem frühen HomePlug-Standard etwa 80 Megabit/Sekunde übertragen können.

Das Installieren ist ein Einfachheit nicht zu überbieten. Auspacken und Stecker rein. Das erste Gerät im Stromnetz bildet den “Server” im Netzwerk sendet ein elektronisches Leuchtfeuer aus. So bald ein weiteres Gerät ins Netz dazukommt, empfängt es dieses Leuchtfeuer und beide bilden sofort ein Netzwerk. Die Netzwerkstruktur ist busförmig, das heißt, dass alle Geräte logisch hintereinander geschaltet sind. Die Datenübertragung selbst erfolgt durch Modulation der Information auf die Netzfrequenz, die jedoch (theoretisch) nur bis zum Stromzähler reichen soll und nicht in das öffentliche Stromnetz übergeht.

So bald mindestens zwei Powerline-Adapter ein Netzwerk gebildet haben, können an beide jeweils Netzwerkgeräte angeschlossen werden. An einem Adapter hängt mein DSL-Router, der per DHCP IP-Adressen vergibt. Am anderen mein PC, der sogleich über die Strecke auch artig seine IP-Adresse bezieht und funktioniert.

Die Bandbreite wird mit dem herkömmlichen HomePlug-Standard mit 80 Megabit pro Sekunde angegeben, das sind natürlich Laborwerte. Bei mir zu Hause mit einem nagelneuen Stromnetz ist der Durchsatz jedoch bei über 70 Megabit/Sekunde. Im Vergleich zu anderen Übertragungstechniken wie z.B. WLAN ist das ein phänomenal geringer Verlust. Eine Stufe weiter geht “HomePlug AV” mit einer theoretischen Bandbreite von 200 Megabit pro Sekunde.

Alles in allem ist HomePlug eine zuverlässige Technologie, die einem viel Verkabelungsarbeit erspart und genau die Flexibilität des normalen Stromnetzes eines Hauses liefert. Sie ersetzt durch die busförmige Topologie zwar keinesfalls ein industrielles LAN, ist aber für Netzstrukturen im privaten Umfeld eine bestechend gute Lösung.

Was mich aber wirklich überrascht, ist die absolute