[gelöst]Minderwertiges ungeschirmtes LAN-Kabel: keine htpps-Seiten

[Ecki-No1]

Gestern war ich bei einem Kunden mit folg. Problem.
altes Notebook mit XP im Schlafzimmer
neues Notebook mit XP im Schlafzimmer
Speedport irgendwas im Wohnzimmer

Irgendein Kumpel von ihm, hatte ihn vor längerer Zeit ein "LAN"-Kabel gebastelt, welches durch ein 5 mm Loch in der Wand passt.
Es wurde eine 4-adrige Telefon-Anschlussschnur auf 2 LAN-Stecker gekrimpt.

Mit dem alten Notebook lief alles.
Das neue Notebook ließ keine login-Versuche auf HTTPS-Seiten zu (Bank XYZ, Web.de)
Per WLAN ging es dann.
Habe dann zum Test ein normales LAN-Kabel zwischen Notebook und Speedport gesteckt, und jetzt gingen auch alle HTPPS-Seiten.

Frage: Wie ist das zu erklären? Fing dieses Kabel etwa zu viele Störungen ein?
Normales Surfen, AVIRA-Updates usw. funktionieren mit dem "LAN"-Kabel.

 

[Feuer-Fritz]

Das hört sich zeimlich interessant an, mal sehen, was dabei raus kommt.

Alle noch so primitiven Versuche, die ich bisher unternahm in der Richtung hatten keinerlei feststellbare Nebenwirkungen...

 

[Ecki-No1]

Naja, als ich die LAN-Karte auf 10 MBit full-duplex zwang, ging es einigermaßen.

 

[Feuer-Fritz]

Jo, das habe ich bei meinen "Baupfuschereien" zu Testzwecken auch nicht gemacht, das lief immer so.

 

[chked]

Ein solches Flachbandkabel ist für LAN so ziemlich das ungeeignetste, was man sich vorstellen kann, da die Adern parallel laufen und nicht verdrillt sind. Der Einfluss der Schirmung wird oft überschätzt. Lt Wikipedia sind mehr als 90% der weltweit eingesetzten Netzwerkkabel ungeschirmt.
Aber dass gerade https-Seiten nicht funktionieren, ist doch sehr seltsam. https wird doch nur als etwas anders "formatierte" Payload im Ethernet übertragen.

 

[udosw]

Das neue Notebook ließ keine login-Versuche auf HTTPS-Seiten zu (Bank XYZ, Web.de)
Per WLAN ging es dann.

Prüf mal die MTU-Einstellungen der beteiligten Geräte. Ich kenne den Effekt, dass bestimmte https-Seiten nicht gehen, wenn die MTU zu groß ist (z.B. 1500), weil die Gegenstellen evtl. keine fragmentierten Pakete zulassen.

Ein wirklicher Zusammenhang mit dem Kabel erscheint extrem unwahrscheinlich, evtl. ein Folgefehler in Richtung Paketverluste oder Fragmentierung.

 

[Ecki-No1]

Prüf mal die MTU-Einstellungen der beteiligten Geräte.

Hm, kann ich wahrscheinlich nicht testen. Aber wie oben geschrieben, mit einem richtigen LAN-Kabel ging es ja dann. Wenn es mit dem Kabel nicht zusammenhängen sollte, wird sich der Kunde mit Sicherheit wieder melden ... und ich prüfe/optimiere die MTU-Einstellungen.

 

[gandalf94305]

Das ist überhaupt nicht überraschend. Wenn in einem verschlüsselten Paket auch nur ein Bit umfällt, kann man es unter Umständen nicht decodieren. Checksumming hilft hier auch nicht mehr, wenn es häufigere Fehler sind.

Ich gehe davon aus, daß das defekte Kabel bei http eine Menge Retransmissions hatte, um letztlich die Seite zusammen zu bekommen. Bei https wäre allerdings ein Fehler in einer end-to-end verschlüsselten Übertragung schon fatal, so daß die Beobachtung, daß https-Seiten nicht gehen, nur belegt, daß die Fehlerwahrscheinlichkeit in einer typischen Paketgröße (wahrscheinlich um die 1,4 kB) bereits um die 100% ist.

Über dieses Kabel würde ich nicht versuchen, einen Linux-Kernel von irgendwo her herunterzuladen ;-)

--gandalf.

 

[Ecki-No1]

Danke gandalf.
Das habe ich sogar verstanden und klingt schlüssig.
Also war die Idee das "LAN"-Kabel gegen ein LAN-Kabel (welches den Namen auch verdient) zu tauschen, schonmal sinnvoll.

 

[gandalf94305]

Genau... ein LAN-Kabel anstelle des Lahm-Kabels :hehe:

 

[sven@mainz]

Das würde vermutlich so einige seltsame Dinge erklären, die hier schon geschildert wurden. An die Sache, daß bei Bit-Fehlern https gleich abbricht, habe ich auch nicht gedacht.

 

[chked]

Bitfehler werden schon von der unter dem https-Protokoll liegenden TCP-Schicht erkannt und ggf. durch Wiederholung korrigiert. Bei https ist allerdings gegenüber http mehr "Kommunikation" durch Zertifikat-Austausch usw. notwendig, wodurch es eher zum Abbruch der Verbindung durch Timeouts kommen kann.

 

[Ecki-No1]

Genau, der "Ladebalken" bewegte sich einfach nicht weiter - irgendwann wäre dann der timeout gekommen.

Fazit: Es geht nichts über ein gescheites LAN-Kabel.
Um LAN-Kabel-Probleme einzugrenzen - nehme man WLAN.