IPv6-Routing im Telekom-Netz

Bisher bin ich davon ausgegangen, dass die Telekom als ausgewachsener Carrier im Jahr 2018 bereits ausreichend Erfahrung mit IPv6 gesammelt hat. Und dass die Telekom Routing-Fehler in ihrem Netz mittels vorhandener Tools schnell und effizient beheben kann. Weit gefehlt.

Ein Kunde hatte die letzten drei Jahre als Glasfaser Internetanschluss „Company Connect 34MBit“ für 899€/Monat am laufen, inklusive IPv6 Netz in der Größe /48, was auch funktionierte.

Nun kam es dazu, dass der Anschluss zu „DeutschlandLAN Connect IP“ 100Mbit (für knapp 800€/Monat) umgeschaltet wurde. Neue Glasfaser beleuchtet, Router und Netzabschluss ausgetauscht, Routen auf die neue Schnittstelle umgeschaltet. IPv4-Netze sind nach dem Umschalten nach ein paar Minuten da, es scheint alles ok soweit. IPv6 an der WAN-Schnittstelle ist  erreichbar, sieht auch gut aus.

Nebenbei wurden die Firewalls beim Kunden hochgepatcht, weil ein Update verfügbar war.

Nun kam es jedoch, dass interne Rechner nicht mehr per IPv6 ins große weite Netz kamen, pings endeten an der Firewall. Lange doktere ich herum, verfluche die Firewall, die letztendlich unschuldig war. Pings funktionieren von A nach B, von B nach C, aber nie von A nach C. Wobei B die Firewall ist. TCPDump zeigt auch, dass Pakete rausgehen, aber nicht zurück kommen. Ich suche nach dem Fehler, warum die IPv6 Paket an der WAN-Schnittstelle gar nicht erst zu sehen sind,  während Pings, die von der Firewall selbst abgesetzt werden, einwandfrei zurück kommen. Ich bin erstmal ratlos. Von dem /48 Netz nutze ich als Transfernetz zwischen Telekom-Router und der Kunden-Firewall allerdings nur ein /64-Netz. Und genau dieses ist auch erreichbar. Es kann nur noch eine Erklärung für das Phänomen geben: Die Ursache muss extern liegen.

Alles deutet darauf hin, dass nur noch ein /64 geroutet wird, die Firewall ist außen erreichbar, nicht jedoch dahinter liegende Netze. Anruf bei der Telekom Business-Hotline. Der Mitarbeiter bestätigt, dass irgendetwas faul ist, ich soll den Fall per Email schildern. Schreibe Email an die Telekom mit detaillierter Beschreibung.

Sehr geehrte Damen und Herren,

