APN netpublic: Ping funktioniert, aber HTTPS fällt mehrmals täglich aus

Du könntest mal den APN wieder auf Internet stellen, dann ist die IP V4 aus und schauen ob es weiter zu dem Phänomen kommt. Damit könnte man das weiter einkreisen.

Wow, danke fuer den Vorschlag. Ich habe den APN gestern gegen 23.43 Uhr von netpublic auf internet umgestellt.

Seit der Umstellung wurde nur eine sehr kurze Unterbrechung erkannt. Diese trat heute um 10.17 Uhr auf und war nach ungefaehr acht Sekunden wieder vorbei. Ein automatischer Neuaufbau der Mobilfunkverbindung war nicht erforderlich.

Zum Vergleich wurden mit dem APN netpublic innerhalb von etwa fuenf Stunden zahlreiche einzelne Ausfaelle aufgezeichnet, teilweise mehrfach kurz hintereinander. Zweimal musste die Mobilfunkverbindung automatisch neu aufgebaut werden. Mit dem APN internet laeuft die Verbindung bisher also deutlich stabiler.

Ich werde den Test mit dem APN internet noch etwas weiterlaufen lassen. Leider erhalte ich damit nur eine private IPv4 Adresse aus dem Bereich 10.x.x.x. Fuer meinen Gaming Anwendungsfall und die dafuer benoetigte oeffentliche IPv4 ist das daher keine dauerhafte Loesung.

Gibt es noch etwas, das ich auf meiner Seite testen oder anders konfigurieren koennte? Falls weitere Messwerte oder bestimmte Tests hilfreich waeren, kann ich diese gerne durchfuehren.

Vielen Dank fuer deine Hilfe.

Hallo ​@Figor ,
herzlich willkommen in unserer o2 Community 😀
Von unserer Seite aus können wir nur die IPv4 Adresse aktivieren und deaktivieren. 
Du kannst nur den APN auf netpublic setzen. 
Wie ist denn der aktuelle Stand ? 
Gruß, Solveig 
 

Hallo Solveig,

vielen Dank fuers Nachfragen!

Ich verwende seit dem 02.10. weiterhin den APN internet. Anfangs wirkte die Verbindung damit deutlich stabiler als mit netpublic. Leider treten die Unterbrechungen aber weiterhin auf.

Aktuelle Beispiele aus der automatischen Aufzeichnung, jeweils deutsche Ortszeit:

- 13.10.: wiederholte Verbindungsfehler zwischen etwa 22:30 und 22:34 Uhr
- 14.10.: erneut Fehler zwischen etwa 22:55 und 22:57 Uhr
- 15.10.: ein weiterer Fehler gegen 12:39 Uhr

Beim Vorfall am 13.10. schlugen HTTPS-Anfragen direkt vom Router aus fehl, teilweise zu mehreren Zielen gleichzeitig. Zeitweise funktionierte Google, aber Cloudflare nicht, oder umgekehrt. Auch Ping schlug in einigen Messungen fehl. Die IPv4-Adressen von Modem und Router blieben dabei gleich. Die Verbindung erholte sich ohne automatischen Neuaufbau.

Zur Einordnung: Auch mit dem APN internet verwende ich weiterhin IPv4 und erhalte eine private Adresse. Es war also bisher kein Vergleich zwischen IPv4 und IPv6. Router ist weiterhin der GL-X3000, MTU 1420.

Zusaetzlich gibt es ein anderes, nahezu taegliches Problem: Nach einem IP-Wechsel behaelt die Router-Schnittstelle zeitweise die alte Adresse. Eine automatische Wiederherstellung behebt das anschliessend. Diesen Punkt moechte ich getrennt betrachten, da die oben beschriebenen Ausfaelle auch ohne einen solchen Adressunterschied auftreten.

Eine bisherige Netzpruefung durch O2 hatte laut SMS leider keinen Befund ergeben.

Gibt es eine Moeglichkeit, die genannten Zeitpunkte gezielt pruefen zu lassen? Oder gibt es bestimmte Tests oder Messwerte, die ich auf meiner Seite noch erfassen koennte, um die Ursache weiter einzugrenzen?

