* Dienstag, 23. Oktober 2001 um 21:33 (+0200) schrieb Matthias Kleine:
wieder einer, der hier aufgelaufen ist. Auch ich (wie schon andere vor mir, habe die Archive schon durchwühlt) komme mit frisch eingerichtetem DSL nicht auf bestimmte Webseiten, und auch bei mir funktioniert POP3 bei GMX nicht.
Kannst du mal die URLs von einigen der nicht erreichbaren Webseiten posten? POP3 von GMX habe ich gerade von einem Client mit Netscape 4.7X ausprobiert -- funktioniert hier.
Die bisherigen Maßnahmen:
- mtu von eth0 und ppp0 auf 1492 gesetzt
Lass die MTU der ethX auf 1500, insbesondere, wenn dein ADSL-"Modem" an einen Hub angeschlossen ist. MTU/MRU von ppp0 auf 1492 ist O.K., aber IMHO sind die Einstellungen ohne Bedeutung, da der PPP-Server der Telekom die MTU/MRU sowieso immer auf 1492 aushandelt...
- diverse iptables - Versuche, z.B.
$ iptables -t nat -A POSTROUTING -o ppp0 -p tcp --tcp-flags SYN,RST SYN \ -m tcpmss --mss 1453: -j TCPMSS --set-mss 1452
Ob die Postrouting-Chain die richtige Chain für das MSS-Clamping ist, kann ich nicht beurteilen, und den Mark-Parameter erst recht nicht...
$ iptables -A FORWARD -p tcp -o ppp0 --tcp-flags SYN,RST SYN -j TCPMSS \ --clamp-mss-to-pmtu
So funktioniert es hier bei mir.
Leider hat's das alles nicht getan. Ist denn hier kein GMX'ler mit DSL, der die Sache schon zum Laufen gebracht hat ;-) ?
Ja hier, gerade eben.
- einerseits ist immer von der mtu die Rede, aber die direkte Konfiguration des Interfaces mittels ifconfig ist wohl trotzdem nicht der Königsweg. Warum?
Einzig relevant für PPPoE (T-DSL) ist das PPP-Interface. Die Netzwerkkarte braucht -- wenn sie nur am ADSL-Modem hängt -- (theoretisch) weder IP noch MTU. Die MTU/MRU des ppp0 wird während des Verbindungsaufbaus per LCP vom pppd ausgehandelt und gesetzt.
- zweitens ist von einem DSL-Overhead die Rede. Geht es hier auch um die mtu?
Ja, PPPoE "verbraucht" 8 Bytes der max. Ethernet-Nutzlast von 1500 Bytes, so dass für PPP nur noch 1492 Bytes (=MTU/MRU) bleiben.
Wo liegt das Problem?
Hm, es ist mir jetzt ein bischen zu spät, um das ausführlich zu diskutieren, zumal die Ursache des Problems wohl noch nicht 100%-ig auszumachen ist. Nur soviel: Das Problem tritt auf bei Servern mit "Path-MTU-Discovery" (PMTUD). Solche Server versenden ihre Antwortpakete mit gesetztem DF-Bit (Don't Fragment). Treffen solche Pakete auf einen Router, dessen "Next-Hop-MTU" zu klein für ein solches Paket ist, verwirft der Router das Paket und schickt eine ICMP-Message zurück an den Server (sinngemäß: "Datagramm too large, but DF-Bit set"). Der Server sollte dann darauf die Daten erneut in kleineren Paketen senden. Tja, aber irgend etwas an diesem System funktioniert bei PPPoE nicht. Entweder bekommt der Server die ICMP-Message nicht oder er reagiert darauf nicht bzw. falsch.
- drittens, welche der oben vorgeschlagenen iptables Flags haben im Zusammenhang mit der Problematik eine Bedeutung und warum?
Dass MSS-Clamping setzt die TCP-Option MSS (Maximum Segment Size) auf einen Wert von 1452 Byte, so dass die PMTUD-Server in jedem Antwort-Paket nur max. 1542 Bytes Daten senden. Plus je 20 Bytes für IP- und TCP-Header ergibt das dann eine Paketgröße von 1492 Bytes, so dass die Pakete durch die PPP-Verbindung gehen und der Router nie "Datagramm too large, but DF-Bit set"-ICMP-Messages erzeugen muss.
Und freilich - was löst eigentlich das Problem???
"Eigentlich" sollte MSS-Clamping das Problem lösen. Ich kann es
hier auch nicht feststellen...
Eventuell gibt es aber bei dir und denn anderen Betroffenen ein
anderes Problem: ECN.
Vielleicht sind die SuSE-Kernel mit ECN-Unterstützung erzeugt worden
und ECN wird standardmäßig aktiviert.(?)
Probiert doch mal 'echo 0 > /proc/sys/net/ipv4/tcp_ecn'.
Gruß
Andreas
--
Andreas Könecke "Andreas Koenecke