End2End ESP

Wie vermutlich viele andere Personen bin auch ich überwiegend aus dem Home Office aktiv und nutze eine lokale Internetanbindung. Bei mir ist es mittlerweile ein FTTH-Anschluss (Glasfaser in Hövelhof) aber davor war es ein DS-Anschluss. Ich bin allerdings nicht der einzige Nutzer und würde schon gerne wissen, wie gut meine Verbindung ist und ob noch alle interessanten Gegenstellen erreichbar sind. Anstatt nun ein PowerShell oder C#-Programm zu schreiben, habe ich meine IoT-Kenntnisse zusammengefasst und einen kleinen Helfer programmiert.

Dieses Projekt ist noch nicht fertig. Ich hoffe mal auf einen Hackathon, längere Ferien o.ä.

Die Überlegung

Wenn Sie Bausteine wie den ESP8266 oder ESP32 mit einer Kette von WS2812-LEDs verschalten, kann der Baustein statisch hinterlegte Gegenstellen abprüfen und deren Status anzeigen. Ich denke an die gleiche Kette wie beim End2End ClientCheck. Dazu muss das gerät natürlich sich im WLAN befinden und ab und an einige Checks durchführen. Jeder Check kann als eigene LED dargestellt werden im Idealfall sind alle LEDs dann grün.

LEDs und Bedeutung

Von Adafruit und anderen Herstellern gibt es fertige LED-Streifen mit WS2812-LEDs, die über einen einzigen Ping angesteuert werden. Jede LED kann die drei Farben (RGB) mit 0-255 Helligkeit ausgeben. Theoretisch sind also viele Farben möglich. Ich habe jeder LED erst einmal eine konkrete Funktion zugewiesen, und wenn alles in Ordnung ist, sollten alle LEDs grün leuchten.

LED Check Beschreibung
1

WLAN verbunden

Diese LED ist grün, wenn die Verbindung zum WLAN besteht. Sie blinkt/leuchtet rot, wenn die Verbindung versucht wird. Die "Verbindung" kann man erkenne, dass der Client ein Default Gateway bekommen hat. Zusätzlich könnte eine farbliche Kennzeichnung anhand der Empfangsstärke passen..

2

Ping zum Default Router

Der nächste Test überprüft sowohl die Erreichbarkeit des Default Gateway als auch die die Antwortzeit. Bei LAN und WLAN sollten hier <10ms immer erreichbar sein und Werte drüber dann Gelb anzeigen. Rot zeigt, dass der Ping nicht innerhalb einer Sekunden beantwortet wurde.

3

Ping zur ersten öffentlichen IP

Mit dem Test wird über ein Traceroute versucht die erste öffentliche IP-Adresse oder CGN-Adresse zu ermitteln. Eine Antwort von diesem System ist quasi die Bestätigung , dass die Außenverbindung zum nächsten Hop besteht.

4

Ping zu www.msftconnecttest.com

Den Test nutzt z.B. auch der Internet Explorer um die generelle Verbindung "zum Internet" zu prüfen. dahinter stehen wohl einige geografisch verteilte Server von Microsoft, die per ICMP antworten.

Zudem kann man auch einen Request auf "http://www.msftconnecttest.com/connecttest.txt" (Unverschlüsselt) machen, und den Content auf "Microsoft Connect Test" prüfen und so zumindest eine Verbindung zum Microsoft Netzwerk zu verifizieren.

5

google.de

Mit Google haben wir sicher eine große Suchmaschine, die von vielen Personen genutzt wird. Eine Abfragen von "http://google.de/favicon.ico" prüft die Verbindung

6

youtube.com

Dahinter steckt zwar auch Google, aber es sind sicher andere Server. Eine Abfrage der Url "Invoke-WebRequest https://youtube.com/favicon.ico" kann die Erreichbarkeit prüfen.

7

office365.com/outlook.com

Auch Privatanwender nutzen Outlook.com, OneDrive etc. Die Erreichbarkeit der Dienste kann man schon mal testen

8

UDP zu TURN-Server

Das gilt erst recht für die Media Relay von Microsoft Teams

nn

weitere

Die Anzahl der Tests ist eigentlich nur durch die LEDs in der Kette beschränkt. Gerade für Firmen könnte es interessant sein, auch Zugänge zu VPN-Servern, Terminal-Gateways, weitere genutzt Cloudanbieter (Datev- SAP etc.) zu überwachen und damit dem Anwender eine schnelle Selbstdiagnose anzubieten.

Durch den Einsatz von WS2812-LEDs (Siehe LEDs und WS2812) kann jede LED unterschiedliche Farben annehmen. Hier orientiere ich mich am Ampelprinzip mit ein paar Zusatzfarben:

Farbe Bemerkung

Grün

Der entsprechende Check ist erfolgreich und die Antwortzeit im Rahmen

Gelb

Der Check ist erfolgreich und die Antwortzeit aber etwas langsam

Rot

Die Antwort hat nu nun definitiv zu lange gedauert oder kam gar nicht. Der Test zählt als "failed".

Blau