Langfristig wuerde ich wegen meines Gaming-Anwendungsfalls gerne wieder netpublic mit oeffentlicher IPv4 nutzen. Aktuell lasse ich internet zum Vergleich eingestellt.

Vielen Dank fuer eure Hilfe!

Hallo ​@Figor,
vielen Dank für deine Antwort. Wenn die Einschränkungen bei beiden APN auftreten sieht es für mich nach dem Netz als Ursache aus. Hast du schon im LiveCheck nach evtl. Störungen an deiner Adresse geschaut? Kannst du deine SIM-Karte mal in einem anderen Gerät ausprobieren um den Router als Fehlerquelle auszuschließen?
Liebe Grüße Bianca

Hallo Bianca,

vielen Dank fuer deinen Vorschlag! Der LiveCheck hat keine Stoerung angezeigt.

Ich habe dieselbe SIM inzwischen in einem Samsung Galaxy S8 mit 4G+ getestet. Mein PC war dabei direkt mit dem Handy-Hotspot verbunden, also ohne den GL-X3000 im Verbindungsweg.

Leider wurden auch dabei Verbindungsfehler aufgezeichnet. Zusaetzlich nutzte der Router die Handyverbindung per USB-Tethering. Beide Geraete registrierten nahezu gleichzeitig fehlgeschlagene Webverbindungen, beispielsweise heute, am 19.10., gegen 08:50, 10:53 und 13:45 Uhr. Die lokale Verbindung vom PC zum Handy funktionierte waehrenddessen weiter.

Damit tritt das Problem offenbar auch mit einem anderen Mobilfunkgeraet auf. Die genaue Ursache ist allerdings noch unklar.

Waere anhand dieser Ergebnisse eine erneute Pruefung zu meinem bisherigen Ticket S30829024 moeglich? Gibt es weitere Tests oder bestimmte Informationen, die euch helfen wuerden? Zeitstempel und anonymisierte Diagnoseauszuege kann ich gerne bereitstellen.

Vielen Dank und liebe Gruesse
Igor

Hi ​@Figor 

Eine Frage: Hast du den den MTU Wert von 1420 selber eingestellt, oder war das eine Standardeinstellung in deinem Router? Du könntest testweise den Wert mal verändern (verkleinern auf z.B. 1350) und schauen, ob das einen positiven Effekt hat.

Der netpublic APN selber funktioniert nicht im 5G SA Netz, daher wäre es zusätzlich mal interessant, ob es einen Unterschied macht, wenn du deinen Router auf 4G only konfigurierst.  

VG Matze 

Hallo Matze,

danke fuer deine Tipps! Die MTU steht aktuell auf 1420. Ob das urspruenglich die Standardeinstellung war, kann ich leider nicht mehr sicher sagen. Einen Test mit 1350 kann ich gerne noch machen.

Inzwischen habe ich die gleiche SIM auch in einem Samsung Galaxy S8 mit 4G getestet. Dabei traten ebenfalls Verbindungsprobleme auf, auch wenn mein PC direkt mit dem Hotspot des Handys verbunden war, also ohne den GL.iNet-Router dazwischen.

Mittlerweile wurde mein Vertrag von O2 zum 30.11. gekuendigt. Ein konkreter Grund wurde dabei nicht genannt. Da mein Datenverbrauch recht hoch war, frage ich mich, ob es irgendeinen Zusammenhang geben koennte. Koennte auf meiner SIM eine verbrauchsabhaengige Priorisierung oder andere Einschraenkung aktiv gewesen sein, die solche Probleme erklaeren wuerde?

Das ist nur eine Vermutung. Koennt ihr das eventuell pruefen oder sagen, ob diese Dinge unabhaengig voneinander sind?

Vielen Dank und viele Gruesse!

​@Figor Ich sehe hier nur die fristgerechte Kündigung, die Info warum diese ausgesprochen wurde liegt uns hier nicht vor. 

