Kein Zugriff auf Webseite der Frankfurter Rundschau, fr.de (MTU Anpassungs-Problem?)

Anscheinend macht Linux immer 30 Hops, auch wenn die route schon beendet ist. eine Vermutung, denn ich weiß es einfach nicht, liegt aber nahe. Und die tracertroute zu fr endet stets bei voxility, und das ist ein Internet Service Provider ISP, genau wie Telekom oder 1&1

Symptom Update (zur Diagnose gibts noch nichts Neues):

Zusammenfassend lässt sich zur Symptomatik sagen, dass die [teilweisen] Gutfälle (also Fälle, wo fr.de [teilweise] per Browser erreicht werden kann), sporadisch und unvorhersehbar sind. Folgende Konstellationen habe ich bisher beobachtet:

• Schlechtfall (das ist leider der "Normalfall"): "fr.de" ist gar nicht erreichbar - weder WLAN, noch LAN, weder "via normales Netzwerk", noch "via Gastzugang".
• Teil-Gutfall: "fr.de" ist nur über Gastzugang erreichbar (WLAN, oder auch LAN über den "LAN4"-Anschluss der Fritzbox).
• Teil-Gutfall: "fr.de" ist nur über WLAN zu erreichen (normal und Gastzugang) aber nicht über LAN.
• Teil-Gutfall: "fr.de" ist nur über LAN zu erreichen aber nicht über WLAN (weder Normal- noch Gastzugang).
• Gutfall (nur einmal heute kurz für ca. 10 min mit FW 7.57 erlebt): fr.de ist auf alle Weisen erreichbar (WLAN [normal und Gast], LAN).

Gut- oder Teil-Gutfälle gehen i.d.R. von selbst früher oder später wieder in den Schlecht-Fall über.

Als Geräte sind ein Linux Notebook (LAN und WLAN fähig) und zwei Android Smartphones regelmäßig im Spiel, wobei eines der Smartphones bisher immer nur Gastzugang hatte, während ich beim anderen Phone beides abwechselnd ausprobiere.

Heute habe ich FW Update von 7.57 zu 7.59 gemacht -> keine Änderung.
(UPDATE 13.06.2024, 23:49: Oder doch? Seit über 24 Stunden ist nun der Gastzugang in Bezug auf fr.de immer funktionierend. Zufall? Oder ist hier was anders?)

Weiterhin gilt:

• Notebook Gastzugang über LAN4 Buchse: Das habe ich nur einmal heute für etwas längere Zeit ausprobiert (ca. 30-60 min), und da war fr.de erreichbar. Ob das aber IMMER für den LAN4-Gastzugang gilt, weiß ich nicht. Während all der Zeit war auch der Gastzugang über WLAN ok, und hierzu weiß ich ja bereits, dass das meistens aber nicht geht.

Über allem gilt zudem die Feststellung: Egal was für ein Fall gerade vorliegt - nach Endgeräte-seitiger Umstellung von MTU=1500 auf MTU=1052 geht der Zugriff auf fr.de IMMER (von diesem Endgerät aus).


Das Verhalten der ping-Kommandos ist immer gleich, egal ob gerade ein Gut- oder Schlechtfall vorliegt:

Bei "normalem" Zugang (NICHT Gastzugang) via LAN oder WLAN ergibt sich immer folgendes Bild:

Code:

$ ping fr.de -c 4 -M do -s 512 --> Erfolg
$ ping fr.de -c 4 -M do -s 1024 --> Erfolg (Bem.: 1024+28=1052 bytes)
$ ping fr.de -c 4 -M do -s 1025 --> Timeout, 100% packet loss
$ ping fr.de -c 4 -M do -s 1448 --> Timeout, 100% packet loss (Bem.: 1448+28=1476 bytes)
$ ping fr.de -c 4 -M do -s 1449 --> Fehlermeldung "Message too long, mtu=1476", 100% packet loss
Zum Vergleich bei heise.de (ebenso bei allen anderen von mir getesteten Sites, z.B. google.de, web.de, www.faz.net):
$ ping heise.de -c 4 -M do -s 512 --> Erfolg
$ ping heise.de -c 4 -M do -s 1464 --> Erfolg (Bem.: 1464+28=1492 bytes)
$ ping heise.de -c 4 -M do -s 1465 --> Fehlermeldung "Message too long, mtu=1492", 100% paket loss

Bei Gastzugang via LAN oder WLAN ergibt sich immer folgendes Bild:

Code:

$ ping fr.de -c 4 -M do -s 512 --> Erfolg
$ ping fr.de -c 4 -M do -s 1024 --> Erfolg (Bem.: 1024+28=1052 bytes)
$ ping fr.de -c 4 -M do -s 1025 --> Timeout, 100% packet loss
$ ping fr.de -c 4 -M do -s 1428 --> Timeout, 100% packet loss (Bem.: 1428+28=1456 bytes)
$ ping fr.de -c 4 -M do -s 1429 --> Fehlermeldung "Message too long, mtu=1456", 100% packet loss
Zum Vergleich bei heise.de (ebenso bei allen anderen von mir getesteten Sites, z.B. google.de, web.de, www.faz.net):
$ ping heise.de -c 4 -M do -s 512 --> Erfolg
$ ping heise.de -c 4 -M do -s 1428 --> Erfolg (Bem.: 1428+28=1456 bytes)
$ ping heise.de -c 4 -M do -s 1429 --> Fehlermeldung "Message too long, mtu=1456", 100% paket loss

(Bem.: Dies ist eine alte Linux Distribution, bei der das einfache "ping" immer "IPv4" macht (ansonsten muss man "ping6" verwenden), also gleichbedeutend mit dem "ping -4" aktueller Distributionen).

Hallo,

nur mal so eingeworfen.
Mal einen Windows-PC probiert oder ein MAC?

Gruß bon

Zitat von bon

nur mal so eingeworfen.
Mal einen Windows-PC probiert oder ein MAC?

Nein. Wüsste auch nicht was das bringen sollte. Es muss ja mit meinen Geräten funktionieren, und das tut es auch an allen anderen Internet-Anschlüssen außer an diesem.

Hallo,

hat AVM schon geantwortet?

Gruß bon

Hallo,

danke für deine Rückmeldung.

Gruß bon

Ich denke, wir müssen nicht alles verstehen, vor allem weil es ja auf deinem Heimrechner auch nicht funktionierte, und der wurde sicher nicht von Samsung hergestellt.

Und Nokia hätte sie zwar nicht zurücknehmen müssen, aber einen kostenlosen Bugfix zur Verfügung stellen, der das Problem behebt. Aber ich hatte damals kein Nokia (im Gegensatz zu meiner Frau), sondern ein Siemens, erst das S3, dann das S10.
Funfact, sofern nicht expilzit im Smartphone das Voice over LTE ausgewählt wird, nutzt man immer noch das alte GSM-System zum Telefonieren. Und sollte das immer noch auf dem Nokia-Bug berzuhen würde ich sagen, dass der sich wohl hartnäckig hält
Ein Samsung abe ich jetzt aktuell auch, denn ich bin der Althandyaufbraucher in der Familie, und so hat das S20 letztlich doch zu mir gefunden. Zuvor hatte ich ein LeEco (das LeMax2 in Rosegold) und ein OnePlus 5T