ubuntuusers.de

Hi,

es scheint bei mir wie verhext zu sein. Bei einigen ausgewählten Webseiten passiert nicht viel, wenn man sie aufruft. Erst wenn man mehrmals auf Reload klickt und nach sehr viel Geduld baut sich vielleicht die Seite mal auf. Das Symptom tritt auf allen (K)Ubuntu-Systemen in meinem LAN auf, allerdings nicht unter Windows (auf gleicher Hardware).

Ein Blick auf die Logs vom Wireshark während der Anforderung solcher Webseiten (z.B. http://www.geocaching.com) offenbart die wahrscheinliche Ursache:
[TCP segment of a reassembled PDU] und [TCP Dup ACK x#y] wechseln sich lustig ab (Beispiel-Logfile im Anhang). Es sieht also aus, als würden die ACKs nicht zum Webserver gelangen und der damit Retransmissions anstoßen. Irgendwie dumm...

Jetzt ein kleiner Ausflug in meine Netzwerktopologie:

WAN --- DSL-Modem --- Router --- Switch --- Client A
                                    |------ Client B
                                    `------ ...

Router: OpenBSD mit NAT
Clients: Kubuntu 7.04 PC/Notebook

MTU im LAN ist überall 1500, auf der DSL-Leitung natürlich 1492. Mehr Daten gebe ich gerne auf Anfrage.

Vielleicht kann mir ja mal jemand einen heißen Tip geben, woran das liegen kann.

Gruß, Smertios.

Woran es liegt weiß ich auch nicht - aber deine ACKs kommen schon durch (erkennst du schon leicht daran, dass dir die Gegenseite die Pakete ACKt).
Es scheitert daran, dass du falsche Checksummen setzt.

Am Anfang siehst du es schön - die ersten drei Pakete sind der sogenannte Three-Way-Handshake (hier announced du übrigens 1460B MSS - oder korrigiert das dein Router? Mehr als 1452B gehen bei PPPoE nämlich nicht (MSS ist MTU - 20B (TCP-Header) - 20B (IP-Header)). Der geht auch gut.
Das 4. Paket markiert tcpdump dann schon als fehlerhaft (falsche checksumme), und das kommt von dir.
Den Rest verstehe ich ehrlich gesagt nicht wirklich 😉, ich vermute, dein Router spielt hier mit. Die ACKs gehen jedenfalls alle durch.

Da dein Router (wahrscheinlich) die Pakete manipuliert wäre ein dump vom router aussagekräftiger (tcpdump kann auch im binary-Format loggen, musst nicht sowas bloatiges wie wireshark dadrauf klatschen).

Ich habe mal am Router nen tcpdump auf tun0 angeschmissen und den Traffic mitgeloggt. Die von meiner Seite angezeigte MSS ist wieder 1460 Bytes. Die reinkommenden Pakete sind allerdings alle 1484 Bytes groß.

Die "inkorrekten" Prüfsummen kommen wahrscheinlich vom sogenannten TCP Checksum Offloading, d.h. die Prüsummenberechnung wird in Hardware auf der Netzwerkkarte vorgenommen, weshalb libpcap sie als "falsch" (weil noch nicht berechnet) sieht. Inwieweit das Ursache für das Problem sein kann, kann ich nicht beurteilen. Würde ich aber mal ausschließen, denn sonst würde es wohl mit allem Traffic Probleme geben, nicht nur mit einigen Webseiten. MTU/MSS scheint mir da ein viel naheliegenderer Kandidat zu sein.

Smertios hat geschrieben:

Ich habe mal am Router nen tcpdump auf tun0 angeschmissen und den Traffic mitgeloggt. Die von meiner Seite angezeigte MSS ist wieder 1460 Bytes. Die reinkommenden Pakete sind allerdings alle 1484 Bytes groß.

Ja, ihr einigt euch auch auf eine MSS von 1440B.

MTU/MSS scheint mir da ein viel naheliegenderer Kandidat zu sein.

Naja, das kannst du leicht ausschließen (allerdings glaube ich da nicht drann, da du das Problem dann unabhängig vom OS haben müsstest).
Wie du pf beibringst die MTU (bzw. MSS) zu limitieren weiß ich nicht.

Grundsätzlich hast du 2 Möglichkeiten:
1. MTU des If anpassen
2. iptables den TCP-Header entsprechend modifizieren lassen

Ich würde letzteres nehmen, damit du innerhalb deines Netzes die volle MTU hast (ist zwar jetzt nicht der riesen performancegewinn, aber warum was verschenken 😉).

Das machst du mit

/sbin/iptables -t mangle -A POSTROUTING -d ! 10.0.0.0/24 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1200

Dein Netz (hier beispielhaft 10.0.0.0/24) natürlich entsprechend anpassen.
Damit setzt du die mss fest auf 1200B.

Sinnvoller ists natürlich das mit pf direkt auf dem Router zu machen - allerdings weiß ich nicht, wie die entsprechende Syntax pf's hier lauten. Es geht aber in jedem Fall (und sinniger ist eigentlich ein '--clamp-mss-to-pmtu', aber das soll ja hier nur zum testen sein, und bevor uns hier jetzt an irgendeiner Stelle von amoklaufenden Firewall-Cowboys geblocktes ICMP auf die Füße fällt ists besser hier ersteinmal die Fehlerquelle einzugrenzen 😉).

Haenschen hat geschrieben:

Grundsätzlich hast du 2 Möglichkeiten:
1. MTU des If anpassen
2. iptables den TCP-Header entsprechend modifizieren lassen

Ich habe mal den optimalen Weg gewählt und die MSS auf dem Router durch pf anpassen lassen. Wenn ich z.B. MSS auf 1200 stelle, dann sehe ich am externen IF Pakete der Länge 1240 reinpurzeln (was ja so erwartet ist). Am Client kommen dann Pakete mit 1254 Byte Länge an (was auch immer diese zusätzlichen 14 Bytes sind). Die Modifikation funktioniert also erstmal.

Das Problem hierbei ist nur, die Maßnahmen haben keine meßbare Wirkung. Soll heißen, die fragliche Website baut sich weiterhin nicht sauber auf. 😠

Gefunden! 😀

Ich glaub, ich hab das Problem. Es lag wohl doch am Checksum Offloading. Scheint ein Bug im e1000-Treiber sein (hab Intel GBit Karten drin), ähnlich diesem.
Deaktiviert man all die lustigen Features der Hardware, vor allem aber tx-offload und rx-offload, dann sieht das so aus:

# ethtool -k eth0
Offload parameters for eth0:
Cannot get device udp large send offload settings: Operation not supported
rx-checksumming: off
tx-checksumming: off
scatter-gather: off
tcp segmentation offload: off
udp fragmentation offload: off
generic segmentation offload: off

Und voilá, bisher bauen sich alle Problemseiten anstandslos auf. Habe nebenbei noch auf dem Router MSS auf 1452 am tun0 festgetackert, damit die globale Config sauber ist.

Danke für die Hinweise, die mich letztendlich zum Ziel geführt haben.

Gruß, Smertios.

Smertios hat geschrieben:

Und voilá, bisher bauen sich alle Problemseiten anstandslos auf.

Hehe - kaum beseitigt man die Bugs, schon läufts ☺

Habe nebenbei noch auf dem Router MSS auf 1452 am tun0 festgetackert, damit die globale Config sauber ist.

Würde ich nicht machen - es könnte auch Hosts geben, die eine MTU < 1480B haben.
Das Buzzwort lautet hier Path MTU Discovery (PMTUD oder auch PMTU); mit iptables machst du das über '... -j TCPMSS --clamp-mss-to-pmtu'. Theoretisch sollte es auch ohne klappen, aber hier grätschen wieder Firewall-Cowboys, die blind ICMP blocken, rein.

Wenn ich die manpage von pf richtig verstehe, sollte die Option max-mss nur eine maximale MSS erzwingen. Damit müßte die Kommunikation mit Hosts kleinerer MTU anstandslos funktionieren.
Ich kann aber trotzdem mal auf dem Client iptables installieren und die entsprechenden Pakete 'manglen'. Mal sehen, ob ich einen Unterschied merke.

Smertios hat geschrieben:

Wenn ich die manpage von pf richtig verstehe, sollte die Option max-mss nur eine maximale MSS erzwingen. Damit müßte die Kommunikation mit Hosts kleinerer MTU anstandslos funktionieren.

Jipps, verstehe ich auch so. Ich war nur über das "festgetackert" in deinem Posting gestolpert und habe es so interpretiert, dass du immer eine mss von 1452 erzwingen willst. Das würde den 3way-handshake erfolgreich verhindern, wenn die Gegenseite nicht so hoch gehen kann/will.

Dann würd ich mir auch in jedem Fall den TCPMSS-Hack über iptables schenken, der ist nämlich eigentlich ziemlich unschön.