Koennte auf meiner SIM eine verbrauchsabhaengige Priorisierung oder andere Einschraenkung aktiv gewesen sein, die solche Probleme erklaeren wuerde?

Das halte ich für eher unwahrscheinlich, das von dir beschriebene Fehlerbild klingt eher nach einer technischen Störung, besonders da sich die Fehlerbilder ja bei den verschiedenen APNs auch unterschiedlich darstellen. 

Aufgrund des doch sehr komplexen Sachverhalts bin ich aber verhalten optimistisch, dass das ganze noch vor dem Vertragsende gelöst werden kann 😕

Trotzdem wäre es super interessant, ob es etwas ändert wenn du ein wenig mit den  MTU Werten experimentieren könntest, um zu schauen ob das einen positiven Effekt hat.

VG Matze

Hallo ​@o2_Matze ,

vielen Dank fuer deine Hilfe und den Vorschlag mit der MTU!

Ich habe inzwischen einen 24-Stunden-Test mit 1420, 1350 und 1280 durchgefuehrt. Jeder Wert war insgesamt acht Stunden eingestellt, verteilt auf zwei Bloecke. APN und sonstige Einstellungen blieben unveraendert.

Das Ergebnis:

• MTU 1420: keine fehlgeschlagenen Testanfragen.
• MTU 1350: eine fehlgeschlagene Testanfrage.
• MTU 1280: zehn fehlgeschlagene Testanfragen, teilweise gleichzeitig zu mehreren Anbietern.

Das sind einzelne Anfragen, nicht zehn getrennte Ausfaelle. Eine Verbesserung durch die kleinere MTU konnte ich damit bisher nicht feststellen. Wegen der unterschiedlichen Testzeiten bedeutet das aber auch nicht automatisch, dass 1280 schlechter ist.

Zusaetzlich wurde beim morgendlichen IP-Wechsel aufgezeichnet, dass das Modem bereits eine neue IP hatte, die Router-Schnittstelle aber noch die alte verwendete. Nach der automatischen IP-Wiederherstellung funktionierten die Verbindungen wieder. Diese Wiederherstellungsphase wurde separat protokolliert. Die MTU steht inzwischen wieder auf 1420.

Noch zur Transparenz: Ich kenne mich mit Netzwerktechnik nicht besonders gut aus und nutze ChatGPT Codex zur Unterstuetzung bei den Tests und der Auswertung. Falls du weitere konkrete Testideen hast oder bestimmte Messwerte brauchst, kann ich gerne versuchen, das mit Codex umzusetzen und die Ergebnisse hier zu teilen.

Vielen Dank nochmal fuer deine Unterstuetzung!

Viele Gruesse
Igor

​@Figor 

Was passiert wenn du MTU auf den Standardwert 1500 stellst? 

Hallo ​@The_Voice_70 

danke fuer den Vorschlag! Ich habe MTU 1500 vom 26. bis 27. Oktober ueber 24 Stunden mit dem APN internet getestet und die Verbindung dabei automatisch protokolliert.

Leider gab es gegen 14:09 Uhr mehrere fehlgeschlagene oder sehr langsame Verbindungen und gegen 16:40 Uhr eine weitere kurze Unterbrechung, bei der die IP unveraendert blieb. Dabei waren mehrere unterschiedliche Ziele betroffen.

Eine klare Verbesserung durch MTU 1500 konnte ich somit bisher nicht feststellen. Nach dem Test wurde wieder 1420 eingestellt.

​@Figor Bemerkst du im Daily Business denn diese Einschränkungen noch so massiv, oder fallen dir die Fehler nur in den Logs auf und weil die Verbindung dauerhaft gemonitored wird? 

VG Matze 

Hallo ​@o2_Matze 

ich habe inzwischen noch einmal auf netpublic zurueckgewechselt und mit MTU 1420 getestet. Gestern habe ich den ganzen Tag im Homeoffice gearbeitet und keinerlei Probleme bemerkt. Dazu passen auch die Messungen: Zwischen 08 und 18 Uhr waren alle Testanfragen erfolgreich.

