Massiver und protokollunabhängiger Paketverlust im O2-Netzwerk

Hallo zusammen, 

 

Ich habe seit mindestens Mai anhaltende Probleme mit dem O2-Mobilfunkinternet zu Hause in Berlin, 10783. 
Die Verbindung hat immer wieder Teilausfälle von 30 Sekunden bis 30 Minuten und funktioniert danach für unterschiedlich lange Zeit wieder. Ein Neustart des Routers stellt die Verbindung meistens wieder her.

Ich bin damit nicht allein.

Am anfang hab ich einen O2 HomeSpot 5G SA verwendet (Hersteller MitraStar, Modell IGW-1121GX4X4-M v3). Als die Probleme auftraten, habe ich dieselbe SIM-Karte in einem alten iPhone XS genutzt. Damit gab es keine Probleme. Als Ersatz habe ich einen Zyxel 5G Outdoor Router (FWA70) bestellt, aber auch damit schien das Problem aufzutreten. Daraufhin habe ich einen Ubiquiti Dream Router 5G Max bestellt. Er kam am Montag an – leider besteht das Problem weiterhin.

Wann es genau angefangen hat, weiß ich nicht mehr. Am 12. Juni habe ich jedoch eine Störung gemeldet (Nr. S30378206) und die Rückmeldung erhalten, „dass die von Ihnen gemeldete Beeinträchtigung (Nr. S30477602) nicht durch eine technische Störung verursacht wird.“ Am Telefon wurde mir außerdem gesagt, dass es eine Störung an meiner örtlichen Mobilfunkstation gegeben habe, die gerade behoben worden sei.

Da ich die SIM-Karte als mögliche Ursache vermutete, habe ich sie im UDR durch eine eSIM ersetzt. Auch das hat nicht geholfen.

Das Fehlerbild ist ungewöhnlich: Während dieser Phasen funktionieren Pings häufig weiter, während TCP-Verbindungen in einen Timeout laufen oder beim TLS-Verbindungsaufbau beziehungsweise bei der Datenübertragung hängen bleiben. Ein Teil des UDP-Verkehrs und VPN-Tunnel funktionieren weiterhin – sowohl Cloudflare WARP auf meinem Mac als auch Tailscale direkt auf dem UDR. Google funktioniert oft noch: Die Suche lädt, aber die Seiten hinter den Suchergebnissen lassen sich nicht öffnen. Die Fehler treten auch bei Tests ohne DNS-Abfrage auf; die Namensauflösung allein kann das Problem daher nicht erklären.

Seit Juni habe ich einzelne Logs, in denen Pings durchkommen, während TCP-Verkehr ausfällt. Mit dem UDR konnte ich das nun genauer untersuchen.

Ich habe direkt vom Dream Router über O2 getestet, bei deaktiviertem VPN. APN: `internet`, IPv4, Benutzername und Passwort leer. Die Anfragen gingen an feste Zieladressen mit den passenden TLS-/HTTP-Hostnamen. Client-WLAN und DNS waren damit nicht beteiligt.

Alle folgenden Uhrzeiten beziehen sich auf den 17. September 2026, MESZ (UTC+02:00).

Messung 1 — Derselbe Netzknoten erscheint in meinen Traces (15:05 Uhr)
Beide Routen – zu Cloudflare (1.1.1.1) und Wikipedia (185.15.59.224) – enthalten 10.81.85.22 als Hop 3. Ich bin sicher, dass dort viele Leute unterwegs sind – also kein eindeutiger Beweis, aber dennoch erwähnenswert.

Inhalte anzeigen

​

Messung 2 — TCP verbindet sich, aber Webanfragen bleiben hängen (18:59 Uhr)

Zu beiden Zielen wurde die TCP-Verbindung innerhalb von 16–23 ms aufgebaut. Die gesendeten Bytes der TLS-Anfrage wurden bestätigt. Von keinem der beiden Ziele kam vor dem Verbindungs-Timeout nach 15 Sekunden eine Antwort mit TCP-Nutzdaten zurück. Auch unverschlüsseltes HTTP lief nach 20 Sekunden in einen Timeout. Der Fehler trat also auch nach erfolgreichem TCP-Verbindungsaufbau auf und war nicht auf TLS beschränkt.

Inhalte anzeigen

​

​

Messung 3 — Ping funktioniert während desselben Ausfalls (18:59 Uhr)

Alle neun gleichzeitig gesendeten Pings an Cloudflare waren erfolgreich, darunter IPv4-Pakete mit 1.500 Byte bei untersagter Fragmentierung. Eine Überwachung per Ping würde eine funktionierende Verbindung erkennen, während Webanfragen scheitern. Das unterscheidet sich von den Beispielen mit ICMP-Verlusten in diesem Thread.

Inhalte anzeigen

​

​

Messung 4 — Dieselben Anfragen funktionieren wieder (19:15 Uhr)

Dieselben Ziele lieferten nun HTTPS-Antworten innerhalb von 178–230 ms und unverschlüsselte HTTP-Antworten innerhalb von 27–46 ms. Die aufgezeichnete Mobilfunk-IP-Adresse und die Cell-ID waren unverändert. Zwischen diesen Messungen hatte sich die Verbindung erholt, ohne dass ein Wechsel der Zelle oder IP-Adresse aufgezeichnet wurde.​

Inhalte anzeigen

​

Die selektiven Ausfälle und der zeitweise hilfreiche VPN-Umweg ähneln Walfischdrecks Messungen vom Juli . Die wiederkehrenden Phasen mit funktionierender und gestörter Verbindung erinnern an ananas1111s Bericht vom August . Meine Tests scheiterten auch, als der Router fest auf LTE eingestellt war.

Könnte das Netztechnik-Team, das Walfischdrecks Fall bearbeitet hat, meinen Anschluss damit vergleichen? O2 berichtete am 16. Juli von Änderungen für LTE/5G NSA; anschließend wurde eine Verbesserung bestätigt . Bitte vergleicht meinen Ausfallzeitraum 18:59:29–18:59:49 Uhr mit der erfolgreichen Messung um 19:15:51 Uhr. Die ungekürzte IP-Adresse, SIM-Daten und den genauen Standort kann ich privat zur Verfügung stellen.

P.S.: Ursprünglich hatte ich das an einen anderen Thread angehängt, aber der war womöglich schon zu alt. Entschuldigung für die Doppelung – ich bin hier wirklich verzweifelt.
 

Ich hoffe wirklich, eine Lösung zu finden, denn 5G ist meine einzige Option – abgesehen von ADSL über einen nassen Bindfaden.