Diese Website existiert nur weil wir Werbung mit AdSense ausliefern.
Bitte den AdBlocker daher auf dieser Website ausschalten! Danke.

[GELÖST] Einige https-Seiten Laden nicht unter Leap, aber unter Windows

Alles rund um das Internet, Internet-Anwendungen (E-Mail, Surfen, Cloud usw.) und das Einrichten von Netzwerken einschl. VPN unter Linux

Moderator: Moderatoren

Antworten
wichita_c12ca
Member
Member
Beiträge: 114
Registriert: 5. Okt 2008, 21:27

[GELÖST] Einige https-Seiten Laden nicht unter Leap, aber unter Windows

Beitrag von wichita_c12ca » 12. Mär 2016, 16:52

(Crosspost: https://www.opensuse-forum.de/thread/36 ... r-windows/ )


Hi zusammen,

ich hab ein seltsames Problem mit openSUSE Leap 42.1. Ich kriege auf einigen Webseiten reproduzierbar Timeouts.
Zwei Beispiele:

https://openshift.redhat.com/app/login
Lädt ordnungsgemäß. Ich kann mich einloggen und und auch auf "Settings" klicken. Danach kann ich aber einen beliebigen Link anklicken und bekomme einen Timeout. Wenn ich dann wieder versuche "https://openshift.redhat.com/app/login" zu laden, geht auch das nicht mehr.
Nach einem Browser-Neustart lädt die Seite wieder, bis zum zweiten Klick nach dem Login.

https://www.mendeley.com/sign-in/
Lädt auch, aber wenn ich meine Login-Daten eingebe und auf "Sign in" klicke bekomme ich auch wieder einen Timeout.

Jetzt das besonders eigenartige:
Das Problem tritt unter openSUSE 42.1 reproduzierbar mit allen Browsern auf, die ich getestet habe (Firefox, Chrome, Midori). Auch eine komplett neue Installation von openSUSE zeigt die gleichen Symptome.
Wenn ich auf dem selben Rechner jedoch Windows 10 starte, funktionieren alle Seiten problemlos. Sowohl mit Chrome, als auch mit Internet Explorer.

Was mir auffällt, ist, dass beide Beispiele, die mir aufgefallen sind, https-Seiten sind. Ob das Problem hierauf beschränkt ist, kann ich jedoch leider nicht sagen.
Ich habe schon drüber nachgedacht, ob es an meinem Internetprovider liegen könnte. Ich bin bei Unitymedia und bekomme vom Provider nur IPv6-Adressen zugewiesen. IPv4-Anfragen werden nach meinem Wissen mit hunderten weiteren Kunden über eine NAT geschleust. Das würde allerdings nicht erklären, warum es mit Windows 10 funktioniert.

Hat jemand eine Idee wo ich noch nach den Ursachen suchen könnte?


EDIT:
Wenn ich die Seiten über einen Webproxy nutze (z.B. https://hide.me/de/proxy ) funktionieren beide Seiten auch unter openSUSE problemlos.

EDIT2:
Netzwerkinfos - collectNWData.txt: http://paste.opensuse.org/48140192
Zuletzt geändert von wichita_c12ca am 17. Mär 2016, 22:59, insgesamt 4-mal geändert.

Werbung:
Benutzeravatar
Jägerschlürfer
Moderator
Moderator
Beiträge: 4498
Registriert: 1. Jul 2005, 12:22
Wohnort: nahe Würzburg

Re: Einige https-Seiten Laden nicht unter Leap, aber unter Windows

Beitrag von Jägerschlürfer » 12. Mär 2016, 17:07

hast du auch noch andere https Seiten die nicht funktionieren, bei denen man sich nicht anmelden muss?
>Linux-Club Foren FAQ< >LC-Wiki<

Know your enemy and know yourself Sun Tzu

wichita_c12ca
Member
Member
Beiträge: 114
Registriert: 5. Okt 2008, 21:27

Re: Einige https-Seiten Laden nicht unter Leap, aber unter Windows

Beitrag von wichita_c12ca » 12. Mär 2016, 17:13

Leider nicht. Das sind die beiden Beispiele, bei denen mir das Problem aufgefallen ist, weil ich diese regelmäßig nutze.

Achso, dabei fällt mir gerade auf, dass ich folgendes vergessen habe (werde ich oben einfügen):
Wenn ich die Seiten über einen Webproxy nutze (z.B. https://hide.me/de/proxy ) funktionieren beide Seiten auch unter openSUSE problemlos.

EDIT:
Du könntest auf www.bugmenot.com gucken.
Für mendeley.com scheint folgender Login zu gehen:
Username: mend@pfui.ru
Password: 1234567

spoensche
Moderator
Moderator
Beiträge: 7487
Registriert: 30. Okt 2004, 23:53
Wohnort: Siegen

Re: Einige https-Seiten Laden nicht unter Leap, aber unter Windows

Beitrag von spoensche » 12. Mär 2016, 19:03

Welchen Browser verwendest du?

wichita_c12ca
Member
Member
Beiträge: 114
Registriert: 5. Okt 2008, 21:27

Re: Einige https-Seiten Laden nicht unter Leap, aber unter Windows

Beitrag von wichita_c12ca » 12. Mär 2016, 19:21

In erster Linie Google Chrome (aus den google-repos), aber das Probel tritt wie gesagt mit allen Browsern auf, die ich getestet habe. Das bedeutet:
Firefox, Chrome, Midori

spoensche
Moderator
Moderator
Beiträge: 7487
Registriert: 30. Okt 2004, 23:53
Wohnort: Siegen

Re: Einige https-Seiten Laden nicht unter Leap, aber unter Windows

Beitrag von spoensche » 13. Mär 2016, 20:00

Es könnte mit den verwendeten Zertifikaten der Webseiten zusammen hängen. Hast du dir diese mal angesehen? Es könnte allerdings auch an der Browserkonfiguration liegen, z.B. eine ältere SSL-Version.

Vergleiche doch mal die Konfigurationen der Browser mit denen die unter Trojaner 10 von M$ verwendest

wichita_c12ca
Member
Member
Beiträge: 114
Registriert: 5. Okt 2008, 21:27

Re: Einige https-Seiten Laden nicht unter Leap, aber unter Windows

Beitrag von wichita_c12ca » 14. Mär 2016, 20:09

Unter Windows hab ich die gleiche Chrome-Konfiguration genutzt wie mit Chrome unter openSUSE. Problem tritt außerdem mit frischer openSUSE Installation mit unveränderten Browser-Konfigurationen auf.

Ich hab mal einen solchen fehlerhaften Ablauf bei openshift mit Wireshark geloggt. An den grünen HTTP-Einträgen sieht man schön, wie der klick auf Settings noch funktioniert, aber der nächste Klick schlägt fehl:
Bild

wichita_c12ca
Member
Member
Beiträge: 114
Registriert: 5. Okt 2008, 21:27

Re: Einige https-Seiten Laden nicht unter Leap, aber unter Windows

Beitrag von wichita_c12ca » 14. Mär 2016, 21:01

​Wireshark-log für den fehlschlagenden mendeley.com-login.
Scheinbar versuchen hier also beide Seiten ACKs zu senden, die nicht ankommen. die [FIN, ACK] pakete kommen dann aber direkt an. Hat dafür irgendwer eine mögliche Erklärung?
Bild

wichita_c12ca
Member
Member
Beiträge: 114
Registriert: 5. Okt 2008, 21:27

Re: Einige https-Seiten Laden nicht unter Leap, aber unter Windows

Beitrag von wichita_c12ca » 17. Mär 2016, 22:58

Lösung:

Das Problem hängt irgendwie mit der MTU und der DS-Lite Implementierung von Unitymedia zusammen.
http://www.networkworld.com/article/222 ... ssues.html Dieser Artikel gibt sehr viele gute Infos zu dem Thema her.

Die Lösung bestand darin im NetworkManager die MTU herunterzusetzen. Momentan habe ich sie auf 1200bytes und alles läuft stabil.

Antworten