Heute Morgen waren die Einschraenkungen allerdings wieder deutlich spuerbar: Eine Webseite hing etwa drei Minuten beim TLS-Handshake, eine andere lud nur teilweise, und ein Speedtest meldete keine Internetverbindung. Trennen und erneutes Verbinden ueber die Routeroberflaeche half nicht. Erst nach einem Neustart funktionierte es wieder.

In den Logs sieht man gestern Abend gegen 22:17 Uhr einen IP-Wechsel. Die dabei entstandene Abweichung zwischen Modem- und Router-IP wurde automatisch korrigiert. Trotzdem gab es danach nachts und heute Morgen weitere HTTPS-Ausfaelle, obwohl die IPs uebereinstimmten und Ping weiterhin funktionierte.

Es sind also leider nicht nur Fehler, die durch die Ueberwachung auffallen. Es gibt komplett unauffaellige Phasen, aber dann auch wieder erhebliche Einschraenkungen im Alltag.

Koennte dieser zeitliche Zusammenhang mit dem IP-Wechsel bei der Eingrenzung helfen? Gibt es einen gezielten Test, den ich beim naechsten Auftreten durchfuehren koennte, bevor ich neu starte?

Hallo zusammen,

ich habe inzwischen einen weiteren Vergleich gemacht: Meine O2 SIM lief im GL-X3000, gleichzeitig steckte eine ALDI TALK SIM in einem separaten Handy. Mein privater PC war direkt mit dem WLAN-Hotspot des Handys verbunden, also ohne Verbindung zum GL-X3000.

Heute, am 05.11.2026 gegen 14:31 Uhr, wurde mein Zoom-Anruf ueber O2 unterbrochen. Auch YouTube liess sich fuer etwa ein bis zwei Minuten nicht oeffnen.

Die parallel laufenden Messungen haben Folgendes aufgezeichnet:
- O2: Um 14:31:06 und 14:31:36 scheiterten Verbindungen zu Cloudflare sowie DNS-Abfragen fuer einen Microsoft-Testserver. Auch externe Pings fielen teilweise aus. Der Router blieb lokal erreichbar und Google funktionierte weiterhin. Ab 14:32:36 waren alle Tests wieder erfolgreich.
- ALDI TALK im Handy: Zwischen 14:30:46 und 14:32:06 scheiterten neun aufeinanderfolgende Cloudflare-Verbindungsversuche. Google und Microsoft blieben dort erreichbar.

Damit gab es zeitgleich Probleme auf zwei getrennten SIMs und Geraeten. Die Symptome waren nicht komplett identisch, aber die zeitliche Ueberschneidung finde ich auffaellig.

Koennte das auf ein gemeinsames Problem im Netz oder auf bestimmten Verbindungswegen hindeuten? 

Im Anhang findet ihr einen anonymisierten Messauszug beider Verbindungen rund um 14:31 Uhr. Vielleicht hilft die zeitliche Gegenueberstellung bei der weiteren Eingrenzung.

Vielen Dank weiterhin fuer eure Unterstuetzung!

Redigierter Messauszug: O2 und ALDI TALK am 05.11.2026

Alle Zeiten: Europe/Berlin, CET (UTC+1).
Zeitstempel bezeichnen den Beginn eines Messdurchlaufs, nicht die exakte
Dauer einer Stoerung. Ein Timeout kann mehrere Sekunden spaeter enden.

AUFBAU
O2: SIM im GL-X3000, unabhaengiger Linux-Messrechner hinter dem Router.
ALDI TALK: separate SIM im Handy, Windows-PC direkt am Handy-WLAN-Hotspot.
Der Windows-PC war dabei nicht ueber den GL-X3000 verbunden.
O2-Messintervall: 30 Sekunden. ALDI-Messintervall: etwa 10 Sekunden.
IPv4-Tests mit curl zu Google HTTPS, Cloudflare HTTPS per direkter
Zieladresse (ohne DNS-Aufloesung) und Microsoft HTTP.
Die Tests bilden Zoom, YouTube und Browser-Verkehr nicht vollstaendig ab.

