Luca Bertoncello schrieb:
Heiko Schlittermann hs@schlittermann.de schrieb:
Wir sollten uns die Frage stellen, *warum* diese Pakete viel kleiner sind. Und vielleicht reichen kleinere Pakete ja auch schon für die beschriebene Verlangsamung - wenn ausreichend hohe Latenz da ist.
Genau! Ich kann leider die Frage "warum sind die Pakete viel kleiner" leider nicht beantworten...
Ich kenne das Problem eher andersherum, daß es vom Router geht, aber aus dem LAN nicht. Die Verkleinerung der MTU im pppoed (/etc/ppp/peers/dsl-provider: mtu <packetsize>) war der erste Schritt, das sollte bei dir schon ausreichen. Eine eth-MTU ist allgemein 1500, bei pppoe war die Grenze glaub ich bei 1394 oder noch niedriger. Das läßt sich mit einem Ping mit entsprechend großem Paketen austesten:
ping -s 1400 $ZIEL kann über pppoe nicht mehr gehen, dann langsam die Paketgrößen reduzieren bis es geht. So kannst du zuerst mit einem gut funktionierenden Ziel die Grenze der eigenen DSL-Leitung austesten und dann das Nadelöhr auf dem Weg zur Problemseite finden, zumindest die Größe davon.
Wo sich das Nadelöhr befindet findest du evtl. mit
traceroute [-I] $ZIEL <paketsize>
heraus. Allerdings nur, wenn alle Hosts auf dem Weg antworten. Da die Sparkassenseite aber nicht auf ein Ping reagiert, ist das auf dem Wege schlecht auszuloten.
Daß die Clientpakete schon kleiner sind, liegt wohl an der MTU-Einstellung des Clients.
Falls das nicht reicht kann noch ein
iptables -A FORWARD -p TCP --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
weiterhelfen. Die Sparkassenseite war übrigens schon immer eine Problemseite bei Paketgrößen und daher auch gut als Testseite zu "mißbrauchen". ;-)
Gruß Rico