Internet-Aussetzer aufspüren mit Raspberry Pi Pingtester

Bei einem Starlink-Anschluss in Verbindung mit einer FRITZ!Box 7690 traten immer wieder schwer greifbare Probleme auf: Webseiten hingen, insbesondere auf iPhones schien die Internetverbindung zeitweise weg zu sein, und kurze Zeit später funktionierte wieder alles normal.

Das Gemeine an solchen Fehlern: Wenn man vor Ort testet, läuft natürlich gerade alles einwandfrei. Ein Speedtest zeigt gute Werte und auch Starlink selbst funktioniert problemlos. Die Frage war deshalb: Wo entstehen die Aussetzer eigentlich?

Die Ausgangssituation

Der Aufbau beim betroffenen Anschluss:

Starlink Mini
     │
     │ Ethernet
     ▼
FRITZ!Box 7690
     │
     ├── WLAN → iPhones / andere Geräte
     │
     └── LAN → Raspberry Pi Pingtester

Starlink alleine funktionierte problemlos. Sobald die FRITZ!Box ins Spiel kam, wurden sporadische Hänger gemeldet. Die FRITZ!Box wurde bereits getauscht, ohne dass das Problem eindeutig verschwunden wäre. Damit kamen mehrere Ursachen infrage:

Starlink selbst
Ethernet-Verbindung zwischen Starlink und FRITZ!Box
FRITZ!Box bzw. deren WAN-Anbindung
WLAN und FRITZ!Repeater
DNS oder IPv6

Mit gelegentlichen manuellen Pings lässt sich so etwas kaum sinnvoll diagnostizieren.

Ein Raspberry Pi 2 bekommt einen neuen Job

In der Bastelkiste lag noch ein alter Raspberry Pi 2 Model B v1.1. Für einen permanenten Netzwerkmonitor reicht dessen Leistung problemlos aus. Der Pi wurde per Ethernet direkt mit der FRITZ!Box verbunden und prüft seitdem alle fünf Sekunden mehrere Stationen der Verbindung.

Überwacht werden:

FRITZ!Box       Default-Gateway
Starlink        192.168.100.1
Cloudflare      1.1.1.1
Google          8.8.8.8
HTTPS           echter HTTPS-Aufruf

Die IP-Adresse der FRITZ!Box wird automatisch über das Default-Gateway des Raspberry Pi ermittelt – damit funktioniert der Pingtester in jedem Netzwerk ohne Anpassung der Konfiguration.

Warum ein HTTPS-Test zusätzlich zum Ping?

Ein erfolgreicher Ping bedeutet noch lange nicht, dass sich das Internet für den Benutzer normal verhält. Deshalb wird zusätzlich regelmäßig eine echte HTTPS-Verbindung aufgebaut. Dafür eignet sich ein HTTP-204-Endpunkt: vollständige Verbindung inklusive TCP, TLS und HTTP, aber praktisch kein Nutzinhalt.

Damit lassen sich interessante Situationen unterscheiden:

Gateway      OK
Starlink     OK
Internet     OK
HTTPS        TIMEOUT

In einem solchen Fall wäre die grundlegende IP-Verbindung vorhanden, während ein Benutzer beim Surfen tatsächlich einen Hänger bemerken würde. Die HTTPS-Laufzeit liegt naturgemäß höher als ein einfacher Ping – bei 30–50 ms Internet-Ping waren rund 100–250 ms für den kompletten HTTPS-Test normal.

SQLite statt schwerem Monitoring-System

Die Messwerte landen in einer lokalen SQLite-Datenbank auf dem Raspberry Pi. Gespeichert werden Zeitpunkt, Ziel, Erfolg/Fehler, Antwortzeit und HTTP-Status. Die Rohdaten werden 14 Tage aufbewahrt.

Ein kleiner Python/Flask-Webserver stellt die Ergebnisse übersichtlich dar: aktueller Zustand aller Ziele, Verfügbarkeit der letzten 24 Stunden, Durchschnittslatenzen. Besonders praktisch – aufeinanderfolgende fehlgeschlagene Messungen werden zu einem Ausfallereignis zusammengefasst:

Beginn: 14:37:46
Ende:   14:40:34
Ziel:   Starlink
Dauer:  2 min 48 s

Fernzugriff über Tailscale