NUTZERBEOBACHTUNG (nicht automatisch gemessen)
Gegen 14:31 wurde ein Zoom-Anruf ueber O2 unterbrochen. YouTube liess
sich ebenfalls fuer etwa ein bis zwei Minuten nicht oeffnen.

O2: AUS GESPEICHERTEN LINUX-MESSUNGEN
Die folgenden Zeilen wurden aus den gespeicherten JSON-Messungen
abgeschrieben und vereinheitlicht; dies ist kein unveraenderter Rohlog.

Zeit      Google HTTPS  Cloudflare HTTPS       Microsoft HTTP
14:30:06  HTTP 204      HTTP 200                HTTP 200
14:30:36  HTTP 204      HTTP 200                HTTP 200
14:31:06  HTTP 204      Verbindungs-Timeout     DNS-Timeout
14:31:36  HTTP 204      Verbindungs-Timeout     DNS-Timeout
14:32:06  HTTP 204      HTTP 200, TCP ca. 4.14s DNS-Timeout
14:32:36  HTTP 204      HTTP 200                HTTP 200
14:33:06  HTTP 204      HTTP 200                HTTP 200

Fehlerdetails aus curl:
14:31:06 Cloudflare: curl (28) Connection timed out after 5002 milliseconds
14:31:06 Microsoft:  curl (28) Resolving timed out after 5001 milliseconds
14:31:36 Cloudflare: curl (28) Connection timed out after 5002 milliseconds
14:31:36 Microsoft:  curl (28) Resolving timed out after 5000 milliseconds
14:32:06 Microsoft:  curl (28) Resolving timed out after 5000 milliseconds

O2-Pingmessungen:
14:31:06 Ein oeffentliches Pingziel ausgefallen; Router erreichbar.
14:31:36 Beide oeffentlichen Pingziele ausgefallen; Router erreichbar.
14:32:06 Ein oeffentliches Pingziel ausgefallen; Router erreichbar.
14:32:36 Alle Pingziele wieder erreichbar.

ALDI TALK: AUTOMATISCH AUS WINDOWS-JSON-LOGS EXTRAHIERT
Nur ausgewaehlte Messfelder, ohne lokale Adressen oder Kennungen.
rc=0: curl erfolgreich; rc=28: Timeout; HTTP 000: keine HTTP-Antwort.
TCP/TLS-Werte sind kumulative Sekunden seit Beginn der Anfrage.
Nullwerte bei Fehlern bedeuten nicht, dass die Verbindung sofort gelang.