wir bitten um Überprüfung der IPv6-Konnektivität auf dem /48-Netz [2003:58:802A:0:0:0:0:0].
Seit Umstellung der Leitung auf DeutschlandLAN Connect IP kann nur noch das /64 Netz (z.B. [2003:58:802A::8] erreicht werden. „Dahinter“ liegende Netze werden ab Router [2003:0:8400:e800::1] nicht weiter geleitet.
Zum Testen läuft IP:[2003:58:802A:2:250:56af:fea7:8e7c], welcher per ICMPv6 erreichbar sein sollte.

Es folgt gegen 17:30 Uhr ein Anruf der Business-Hotline. Der Mitarbeiter gibt zu Wort, dass das Problem in der Tat so bestätigt werden kann. Leider könne er die Routen derzeit nicht korrigieren, da die benötigten Tools (noch) nicht zu Verfügung ständen. Wir sollten eine Änderungsauftrag über den entsprechenden Vertriebsmitarbeiter eingeben.

Ich schicke die Email mit erweiterter Erklärung an unseren Vertrieb’ler und seinen Mitarbeiter im Office. Mir schwant schon, dass das eine längere Sache wird, da ich von Vertrieb’lern bisher wenig zufriedenstellende Antworten bekommen habe. Die Antwort kommt prompt in Form einer fehladressierten Emaill, die eigentlich an den Vertrieb’er gehen sollte:

Hallo Cheffe,

ist dir bekannt, was hier zu tun ist?
So ein Thema hatte ich noch nicht.

Da IPv6 glücklicherweise nicht geschäftskritisch ist und die IPv4-Netze funktionieren, lasse ich dem Vertrieb freundliche drei Tage Zeit, bis ich per Anruf nachharke. Der Vertriebsmitarbeiter, hörbar bemüht, möchte seinerseits nachharken. Mich erreicht eine Information, die „IP-Adressänderung sei über den Innendienst angewiesen“.
<zyn on>Wie ab die doch gehen.<zyn off>

Fünf Tage später ist alles noch beim Alten. Zur Abwechslung rufe ich wieder die Business-Hotline an. Die Dame am andere Ende der Leitung ruft sich den Fall auf und entscheidet sofort, die Angelegenheit an ihren Kollegen weitergeben zu müssen, er wird sind melden.
Am nächsten Tag erreicht mich morgens folgende Email:

bei der Übernahme von Company Connect (CoCo) auf Deutschland LAN IP (DCIP) ist auf dem RD eine statische Route vergessen worden.
Diese Route wurde nun im RD-Profil zugefügt.

Sollten Sie in einer verkehrs-schwachen-Zeit Ihren RD neu starten, sollte die IPv6-Connectivity wie gewohnt funktionieren.

Ich möchte Sie jedoch bitten, sich an Ihren vertrieblichen Ansprechpartner zu wenden und über ihn, einen Korrekturauftrag (IP-Adressauftrag einzustellen).

Ich wünsche Ihnen noch eine angenehme Restwoche und verbleibe mit freundlichen Grüßen

Aha, aha. Professionell wurden Abkürzungen für die Produktnamen in Klammern eingefügt (wozu?), aber RD nicht erklärt. Glücklicherweise ist aus dem Kontext ableitbar, dass es sich um unseren Telekom-Router handeln muss. Aber was um Himmels willen soll ich mit dem letzten Absatz anfangen? Klappt’s nun, wenn die den Router neu starte, oder soll ich nun wiederholt einen IP-Korrekturauftrag an den vertrieblichen Ansprechpartner stellen? Und wenn ja, warum?

Ich wähle wieder die Hotline-Nummer. Wer logisch inkonsistente Informationen sendet, darf sich gerne erklären.
Der Mitarbeiter am Telefon ist gleich im Bilde – noch bevor ich unsere Kundennummer nennen darf. Ich bin verblüfft. Üblicherweise darf ich erstmal alles erklären, unsere Kundennummer nennen, ggf. ein Password und noch eine Leitungsbezeichnung, um dann drei mal hin- und herverbunden zu werden und stets die selbe „Geschichte“ von Neuem zu erzählen. Und dieser Mitarbeiter weiß sofort bescheid.
Ich frage nach dem tieferen Sinn, speziell des letzten Absatzes in der letzten Email. Er bestätigt, dass man das nicht so ganz verstehen kann. Aber letzten Endes müsse diese „quick&dirty“-Änderung noch dokumentiert werden, und dafür sei wiederum der Vertrieb zuständig. Ich erspare ihm meine Frage, warum ICH das nun machen solle, denn die Antwort kann ja eigentlich nur lauten: „weil wir’s einfach nicht drauf haben“.
Ich erkundige mich allerdings noch danach, ob die Änderung in unserem Telekom-Router ausreiche, da meine Diagnose darauf hindeute, dass die Route auch im tiefer liegenden Netz korrigiert werden müsse. Die Antwort fällt wie erwartet aus: „Das sehe man ja dann, wenn es immer noch nicht funktioniere“.

Für 21 Uhr habe ich von entfernt über das Outlet-Segment der USV, an welcher der Router hängt, einen Hard-Reset programmiert. Nachdem die Internetverbindung wieder online war, funktionierte IPv6 tatsächlich wieder im kompletten /48-Raum.

Ritto over IP

Es war schon lange ein Wunsch von mir, darüber informiert zu werden, wenn der Postbote geklingelt hat. Bzw. wenn er nicht geklingelt hat.

Die Lösung zu dieser Aufgabe konnte ich nun endlich durch Vorarbeit anderer Bastler und Dokumentierer  fertig stellen: Ein ausgefeilter Hack der Ritto Türsprechanlage, der das Klingelsignal abgreift, per WLAN an MQTT meldet und auf dem Rückweg  obendrein noch ermöglicht, den Türöffner von entfernt zu betätigen. Wie geil ist das eigentlich?

Bei dem bei uns verbauten Modell handelt es sich um ein Ritto Wohntelefon Twinbus 7630. Vermutlich wird der Eingriff jedoch auch bei ähnlichen Modellen funktionieren. Im Notfall kann man den Pins einfach mal mit dem Multimeter auf die Pelle rücken und  nachmessen, ob sich spannungsmäßig etwas tut, wenn man klingelt.

Die Weiterentwicklung gegenüber der „Version“ meines Vorgängers besteht hauptsächtlich darin, dass dieses Modul nun auch von der Gesamtanlage gespeist wird, d.h. es ist keine weitere Stromversorgung notwendig. Wer würde auch sonst eine extra Leitung zum „Wohntelefon“ (was ein däml…. Name *Anm. d. Red.) legen, der Aufwand rentiert in den meisten Fällen schlicht nicht. Und Batteriebetrieb fällt sowieso schon mal ganz aus, es sei denn, man hat den seltenen Hang zum permaneten Akkuwechsel.
Das ESP-Modul samt Anhang über den Twinbus „schmarotzenderweise“ zu speisen ist im Übrigen wieder mal eine Angelegenheit der Kategorie „nicht trivial„. Wie in vielen Foren zu lesen ist, ist das gesamte Twinbus-System ziemlich zimperlich, was Eingriffe angeht und alles andere als robust. Die ganzen Warnungen, tunlichst die Finger davon zu lassen, es sei denn, man sei darauf aus, die Gegensprechanlage für das gesamte Haus lahm zu legen (inkl. der Kosten für den Technikereinsatz danach) rief selbstverständlich meine Neugierde auf den Plan. Die Platine bietet 24V an Kontakt Nr.5, das NodeMCU Board braucht 5V. Also braucht’s einen Spannungsregler. Testweise habe ich erst mal einen dumpfen 7805 genommen, der den Spannungsabfall einfach in Wärme verbrät.

Spannungregler 7805

Der wurde aber auch wegen der hohen Differenz von 19V bei den maximal 260mA ordentlich heiß. Hätte funktioniert, aber mangels Konvektionsmöglichkeit habe ich davon abgesehen. Außerdem bin ich auch nicht der Typ, der den Bug zum Feature macht alla „Hey, unser Wohntelefon hat noch eine Fingerwärmfunktion“.
Probiert habe ich also noch einen DC-DC Wandler (TracoPower TSR 1-2450 24 V/DC 5 V/DC 1 A 6 W), der mit der Anlage nicht funktionierte, aber der Zweite tut seine Arbeit perfekt. Es ist ein „FISM Fixed Isolated Modul“ (Würth Elektronik 177920531 24 V 5 V 0.2 A 1 W), macht zwar dauerhaft nur 200mA mit, aber für 5 Sekunden auch 300mA und sollte damit für die Stromspitzen ausreichen.

DC/DC Wandler

Davon abgesehen sollte ein obligatorischer Kondensator auch die Spitzen abfangen. Das Teil ist nun auch schon ein Jahr in Betrieb und funktioniert tadellos, nicht mal der Prozessor ESP8266 ist abgeschmiert.

Zur Übertragung des Klingelsignals ins WLAN habe ich mich für ein NodeMCU entschieden, da ich damit „quick & dirty“ schnell zum Ziel komme.

NodeMCU mit ESP12

Es gibt auch elegantere oder schlankere Lösungen.

Heute würde ich nur noch ein ESP12F-Modul nehmen und gleich einen 24V->3,3V DC/DC Wandler davor setzen.

ESP12F mit ESP8266

Ein ESP12 hat halt keine Spannungswandlung, keinen Serial-zu-USB-Chip (UART) und auch keine Flash-Logik. Diese Funktionen sind auf dem NodeMCU-Board „drumrum“ gebaut und erleichtern den Einstieg. Durch seine Verwendung kann ich zukünftig wesentlich einfacher Updates über die USB-Schnittstelle einspielen, sollte mal beim OTA-Update (über WLAN) etwas schief laufen.

Wemos D1 mini

Die selbe Funktionalität bietet übrigens auch ein Weemos D1-Board, falls das jemand noch nicht kennt.

Zur Ritto-Platine zurück: Mitte oben befindet sich die 24V Speisespannung für das WLAN-Modul und am Pin in der Mitte das Klingelsignal. Wenn jemand die Klingel betätigt, liegen dort 5 Volt an, die man auswerten kann. Der linke der drei Pins in Ground.

Unten rechts befinden sich die beiden Kontakte um den Türöffner zu betätigen. Diese kann man mit einem CMOS 4066, eine Art elektronisches Relais, durchschalten. Das kommt dem Tastendruck am Gerät gleich.

Umgekehrt funktioniert das Durchschalten per CMOS4066 zum ESP3266 leider nicht, da die Schaltzustände bei dieser elektronischen Variante sich nur in einer größeren Änderung des Widerstands unterscheiden. D.h. bei „aus“ ist beim 4066 der  Widerstand nicht unendlich und bei „ein“ ist der Widerstand nicht gleich Null. Welchen Wert diese Widerstände haben, hängt mit der Speisespannung zusammen und ist nicht linear. Also muss eine andere Möglichkeit her, um den GPIO Pin zu schalten.

Diese Aufgabe kann man per Transistor bewältigen, indem man D2 auf Ground bzw. Low Level zieht. Wenn am Klingelkontakt die 5 V anliegen, wird der Transistor leitend und welchselt am  GPIO D2 den Level. Ich habe einen BC547B genommen, aber ich gehe davon aus, dass auch sonst fast jeder übliche NPN-Transistor funktioniert. Davor ist zum Kingelkontakt ein 1 kΩ Widerstand.

Zur Stabilisierung und Entstörung habe ich noch einen 470 μF Kondensator hinter den DC-DC Wandler gehängt.

Die Schaltung kurz aufskizziert:

Der Versuchsaufbau auf dem Breadboard sieht folgendermaßen aus:

… und zum Testen muss die Schaltung natürlich auch an die Anlage:

Was bisher fehlt, ist die Software. Ich habe mich für die Firmware „Tasmota“ von Theo Arends entschieden.

 

Selbstverständlich kann man mit ein paar Bibliotheken relativ schnell selbst etwas zusammenschustern, aber das Angebot von Theo hat alles an Board, was man benötigt. Wer im ersten Step (noch) keine Lust auf das volle Paket mit MQTT und Node-Red hat, der kann den Türöffner erst mal nur über das Webfrontend steuern, welches sogar „responsive designt“ ist und damit auch auf dem Smartphone schlank aussieht.

Das gesamte Konstrukt vom Breadboard habe ich, nach Versicherung dass auch alles funktioniert, schlicht auf einer Lochrasterplatine  eingelötet. Bei einer nächsten Version würde ich vielleicht eine extra Platine fertigen lassen, aber es funktioniert auch so einwandfrei.

Richtig interessant wird die Sache, wenn man sich nun noch einen MQTT-Server mit z.B. Node-Red gönnt. Zugegebenermaßen ist das alles am Anfang natürlich etwas viel, aber mancher Bastler hat ja schon einen Teil der Infrastruktur zu Hause. Und MQTT ist nun wirklich nicht die Hürde. Es ist mit „apt-get install mosquitto“ ruckzuck auf Debian installiert und funktioniert danach einfach nur noch. -> Ja, der Satz ist zu Ende.  Es tut was es soll und ist wartungsarm.
Als Server(-hardware) nutze ist selbst (aus Performancegründen) einen Intel NUC5CPYH, weil er einen AES-NI Chip und ausreichend Power/RAM hat, um immer alles „schnell mal noch“ drauf zu packen. Wer bereit ist, mehr mit Ressourcen zu haushalten kann auf den doch wesentlich günstigeren Raspberry 3b zurück greifen. Ein Einrichtungstutorial ist hier. Für die Einrichtung von Node-Red mit node.js unter Debian empfehle ich diese Anleitung. Zusätzliche Hinweise wegen dem begrenzten Arbeitsspeicher auf dem Raspberry Pi finden sich in diesen Artikel von Markus Ulsass.

Um letztendlich über das eigentliche Klingeln an der Tür benachrichtigt zu werden setze ich den Dienst Pushover, aufsetzend auf Node-Red, ein.

Da das ausführliche Beschreiben aller beteiligten Komponenten über die Hardware hinaus diesen Artikel sprengen würde, habe ich oben die wichtigsten Punkte gegen aussagekräftige Hilfeseiten verlinkt. Ich wünsche somit viel Spaß bei Nachbauen und freue mich auch über Feedback oder Verbesserungsvorschläge.

WLAN Probleme mit der Fritzbox 7590

Die neue AVM Fritzbox 7590 hat derzeit in einigen Fällen Probleme mit dem WLAN. Bei mir ist es das 2,4 GHz Band. Kein Gerät kann sich damit verbinden. Alle Versuche sind bei mir gescheitert, trotz Umbennen der SSID oder Wechsel des Passworts.

Auch fällt auf, dass man bei abgeschaltetem 5GHz-Band den Kanal im 2,4GHz-Band nicht verstellen kann, aber im (abgeschalteten!) 5GHz-Band. Ergibt irgendwie keine Sinn, oder?

Der Support von AVM bestätigt das Problem und fordert Logs an, ich warte auf Lösung.

Auch die Übernahme der Konfiguration aus der 7490 war ein steiniger Weg: Die 7590 wird ab Werk mit älterer Firmware ausgeliefert. Da die alte 7490 jedoch bereits den Stand 06.93 hat und diese Firmware offizielle für die neue 7590 noch gar nicht verfügbar ist, versagt der Konfigurations-Import im neuen Modell. Zuerst muss die neue 7590 mit der manuell heruntergeladenen FRITZ!OS 06.93-49653 BETA hochgepatcht werden, damit der Konfigurationsimport überhaupt funktioniert. Das hätte man besser lösen können, indem man entweder das Firmware-Update für das ältere Modell zurückhält, oder den Importer in der Neuen derart anpasst, dass er auch die ältere Konfig verdauen kann.

Update:
Nach einem weiteren Konfigurations-Übernahmeversuch funktioniert das 2,4GHz WLAN nun endlich. Bei diesem zweiten Export (Sichern) der Einstellungen von der Fraitzbox 7490 habe ich zuvor die SSID’s beider WLAN-Bäder gleich (um-) benannt. D.h. nach dem Import in die neue Fritzbox 7590 sind nun von anfang an die SSID’s gleich und das WLAN funktionierte sofort, ebenso wie die Kanalauswahl. Ansonsten war der gesamte Ablauf (Sichern, Wiederherstellen) exakt der Selbe wie beim ersten Mal.
Da bei den letzten Firmware-Versionen besonders viele Änderungen im WLAN-Mesh implementiert wurden, gehe ich davon aus, dass beim Import ungleicher SSID’s der Fehler zu suchen ist.

Update 2:
Auch ein importierter VPN-Zugang macht Probleme:
Der VPN-Zugang vom Smartphone zum Heimnetz funktioniert nur eingeschränkt. Die VPN-Verbindung zur Fritzbox 7590 wird zwar hergestellt und der Zugriff auf einige interne Geräte funktioniert auch. Ominöserweise funktioniert jedoch der Zugriff auf den Debian-Server auf allen Diensten und Ports nicht.
Das Fehlerbild hinterlässt Fragezeichen. Tcpdump zeigt auf dem Debian-Server Datenpakete an, die vom Smartphone per VPN gesendet werden, jedoch kommen die Rückläufer beim Smartphone nicht an. Also muss es an der Fritzbox liegen.
Nach Entfernen und dem Neuanlegen des entsprechenden VPN-Zugangs funktioniert auch der Zugriff auf den Debian Server wieder wie gewohnt. Wie ist das Ganze eigentlich zu erklären? Warum „schluckte“ die Fritzbox Datenpakete vom Debian-Server, während sie die Pakete von z.B. ESP8288-Modulen einwandfrei durchließ?