Skip to main content
Warum O2
Warenkorb
 Service
Frage

Massiver und protokollunabhängiger Paketverlust im O2-Netzwerk

  • November 17, 2025
  • 40 Antworten
  • 611 Aufrufe
Kompletten Beitrag anzeigen

40 Antworten

Besucher:in

Hallo ​@o2_Matze, danke für deine Rückmeldung und fürs Weitergeben an die IT. 🙂

Ich kann die Verbesserung für meinen Anschluss bestätigen. Seit dem Nachmittag des 16.07. ist das frühere ziel- und verbindungsabhängige Fehlerbild im laufenden Router-Monitoring nicht mehr aufgetreten.

Zur Kontrolle habe ich den nativen o2-Pfad unter Umgehung meines Tunnels getestet. Die Routing-Ausnahme habe ich per Traceroute geprüft. Bei 30 aufeinanderfolgenden TCP-Verbindungen zu 1.0.0.1:443 gab es weder auffällige Verzögerungen noch Timeouts. Ein nativer Test mit 100 Pings zu 9.9.9.9 blieb ohne Verlust. Das frühere Fehlerbild ließ sich dabei nicht reproduzieren. Der Tunnel ist inzwischen deaktiviert. Auch mein regulärer Datenverkehr läuft wieder nativ über o2.

Außerdem zeigen meine Messungen zwei Veränderungen: Die nach außen sichtbare IPv4 stammt seit dem 16.07. aus einem anderen Adressbereich (46.114.x statt zuvor 176.7.x), und im Traceroute sind auf dem getesteten nativen Pfad keine o2-internen Hops mehr erkennbar. Welche interne Änderung dahintersteht, geht daraus nicht hervor.

5G SA habe ich entsprechend eurer Empfehlung am Modem deaktiviert. Derzeit ist das Modem über 5G NSA verbunden, mit LTE-Band 3 als Anker und n78 als 5G-Träger.

Vielen Dank auch an alle Beteiligten im Hintergrund für die Unterstützung. Das Monitoring lasse ich erstmal weiterlaufen und melde mich, falls das Fehlerbild erneut auftritt.