14:30:36 google rc=0 HTTP=204 TCP_s=0.033946 TLS_s=0.094478
14:30:36 cloudflare-direct rc=0 HTTP=200 TCP_s=0.022308 TLS_s=0.06739
14:30:36 microsoft-http rc=0 HTTP=200 TCP_s=0.067644 TLS_s=0
14:30:46 google rc=0 HTTP=204 TCP_s=0.057484 TLS_s=0.11685
14:30:46 cloudflare-direct rc=28 HTTP=000 TCP_s=0 TLS_s=0
14:30:46 microsoft-http rc=0 HTTP=200 TCP_s=0.050589 TLS_s=0
14:30:56 google rc=0 HTTP=204 TCP_s=0.040876 TLS_s=0.099862
14:30:56 cloudflare-direct rc=28 HTTP=000 TCP_s=0 TLS_s=0
14:30:56 microsoft-http rc=0 HTTP=200 TCP_s=0.068045 TLS_s=0
14:31:06 google rc=0 HTTP=204 TCP_s=0.036701 TLS_s=0.089916
14:31:06 cloudflare-direct rc=28 HTTP=000 TCP_s=0 TLS_s=0
14:31:06 microsoft-http rc=0 HTTP=200 TCP_s=0.031794 TLS_s=0
14:31:16 google rc=0 HTTP=204 TCP_s=0.048169 TLS_s=0.102714
14:31:16 cloudflare-direct rc=28 HTTP=000 TCP_s=0 TLS_s=0
14:31:16 microsoft-http rc=0 HTTP=200 TCP_s=0.055399 TLS_s=0
14:31:26 google rc=0 HTTP=204 TCP_s=0.039602 TLS_s=0.08767
14:31:26 cloudflare-direct rc=28 HTTP=000 TCP_s=0 TLS_s=0
14:31:26 microsoft-http rc=0 HTTP=200 TCP_s=0.037319 TLS_s=0
14:31:36 google rc=0 HTTP=204 TCP_s=0.058735 TLS_s=0.121296
14:31:36 cloudflare-direct rc=28 HTTP=000 TCP_s=0 TLS_s=0
14:31:36 microsoft-http rc=0 HTTP=200 TCP_s=0.087701 TLS_s=0
14:31:46 google rc=0 HTTP=204 TCP_s=0.056996 TLS_s=0.107492
14:31:46 cloudflare-direct rc=28 HTTP=000 TCP_s=0 TLS_s=0
14:31:46 microsoft-http rc=0 HTTP=200 TCP_s=0.034897 TLS_s=0
14:31:56 google rc=0 HTTP=204 TCP_s=0.031752 TLS_s=0.079914
14:31:56 cloudflare-direct rc=28 HTTP=000 TCP_s=0 TLS_s=0
14:31:56 microsoft-http rc=0 HTTP=200 TCP_s=0.039703 TLS_s=0
14:32:06 google rc=0 HTTP=204 TCP_s=0.039655 TLS_s=0.105902
14:32:06 cloudflare-direct rc=28 HTTP=000 TCP_s=0 TLS_s=0
14:32:06 microsoft-http rc=0 HTTP=200 TCP_s=0.055324 TLS_s=0
14:32:16 google rc=0 HTTP=204 TCP_s=0.033311 TLS_s=0.084523
14:32:16 cloudflare-direct rc=0 HTTP=200 TCP_s=0.019017 TLS_s=0.07909
14:32:16 microsoft-http rc=0 HTTP=200 TCP_s=0.040666 TLS_s=0

EINORDNUNG UND GRENZEN
Auf beiden getrennten Verbindungen wurden im selben Zeitfenster Fehler
zum Cloudflare-Testziel aufgezeichnet. Google blieb auf beiden erreichbar.
Dies belegt eine zeitliche Ueberschneidung partieller Verbindungsprobleme,
aber nicht die genaue Ursache oder den betroffenen Netzabschnitt.
Keine Messung des Zoom-Datenstroms und keine Paketaufzeichnung vorhanden.

In den gesicherten Router-Recovery-Protokollen ist um 14:31 kein
automatischer Neuaufbau und keine automatische IP-Korrektur verzeichnet.
Der detaillierte rollierende Router-Probelog reicht nicht mehr bis 14:31
zurueck; deshalb ist eine unveraenderte Modem-IP hier nicht nachgewiesen.
Die obigen O2-Probeergebnisse stammen vom separaten Linux-Messrechner.

DATENSCHUTZ
Nicht enthalten: Name, Rufnummer, Kundennummer, SIM-Kennungen, IMEI,
Zellkennungen, MAC-Adressen, eigene IP-Adressen, WLAN-Namen, Passwoerter,
Geraetenamen, Prozesslisten oder persoenliche Dateipfade.
Enthalten bleiben Testdatum, Uhrzeiten, Routermodell, Anbieter und
technische Ergebnisse, damit der Vorfall zeitlich zugeordnet werden kann.

Hi ​@Figor 

Vielen Dank für deine Unterstützung und die Mühe bei der Fehlereingrenzung.

In der Tat zeigt deine sehr detaillierte Messung da eine kurzzeitige Großraum bzw. Core-Netz-Störung bzw. temporäre Einschränkung.

Dieses “Sand im Getriebe” also diese kurz auftreten Störungen sind sehr schwer zu lokalisieren bzw. zu korrigieren. Konntest du da selber ein Muster erkennen? Tritt das ganze wiederkehrend zu bestimmten Tagen und Zeiten auf, oder passiert das komplett sporadisch? 

VG Matze