Der Check ist angehalten, da er von einem vorherigen Check abhängig ist, der aber schon "Failed" ist. Wenn z.B. die WLAN-Verbindung nicht steht oder die Internet-Verbindung nicht da ist, dann macht es es ja keinen Sinn, die nachfolgenden Tests auszuführen, Zeit zu verschwenden und letztlich auch nur ein "Rot" anzuzeigen.

Weiss

In dem Fall steht das Programm und gibt den numerischen Fehler (1-255) als Binärcode aus.

Aus

Es ist kein Test konfiguriert

Denkbar ist natürlich auch ein Übergang von Grün nach Gelb u.a. und auch die Helligkeit könnte man verwenden, um die Ergebnisse in Farben abzubilden und langsam verblassen zu lassen. Jede Messung addiert auf die entsprechende Farb-LED einen Wert und nach jedem Durchlauf werden alle Werte halbiert oder um einen Festwert reduziert.

Entwicklungsstufen

Anstatt gleich alles zu wollen, habe ich mir mehrere Stufen geplant:

Stufe Beschreibung

Basismodell

Das ist einfach nur ein ESP8266/ESP32 beliebiger Bauart, der mit im Code hinterlegten Zugangsdaten zum WLAN und vorgegeben Prüfungen eine WS2812-LED-Leiste ansteuert.

WPS

Um es für den Heimeinsatz einfacher zu machen, sollte im zweiten Schritt die Unterstützung für WPS dazu kommen. Dazu muss der ESP8266/ESP32 entweder eine Taste haben oder er versucht beim Start sich mit dem letzten Netz zu verbinden und wenn das nicht klappt, startet er einen WPS-Versuch.

Reporting

Wie wäre es, wenn die kleine Box ihre Ergebnisse nicht nur lokal als LED ausgibt, sondern "verbreitet". Sie könnte die Ergebnisse an einen MQTT-Server, als UDP-Broadcast, an einen WebService (z.B. PRTG oder Incinga) o.ä. senen

Konfiguration

Damit eine Veränderung der Prüfungen nicht nur per Änderungen am Code möglich ist, könnte das System die Konfiguration z.B. von einem Webserver oder ebenfalls per MQTT bekommen. Die MAC-Adresse ist ja durchaus als "Seriennummer" verwendbar. Der Service könnte in der Cloud oder auch im LAN stehen

UPnP-Query

Gerade die "Homerouter" wie eine Fritz!Box erlauben weitere Abfragen zur externen Verbindung per UPNP, z.B. DSL-Qualitätsinformationen.

Enterprise Monitoring

Für Firmen könnte es sogar interessant sein, die Ergebnisse am Ende an ein Enterprise-Monitoring zu senden, z.B.: per PRTG - HTTP Push-Sensor oder NRDP o.a

 

Es geht noch mehr

Genau genommen könnte die kleine Box noch viel mehr Daten sammeln, die dann aber nicht mehr per LEDs angezeigt werden können.

- Ping Default Gateway (<10ms ok, <50ms >50ms bad/not reachable)
- check ARP-Entry of the default gateway. Visible ?
- ICMP Traceroute1: Distace to first "non private IP" (Public or CGN) 
- ICMP Traceroute2: Distace to first "public IP" 
- ICMP Traceroute3 to MSConnectiontest
- UDP3478 TTL-Check
- Collect ttl to "breakout"
- Collect Latency to Breakout or Proxy (internal traffic)
- Enumerate other WLAN-SSIDs around

Aber die Daten könnte die Box an ein Display o.ä. melden oder eine Smartphone-App im gleichen Haus, die bei "Störungen" auch bescheid sagen kann. Also Firma könnte man dieses Gerät auch nutzen, um die Ergebnisse an eine zentrale Plattform zu melden und damit einen "Überblick" über Verbindungsprobleme zu erhalten. Die Herausforderung dabei ist aber ein Traceroute, um den Hop hinter dem DSL-Router zu erwischen.

Konfiguration

Ich habe keine umfangreiche Konfigurationsoberfläche gebaut. Es gibt ja viele Module, um z.B. einen "WiFiManager" einzubinden aber letztlich müssen Sie schon irgendwo die Checks abrufen und umsetzen. Daher veröffentliche ich den Sourcecode und definiere die Prüfungen am Anfang. Wer etwas programmiert, solle kein Problem mit einer Anpassung haben.

Leider gibt es anscheinend kein Traceroute beim ESP8266 und auch die Auswertung eines ICMP_NOT_REACHABLE ist wohl nicht vorgesehen. Daher kann ich keine "Plug'nPlay"-Konfiguration eines Pings entlang des Pfades automatisch einrichten. Das ist aber auch gar nicht möglich, das gerade Cloud-Dienste ihre eigenen Anbindungen haben und sich die Wege nach wenigen Hops schon auftrennen.

Interessant ist schon der erste Hop zu ihrem WLAN-Router und dann der erster Hop über die DSL-Verbindung und der Weg vom Provider raus. Hier sind Engstellen bei schlechter Qualität oder vielen "Mitsurfern" zu erwarten.

Weitere Links