Viele Grüße

    o2_Matze
    • o2_MatzeModerator
    • Moderator
    • July 22, 2026

    Hi ​@Walfischdreck 

    Super, das sind doch großartige Nachrichten \o/ 

    Vielen Dank auch an alle Beteiligten im Hintergrund für die Unterstützung.

    Den Dank leite ich gerne weiter (ich glaube die Kollegen lesen hier aber eh heimlich mit 😄)

    Das Monitoring lasse ich erstmal weiterlaufen und melde mich, falls das Fehlerbild erneut auftritt.

    Das klingt nach einem guten Plan, sollte also noch was auffälliges in den Logs aufploppen ping uns hier einfach an. 

    VG Matze 

    „Was Du mit guter Laune tust, fällt Dir nicht schwer.“- ungarische Weisheit
      Einsteiger:in
      Forum|alt.badge.img
      • ananas1111
      • Einsteiger:in
      • August 11, 2026

      Hallo ​@o2_Matze 

      Es sieht so aus, als hätte ich wieder dasselbe Problem. 

      Die Probleme liegen wohl wieder bei 10.81.85.22 und vermutlich spätestens seit gestern Nachmittag ;( 

      Die folgende Screenshot ist eine Beispiel gegen 8 Uhr am 11.08.  Es wäre gut, wenn du die Technik-Team noch einmal informierst. Ich nutze gerade 5G NSA und bin in NRW.

       

      The_Voice_70
      Legende
      Forum|alt.badge.img+31
      • The_Voice_70Legende
      • Legende
      • August 11, 2026

      ​@ananas1111 

      Wo exakt in NRW ?

      Erster Vertrag: Alice Fun Max Flat analog (11.04.2008), Alice Homebox Wlan 1231 (rot), o2 my Service - Hilfe zur Selbsthilfe: https://www.youtube.com/@o2de. Dir hat eine Antwort weitergeholfen? Prima, dann markiere diese bitte als "Beste Antwort", damit auch andere davon profitieren.
      Einsteiger:in
      Forum|alt.badge.img
      • ananas1111
      • Einsteiger:in
      • August 11, 2026

      ​@The_Voice_70 Aachen

      o2_Matze
      • o2_MatzeModerator
      • Moderator
      • August 11, 2026

      ​@ananas1111 Vielen Dank für deine Meldung. Das ganze ist heute plötzlich aufgetreten?  Besteht der Fehler weiterhin, oder war das ganze nur ein temporärer Schluckauf heute Vormittag? 

      VG Matze 

      „Was Du mit guter Laune tust, fällt Dir nicht schwer.“- ungarische Weisheit
        Einsteiger:in
        Forum|alt.badge.img
        • ananas1111
        • Einsteiger:in
        • August 11, 2026

        ​@o2_Matze Hi, es ist gut möglich, dass es immer wieder zu Problemen kommt, aber seit gestern hat sich das Problem deutlich verschlimmert. Es kommt immer wieder zu Paketverlusten von deutlich über 80 %.

        Momentan besteht das Problem weiterhin und es scheint, als würde es jetzt über MegaIX statt DE-CIX laufen. Der Paketverlust liegt aktuell bei etwa 50 %, siehe Screenshot:

         

        o2_Matze
        • o2_MatzeModerator
        • Moderator
        • August 11, 2026

        ​@ananas1111 Wir geben es gerne an die Fachabteilung zur Prüfung weiter. Kannst du noch kurz was zur verwendeten Hardware sagen, der Vollständigkeit halber will die Netztechnik auch immer was zu den Hintergründen wissen, also wo tritt der Fehler auf (an deiner Kontaktadresse?) und welche Hardware wird verwendet und bist du im 4G oder 5G Netz eingebucht und gibt es Unterschiede beim Fehler, je nachdem in welchem Netz du eingebucht bist?

        VG Matze  

        „Was Du mit guter Laune tust, fällt Dir nicht schwer.“- ungarische Weisheit
          Einsteiger:in
          Forum|alt.badge.img
          • ananas1111
          • Einsteiger:in
          • August 11, 2026

          ​@o2_Matze 

          vielen Dank für deine Rückmeldung. Zur Hardware: Ich nutze eine Banana Pi R3 Mini mit einem Foxconn T99W175 WWAN-Modul (Qualcomm) sowie ein TCL-Tablet (MTK) mit 5G SA. Ich habe alle möglichen Modi (4G/5G NSA/SA) ausprobiert, aber das macht gar keinen Unterschied. Deswegen denke ich, dass das Problem sehr wahrscheinlich am O2-Backbone liegt.

          Und ja, der aktuelle Betriebsort ist genau an meiner Kontaktadresse. Sag einfach Bescheid, was ich noch testen soll. 

          Viele Grüße

            o2_Matze
            • o2_MatzeModerator
            • Moderator
            • August 11, 2026

            ​@ananas1111 Vielen Dank für die Infos. Wir nehmen ein Fehlerticket dazu auf und adressieren das an die Netztechnik, das ganze ist aber immer hoch komplex, daher vermag ich nicht zu sagen wie schnell hier die Fachabteilung aktiv werden kann, wir sind aber guter Dinge, das wir hier auch wie bei ​@Walfischdreck eine Lösung finden werden.

            VG Matze 

            „Was Du mit guter Laune tust, fällt Dir nicht schwer.“- ungarische Weisheit
              o2_Matze
              • o2_MatzeModerator
              • Moderator
              • August 14, 2026

              ​@ananas1111 Die Technik konnte im ersten Step den Fehler noch nicht lokalisieren, wir bleiben da aber am Ball und sind da hinter den Kulissen weiter für dich aktiv.

              VG Matze 

              „Was Du mit guter Laune tust, fällt Dir nicht schwer.“- ungarische Weisheit
                Einsteiger:in
                Forum|alt.badge.img
                • ananas1111
                • Einsteiger:in
                • August 14, 2026

                ​@o2_Matze Vielen Dank für deine Rückmeldung. 

                Ich möchte noch einmal ein sehr spezifisches Detail im MTR-Muster hervorheben, das mir bei der Analyse aufgefallen ist und das hoffentlich bei der internen Fehlersuche hilft:

                Der Paketverlust tritt nicht gleichmäßig (wie bei einer einfachen Überlastung) auf, sondern zeigt ein strikt phasenweises / blockweises Verhalten (Black-Hole-Flapping):

                - Phase A: Für ca. 10–30 Sekunden gehen alle Pakete mit perfekter Latenz durch (...).
                - Phase B: Schlagartig bricht die Verbindung ab und es folgen 10–30 Sekunden mit 100 % Paketverlust synchron auf allen Hops ab `10.81.85.22` bis zum Ziel (???).

                Und danach wiederholt sich das Ganze kontinuierlich: Phase A→B→A→B... Dies lässt sich fast jederzeit mit `mtr` beobachten.

                Das betrifft nicht nur ICMP (Ping), sondern protokollunabhängig auch z.B. TCP (mtr mit -T). Durch TCP-Retransmissions ist die gemessene Paketverlustrate bei TCP zwar scheinbar niedriger, aber das Störungsmuster bleibt exakt dasselbe.

                Hingegen ist IPv6 immer einwandfrei, wie von praktisch jedem hier schon bestätigt wurde. Ich hoffe, das hilft euch, das Problem einzugrenzen und zu finden!

                 

                ICMP:

                 

                TCP:

                 

                Einsteiger:in
                Forum|alt.badge.img
                • mrwiggles
                • Einsteiger:in
                • September 17, 2026

                Guten Abend alle, ​@o2_Bianca und ​@o2_Matze 
                 

                entschuldigt bitte, dass ich diesen älteren Thread wieder aufgreife. Meine Probleme scheinen sich aber stark mit den hier beschriebenen zu überschneiden.

                Ich habe seit mindestens Mai anhaltende Probleme mit dem O2-Mobilfunkinternet zu Hause in Berlin, 10783. Langsam bin ich mit meinem Latein am Ende.
                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.

                Zunächst habe 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.

                Gespeicherte UDP-Traceroute-Messungen — 17. September 2026, MESZ (UTC+02:00)
                Aus den gespeicherten JSON-Daten formatiert; keine neue Messung.
                Eine Anfrage pro TTL, 700 ms Wartezeit auf die Antwort; Mobilfunkschnittstelle wwan0, Routing-Markierung 0x80000.
                Eine ausbleibende Antwort allein belegt keinen Fehler bei der Paketweiterleitung. Diese Traces messen keine Verlustraten pro Hop.

                Beginn: 2026-09-17T15:05:19.076168+02:00
                Ziel: 1.1.1.1
                TTL  Antwortadresse      RTT (ms)  ICMP-Typ/Code
                  1  10.0.81.131           15.96  11/0
                  2  195.71.210.60         14.77  11/0
                  3  10.81.85.22           17.76  11/0
                  4  62.53.166.98          11.75  11/0
                  5  62.53.0.184            16.0  11/0
                  6  162.158.112.6         46.39  11/0
                  7  162.158.112.33        18.32  11/0
                  8  1.1.1.1               14.13  3/3

                Beginn: 2026-09-17T15:05:28.923887+02:00
                Ziel: 185.15.59.224
                TTL  Antwortadresse      RTT (ms)  ICMP-Typ/Code
                  1  10.0.81.131           15.66  11/0
                  2  195.71.210.62         15.45  11/0
                  3  10.81.85.22           17.31  11/0
                  4  62.53.166.98          21.53  11/0
                  5  62.53.15.244          19.84  11/0
                  6  62.53.3.190           18.46  11/0
                  7  62.53.12.37           19.43  11/0
                  8  *                            
                  9  *                            
                 10  *                            
                 11  45.153.81.210         11.92  11/0
                 12  94.103.180.16         22.44  11/0
                 13  94.103.180.13         29.94  11/0
                 14  *                            
                 15  *                            
                 16  *                            
                 17  *                            
                 18  *                            
                 19  *                            
                 20  *                            
                 21  *                            
                 22  *                            
                 23  *                            
                 24  *

                 

                ​

                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.

                Beginn der Messreihe: 2026-09-17T18:59:29.156940+02:00
                Die folgenden Zeitangaben sind Sekunden seit Beginn der jeweiligen Anfrage.
                http=000: keine HTTP-Antwort. tls=0 / firstbyte=0: Die jeweilige Phase wurde nicht erreicht (bei unverschlüsseltem HTTP ist tls ebenfalls 0).

                HEAD http://one.one.one.one/ -> 1.1.1.1
                local=<ROUTER-IPv4>:37560 http=000 tcp=0.012192 tls=0.000000 firstbyte=0.000000 total=20.001343
                curl: (28) Operation timed out after 20001 milliseconds with 0 bytes received

                HEAD https://one.one.one.one/ -> 1.1.1.1
                local=<ROUTER-IPv4>:40090 http=000 tcp=0.015530 tls=0.000000 firstbyte=0.000000 total=15.001132
                curl: (28) Operation timed out after 15001 milliseconds with 0 out of 0 bytes received

                HEAD http://www.wikipedia.org/ -> 185.15.59.224
                local=<ROUTER-IPv4>:46086 http=000 tcp=0.022865 tls=0.000000 firstbyte=0.000000 total=20.001392
                curl: (28) Operation timed out after 20001 milliseconds with 0 bytes received

                HEAD https://www.wikipedia.org/ -> 185.15.59.224
                local=<ROUTER-IPv4>:43898 http=000 tcp=0.023318 tls=0.000000 firstbyte=0.000000 total=15.001755
                curl: (28) Operation timed out after 15001 milliseconds with 0 out of 0 bytes received

                TCP-Mitschnitt: ausgewählte HTTPS-Verbindungen auf wwan0; Zeitstempel in MESZ.
                tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
                listening on wwan0, link-type LINUX_SLL (Linux cooked v1), snapshot length 262144 bytes
                29 packets captured
                29 packets received by filter
                0 packets dropped by kernel

                2026-09-17 18:59:29.515284 IP <ROUTER-IPv4>.40090 > 1.1.1.1.443: Flags [S], seq 1351847352, win 42340, options [mss 1460,sackOK,TS val 3112842960 ecr 0,nop,wscale 12], length 0
                2026-09-17 18:59:29.526933 IP 1.1.1.1.443 > <ROUTER-IPv4>.40090: Flags [S.], seq 2464604398, ack 1351847353, win 65535, options [mss 1460,sackOK,TS val 3977327961 ecr 3112842960,nop,wscale 13], length 0
                2026-09-17 18:59:29.527219 IP <ROUTER-IPv4>.40090 > 1.1.1.1.443: Flags [.], ack 1, win 11, options [nop,nop,TS val 3112842972 ecr 3977327961], length 0
                2026-09-17 18:59:29.572436 IP <ROUTER-IPv4>.43898 > 185.15.59.224.443: Flags [S], seq 4172387306, win 42340, options [mss 1460,sackOK,TS val 2789541965 ecr 0,nop,wscale 12], length 0
                2026-09-17 18:59:29.594938 IP 185.15.59.224.443 > <ROUTER-IPv4>.43898: Flags [S.], seq 3288536965, ack 4172387307, win 43440, options [mss 1440,sackOK,TS val 4061804799 ecr 2789541965,nop,wscale 9], length 0
                2026-09-17 18:59:29.595192 IP <ROUTER-IPv4>.43898 > 185.15.59.224.443: Flags [.], ack 1, win 11, options [nop,nop,TS val 2789541988 ecr 4061804799], length 0
                2026-09-17 18:59:29.617622 IP <ROUTER-IPv4>.40090 > 1.1.1.1.443: Flags [P.], seq 1:518, ack 1, win 11, options [nop,nop,TS val 3112843062 ecr 3977327961], length 517
                2026-09-17 18:59:29.634416 IP 1.1.1.1.443 > <ROUTER-IPv4>.40090: Flags [.], ack 518, win 16, options [nop,nop,TS val 3977328068 ecr 3112843062], length 0
                2026-09-17 18:59:29.650358 IP <ROUTER-IPv4>.43898 > 185.15.59.224.443: Flags [P.], seq 1:518, ack 1, win 11, options [nop,nop,TS val 2789542043 ecr 4061804799], length 517
                2026-09-17 18:59:29.883792 IP <ROUTER-IPv4>.43898 > 185.15.59.224.443: Flags [P.], seq 1:518, ack 1, win 11, options [nop,nop,TS val 2789542277 ecr 4061804799], length 517
                2026-09-17 18:59:29.911919 IP 185.15.59.224.443 > <ROUTER-IPv4>.43898: Flags [.], ack 518, win 84, options [nop,nop,TS val 4061805116 ecr 2789542277,nop,nop,sack 1 {1:518}], length 0
                2026-09-17 18:59:44.522581 IP <ROUTER-IPv4>.40090 > 1.1.1.1.443: Flags [F.], seq 518, ack 1, win 11, options [nop,nop,TS val 3112857967 ecr 3977328068], length 0
                2026-09-17 18:59:44.581585 IP <ROUTER-IPv4>.43898 > 185.15.59.224.443: Flags [F.], seq 518, ack 1, win 11, options [nop,nop,TS val 2789556974 ecr 4061805116], length 0
                2026-09-17 18:59:44.753802 IP <ROUTER-IPv4>.40090 > 1.1.1.1.443: Flags [F.], seq 518, ack 1, win 11, options [nop,nop,TS val 3112858199 ecr 3977328068], length 0
                2026-09-17 18:59:44.813837 IP <ROUTER-IPv4>.43898 > 185.15.59.224.443: Flags [F.], seq 518, ack 1, win 11, options [nop,nop,TS val 2789557207 ecr 4061805116], length 0
                2026-09-17 18:59:44.983816 IP <ROUTER-IPv4>.40090 > 1.1.1.1.443: Flags [F.], seq 518, ack 1, win 11, options [nop,nop,TS val 3112858429 ecr 3977328068], length 0
                2026-09-17 18:59:45.053809 IP <ROUTER-IPv4>.43898 > 185.15.59.224.443: Flags [F.], seq 518, ack 1, win 11, options [nop,nop,TS val 2789557447 ecr 4061805116], length 0
                2026-09-17 18:59:45.433800 IP <ROUTER-IPv4>.40090 > 1.1.1.1.443: Flags [F.], seq 518, ack 1, win 11, options [nop,nop,TS val 3112858879 ecr 3977328068], length 0
                2026-09-17 18:59:45.523794 IP <ROUTER-IPv4>.43898 > 185.15.59.224.443: Flags [F.], seq 518, ack 1, win 11, options [nop,nop,TS val 2789557917 ecr 4061805116], length 0
                2026-09-17 18:59:46.333760 IP <ROUTER-IPv4>.40090 > 1.1.1.1.443: Flags [F.], seq 518, ack 1, win 11, options [nop,nop,TS val 3112859779 ecr 3977328068], length 0
                2026-09-17 18:59:46.493799 IP <ROUTER-IPv4>.43898 > 185.15.59.224.443: Flags [F.], seq 518, ack 1, win 11, options [nop,nop,TS val 2789558887 ecr 4061805116], length 0
                2026-09-17 18:59:48.173783 IP <ROUTER-IPv4>.40090 > 1.1.1.1.443: Flags [F.], seq 518, ack 1, win 11, options [nop,nop,TS val 3112861619 ecr 3977328068], length 0
                2026-09-17 18:59:48.413800 IP <ROUTER-IPv4>.43898 > 185.15.59.224.443: Flags [F.], seq 518, ack 1, win 11, options [nop,nop,TS val 2789560807 ecr 4061805116], length 0

                 

                ​

                ​

                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.

                $ ping -n -I wwan0 -c 3 -i .2 -W 2 -M do -s 56 1.1.1.1
                PING 1.1.1.1 (1.1.1.1) from <ROUTER-IPv4> wwan0: 56(84) bytes of data.
                64 bytes from 1.1.1.1: icmp_seq=1 ttl=57 time=13.6 ms
                64 bytes from 1.1.1.1: icmp_seq=2 ttl=57 time=10.7 ms
                64 bytes from 1.1.1.1: icmp_seq=3 ttl=57 time=10.5 ms

                --- 1.1.1.1 ping statistics ---
                3 packets transmitted, 3 received, 0% packet loss, time 401ms
                rtt min/avg/max/mdev = 10.514/11.626/13.631/1.420 ms

                $ ping -n -I wwan0 -c 3 -i .2 -W 2 -M do -s 536 1.1.1.1
                PING 1.1.1.1 (1.1.1.1) from <ROUTER-IPv4> wwan0: 536(564) bytes of data.
                544 bytes from 1.1.1.1: icmp_seq=1 ttl=57 time=14.9 ms
                544 bytes from 1.1.1.1: icmp_seq=2 ttl=57 time=14.6 ms
                544 bytes from 1.1.1.1: icmp_seq=3 ttl=57 time=16.0 ms

                --- 1.1.1.1 ping statistics ---
                3 packets transmitted, 3 received, 0% packet loss, time 401ms
                rtt min/avg/max/mdev = 14.607/15.169/16.009/0.605 ms

                $ ping -n -I wwan0 -c 3 -i .2 -W 2 -M do -s 1472 1.1.1.1
                PING 1.1.1.1 (1.1.1.1) from <ROUTER-IPv4> wwan0: 1472(1500) bytes of data.
                1480 bytes from 1.1.1.1: icmp_seq=1 ttl=57 time=15.5 ms
                1480 bytes from 1.1.1.1: icmp_seq=2 ttl=57 time=14.5 ms
                1480 bytes from 1.1.1.1: icmp_seq=3 ttl=57 time=25.9 ms

                --- 1.1.1.1 ping statistics ---
                3 packets transmitted, 3 received, 0% packet loss, time 402ms
                rtt min/avg/max/mdev = 14.510/18.664/25.942/5.163 ms

                 

                ​

                ​

                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.​

                Beginn der Messreihe: 2026-09-17T19:15:50.646625+02:00
                Die folgenden Zeitangaben sind Sekunden seit Beginn der jeweiligen Anfrage.
                http=000: keine HTTP-Antwort. tls=0 / firstbyte=0: Die jeweilige Phase wurde nicht erreicht (bei unverschlüsseltem HTTP ist tls ebenfalls 0).

                HEAD http://one.one.one.one/ -> 1.1.1.1
                local=<ROUTER-IPv4>:60194 http=301 tcp=0.014615 tls=0.000000 firstbyte=0.027066 total=0.027291

                HEAD https://one.one.one.one/ -> 1.1.1.1
                local=<ROUTER-IPv4>:39550 http=200 tcp=0.014041 tls=0.184209 firstbyte=0.229629 total=0.229771

                HEAD http://www.wikipedia.org/ -> 185.15.59.224
                local=<ROUTER-IPv4>:35228 http=301 tcp=0.023126 tls=0.000000 firstbyte=0.045748 total=0.045983

                HEAD https://www.wikipedia.org/ -> 185.15.59.224
                local=<ROUTER-IPv4>:53998 http=200 tcp=0.025701 tls=0.149249 firstbyte=0.178200 total=0.178391

                Auszug aus dem TCP-Mitschnitt: Verbindungsaufbau und erste Antwort-Nutzdaten (spätere Pakete ausgelassen).
                2026-09-17 19:15:51.024146 IP <ROUTER-IPv4>.39550 > 1.1.1.1.443: Flags [S], seq 2086401861, win 42340, options [mss 1460,sackOK,TS val 3113824469 ecr 0,nop,wscale 12], length 0
                2026-09-17 19:15:51.036637 IP 1.1.1.1.443 > <ROUTER-IPv4>.39550: Flags [S.], seq 1514937543, ack 2086401862, win 65535, options [mss 1460,sackOK,TS val 924885515 ecr 3113824469,nop,wscale 13], length 0
                2026-09-17 19:15:51.036907 IP <ROUTER-IPv4>.39550 > 1.1.1.1.443: Flags [.], ack 1, win 11, options [nop,nop,TS val 3113824482 ecr 924885515], length 0
                2026-09-17 19:15:51.108324 IP <ROUTER-IPv4>.53998 > 185.15.59.224.443: Flags [S], seq 2147663298, win 42340, options [mss 1460,sackOK,TS val 2790523501 ecr 0,nop,wscale 12], length 0
                2026-09-17 19:15:51.131615 IP 185.15.59.224.443 > <ROUTER-IPv4>.53998: Flags [S.], seq 3013892200, ack 2147663299, win 43440, options [mss 1440,sackOK,TS val 109902895 ecr 2790523501,nop,wscale 9], length 0
                2026-09-17 19:15:51.131880 IP <ROUTER-IPv4>.53998 > 185.15.59.224.443: Flags [.], ack 1, win 11, options [nop,nop,TS val 2790523525 ecr 109902895], length 0
                2026-09-17 19:15:51.167877 IP <ROUTER-IPv4>.39550 > 1.1.1.1.443: Flags [P.], seq 1:518, ack 1, win 11, options [nop,nop,TS val 3113824613 ecr 924885515], length 517
                2026-09-17 19:15:51.186629 IP 1.1.1.1.443 > <ROUTER-IPv4>.39550: Flags [.], ack 518, win 16, options [nop,nop,TS val 924885664 ecr 3113824613], length 0
                2026-09-17 19:15:51.189638 IP 1.1.1.1.443 > <ROUTER-IPv4>.39550: Flags [.], seq 1:1449, ack 518, win 16, options [nop,nop,TS val 924885666 ecr 3113824613], length 1448
                2026-09-17 19:15:51.189826 IP <ROUTER-IPv4>.39550 > 1.1.1.1.443: Flags [.], ack 1449, win 11, options [nop,nop,TS val 3113824635 ecr 924885666], length 0
                2026-09-17 19:15:51.189861 IP 1.1.1.1.443 > <ROUTER-IPv4>.39550: Flags [P.], seq 1449:2631, ack 518, win 16, options [nop,nop,TS val 924885666 ecr 3113824613], length 1182
                2026-09-17 19:15:51.189924 IP <ROUTER-IPv4>.39550 > 1.1.1.1.443: Flags [.], ack 2631, win 11, options [nop,nop,TS val 3113824635 ecr 924885666], length 0
                2026-09-17 19:15:51.201797 IP <ROUTER-IPv4>.53998 > 185.15.59.224.443: Flags [P.], seq 1:518, ack 1, win 11, options [nop,nop,TS val 2790523595 ecr 109902895], length 517
                2026-09-17 19:15:51.207243 IP <ROUTER-IPv4>.39550 > 1.1.1.1.443: Flags [P.], seq 518:598, ack 2631, win 11, options [nop,nop,TS val 3113824652 ecr 924885666], length 80
                2026-09-17 19:15:51.208074 IP <ROUTER-IPv4>.39550 > 1.1.1.1.443: Flags [P.], seq 598:644, ack 2631, win 11, options [nop,nop,TS val 3113824653 ecr 924885666], length 46
                2026-09-17 19:15:51.208235 IP <ROUTER-IPv4>.39550 > 1.1.1.1.443: Flags [P.], seq 644:693, ack 2631, win 11, options [nop,nop,TS val 3113824653 ecr 924885666], length 49
                2026-09-17 19:15:51.208286 IP <ROUTER-IPv4>.39550 > 1.1.1.1.443: Flags [P.], seq 693:728, ack 2631, win 11, options [nop,nop,TS val 3113824653 ecr 924885666], length 35
                2026-09-17 19:15:51.208885 IP <ROUTER-IPv4>.39550 > 1.1.1.1.443: Flags [P.], seq 728:806, ack 2631, win 11, options [nop,nop,TS val 3113824654 ecr 924885666], length 78
                2026-09-17 19:15:51.220109 IP 1.1.1.1.443 > <ROUTER-IPv4>.39550: Flags [P.], seq 2631:3191, ack 598, win 16, options [nop,nop,TS val 924885697 ecr 3113824652], length 560
                2026-09-17 19:15:51.220336 IP <ROUTER-IPv4>.39550 > 1.1.1.1.443: Flags [.], ack 3191, win 11, options [nop,nop,TS val 3113824665 ecr 924885697], length 0
                2026-09-17 19:15:51.221416 IP <ROUTER-IPv4>.39550 > 1.1.1.1.443: Flags [P.], seq 806:837, ack 3191, win 11, options [nop,nop,TS val 3113824666 ecr 924885697], length 31
                2026-09-17 19:15:51.221612 IP 1.1.1.1.443 > <ROUTER-IPv4>.39550: Flags [.], ack 693, win 16, options [nop,nop,TS val 924885699 ecr 3113824653], length 0
                2026-09-17 19:15:51.221725 IP 1.1.1.1.443 > <ROUTER-IPv4>.39550: Flags [P.], seq 3191:3222, ack 693, win 16, options [nop,nop,TS val 924885699 ecr 3113824653], length 31
                2026-09-17 19:15:51.221799 IP <ROUTER-IPv4>.39550 > 1.1.1.1.443: Flags [.], ack 3222, win 11, options [nop,nop,TS val 3113824667 ecr 924885699], length 0
                2026-09-17 19:15:51.224123 IP 1.1.1.1.443 > <ROUTER-IPv4>.39550: Flags [.], ack 806, win 16, options [nop,nop,TS val 924885702 ecr 3113824654], length 0
                2026-09-17 19:15:51.229615 IP 185.15.59.224.443 > <ROUTER-IPv4>.53998: Flags [.], seq 1:1449, ack 518, win 84, options [nop,nop,TS val 109902992 ecr 2790523595], length 1448

                 

                ​

                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.
                 

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

                Einsteiger:in
                Forum|alt.badge.img
                • mrwiggles
                • Einsteiger:in
                • September 25, 2026

                Ich wäre für jede Hilfe hier sehr dankbar.

                Einsteiger:in
                Forum|alt.badge.img
                • mrwiggles
                • Einsteiger:in
                • September 28, 2026

                Zur Information: Ich habe erneut ein Ticket beim technischen System eröffnet S30809569, mal schauen 

                Allgemeine Nutzungsbedingungen der O₂ CommunityAccessibility statement
                © Telefónica Germany GmbH & Co. OHG Telefónica