Da der Raspberry Pi beim Nachbarn steht, läuft auf dem Pi zusätzlich Tailscale. Eine Portfreigabe auf der FRITZ!Box ist dadurch nicht erforderlich – besonders praktisch bei Starlink und dessen Netzstruktur. Die Statusseite ist innerhalb des eigenen Tailnets einfach über die Tailscale-IP und Port 8080 erreichbar.

Ein zweiter Pingtester als Referenz

Da mein eigener Internetanschluss ebenfalls über Starlink läuft, bekam auch meine ohnehin vorhandene Tailscale-VM auf Proxmox denselben Pingtester. Damit existieren zwei voneinander unabhängige Messstationen:

Nachbar                     Eigenes Netz
   │                            │
FRITZ!Box                   FRITZ!Box
   │                            │
Starlink                    Starlink
   │                            │
Internet                    Internet

Das erwies sich als ausgesprochen hilfreich: Einzelne verlorene ICMP-Pakete zu Google oder Cloudflare tauchten auf beiden Anschlüssen auf. Bei mehr als 12.000 Messungen innerhalb eines Tages waren nur wenige einzelne Pings verloren gegangen – solche Einzelereignisse sind für die eigentliche Fehlersuche kaum relevant.

Auch der nächtliche Starlink-Reconnect wird sichtbar

Sehr schön erkennt der Monitor den regelmäßigen nächtlichen Starlink-Reconnect:

Starlink      1 min 03 s
Cloudflare    1 min 03 s
Google        1 min 03 s
HTTPS             38 s

Entscheidend dabei: Die FRITZ!Box blieb erreichbar. Damit lässt sich unmittelbar erkennen, dass das lokale LAN funktioniert und der Ausfall hinter der FRITZ!Box stattfindet. Solche bekannten nächtlichen Reconnects können bei der eigentlichen Fehlersuche ignoriert werden.

Und dann wurde ein echter Fehler erwischt

Der Pingtester zeichnete folgendes Ereignis auf:

Beginn: 14:37:46

FRITZ!Box     2 min 48 s nicht erreichbar
Starlink      2 min 48 s nicht erreichbar
Cloudflare    2 min 48 s nicht erreichbar
Google        2 min 48 s nicht erreichbar
HTTPS         2 min 25 s nicht erreichbar

Ende: 14:40:34

Das ist ein völlig anderes Fehlerbild als ein normaler Starlink-Reconnect. Der Raspberry Pi hängt per Ethernet direkt an der FRITZ!Box. Wenn selbst die lokale FRITZ!Box-IP während des Ereignisses nicht erreichbar ist, kann ein reiner Starlink-Ausfall die Ursache nicht sein. Die Fehlersuche lässt sich damit stark eingrenzen: FRITZ!Box selbst, lokale Ethernet-Verbindung oder ein lokales Netzwerkproblem müssen untersucht werden.

WLAN und FRITZ!Repeater als Kandidaten

Parallel dazu gab es Hinweise, dass insbesondere iPhones von den wahrgenommenen Hängern betroffen waren. Im Netzwerk befand sich ein FRITZ!Repeater 1200, der für mehrere Tage außer Betrieb genommen wurde. Meldet ein iPhone einen Hänger, während gleichzeitig Gateway, Starlink, Internet und HTTPS auf dem Pi einwandfrei funktionieren, lässt sich die WAN-Seite weitgehend ausschließen.

Fazit

Ein alter Raspberry Pi 2 reicht völlig aus, um aus einem diffusen „Das Internet hängt manchmal." eine technisch verwertbare Fehlerbeschreibung zu machen. Statt Vermutungen bekommt man konkrete Aussagen wie:

Um 14:37:46 fiel auch das lokale Gateway für 2 Minuten und 48 Sekunden aus.

Gerade bei sporadischen Netzwerkproblemen ist das wesentlich wertvoller als ein Speedtest, der fast zwangsläufig genau dann durchgeführt wird, wenn wieder alles funktioniert. Und nebenbei hat ein über zehn Jahre alter Raspberry Pi 2 damit noch einmal eine durchaus sinnvolle Aufgabe bekommen.

Sporadische Netzwerkprobleme, die sich nicht greifen lassen? Wir richten gern einen Pingtester ein.

Anfrage stellen

← Zurück zum Technik-Blog