ARCHIV 1999-2006

ARCHIV :: # 2996

MTU 1400

Kleiner Schalter, grosse Wirkung

Autor: thyl - Datum: 28.05.2004

Jahrelang habe ich mich damit herumgeschlagen, dass unter MacOSX hinter meinem Linux-DSL Router nicht alle Websites angezeigt wurden; tatsächlich einer der Gründe dafür, warum mein NeXTSTEP-System immer noch im Einsatz ist. Ich hatte schon mal den Tipp bekommen, dass vielleicht der Router mit der Ethernet-Paketlänge nicht zurechtkäme. Diese hatte ich stundenlang versucht, entsprechend einzustellen, ohne Ergebnis, und dann aufgegeben. (Ich liebe UNIX, aber es liebt mich nicht :-(()

Durch Zufall habe ich jetzt in den Netzwerk-Preferences von 10.3 bei Ethernet einen neuen Schalter gefunden, mit dem man die Paketlänge MTU einstellen kann. Flugs mal einfach auf 1400 statt 1500 Byte gesetzt, und auf einmal ging es! Nicht nur die Websites, sondern auch das automatische Updaten klappt wieder.

Der dicke Hund ist aber eigentlich, dass offensichtlich so viele Leute betroffen waren, dass Apple eben diesen Schalter in die Preferences aufgenommen hat (gerade diesen, aus all den möglichen Konfigurationsparametern für Ethernet) und dass das drei Jahre gedauert hat.

Was jemand mit nur einem Rechner gemacht hätte, weiß ich nicht, denn selbst wenn es bei Apples Knowledge Base schon früher eine Lösung gegeben hätte, hätte zumindest ich das nicht herausgefunden, denn da bin ich auch nicht hingekommen.

Kommentare

?? ging schon immer

Von: Henryk Richter | Datum: 28.05.2004 | #1
ifconfig en0 mtu 1460

All die Jahre so ein Ärger...

Von: zerocool | Datum: 28.05.2004 | #2
... und dabei hätte ein:
ifconfig eth1 mtu 1492
auf der Linuxbox vermutlich gereicht... ;)

All die Jahre so ein Ärger...

Von: zerocool | Datum: 28.05.2004 | #3
... und dabei hätte ein:
ifconfig eth1 mtu 1492
auf der Linuxbox vermutlich gereicht... ;)

Problem ist ja schon länger bekannt

Von: Martin | Datum: 28.05.2004 | #4
Allerdings hab ich noch immer nicht geblickt, ob man das auch machen muss, wenn man hinter nem Router sitzt. Das hängt dann wohl mit der Fragmentation zusammen. Ausserdem wärs ja schon cool, wenn man eine verlässliche Gegenstelle hätte, mit der man testen kann, ob man das Problem hat oder nicht.

Der blöde Schalter fehlt übrigens IMHO bei Airport - nobody knows why. Würde vielleicht "beweisen", daß das Problem nur bei direkter PPPoE-Einwahl auftritt, was über Airport etwas unwahrscheinlich erscheint :-).

war das...

Von: rené | Datum: 28.05.2004 | #5
nicht das was man mit broad band optimizer lösen konnte? ich hab den installiert und bei mir steht es schon auf 1500. soweit ich weiß verändert der bbo die paketlänge. aber genau weiß ich auch nix ;)

@Besserwisser ;-)

Von: Thyl (MacGuardians) | Datum: 28.05.2004 | #6
>ifconfig en0 mtu 1460

Genau, so was hab ich alles probiert, auf MacOSX, auf Linux, mit verschiedenen Werten etc....

Sag ich ja, UNIX mag mich nicht.

@Martin

Von: iLig | Datum: 28.05.2004 | #7
Das Problem tritt immer dann auf, wenn PPPoE im Spiel ist und man über einen Router an DSL angeschlossen ist. Die 8 Byte werden für den Protokolloverhead für PPPoE gebraucht. Wenn der Rechner direkt am modem hängt und PPPoE eingeschaltet ist wird der mtu Wert automatisch auf 1492 gesetzt.

@Martin

Von: iLig | Datum: 28.05.2004 | #8
Das Problem tritt immer dann auf, wenn PPPoE im Spiel ist und man über einen Router an DSL angeschlossen ist. Die 8 Byte werden für den Protokolloverhead für PPPoE gebraucht. Wenn der Rechner direkt am modem hängt und PPPoE eingeschaltet ist wird der mtu Wert automatisch auf 1492 gesetzt.

@Martin

Von: iLig | Datum: 28.05.2004 | #9
Das Problem tritt immer dann auf, wenn PPPoE im Spiel ist und man über einen Router an DSL angeschlossen ist. Die 8 Byte werden für den Protokolloverhead für PPPoE gebraucht. Wenn der Rechner direkt am modem hängt und PPPoE eingeschaltet ist wird der mtu Wert automatisch auf 1492 gesetzt.

@Martin

Von: iLig | Datum: 28.05.2004 | #10
Das Problem tritt immer dann auf, wenn PPPoE im Spiel ist und man über einen Router an DSL angeschlossen ist. Die 8 Byte werden für den Protokolloverhead für PPPoE gebraucht. Wenn der Rechner direkt am modem hängt und PPPoE eingeschaltet ist wird der mtu Wert automatisch auf 1492 gesetzt.

Fragen, Fragen, Fragen...

Von: Klaus Major | Datum: 28.05.2004 | #11
Hi iLig (immer schön langsam ;-),

tritt das Problem tritt immer dann auf, wenn PPPoE im Spiel ist und man über einen Router an DSL angeschlossen ist?

Werden die 8 Byte für den Protokolloverhead für PPPoE gebraucht?

Wird der mtu Wert automatisch auf 1492 gesetzt, wenn der Rechner direkt am modem hängt und PPPoE eingeschaltet ist?


Sorry, konnte wirklich nicht widerstehen :-D


Schönes Wochenende

Klaus Major

[OT] P-P-P Powerbook

Von: Yemeth | Datum: 28.05.2004 | #12
Wollte ich niemandem vorenthalten (Onkel Heise, bzw. Telepolis):

[Link]

LOL Spammer! (n/t)

Von: ColonelAsh | Datum: 28.05.2004 | #13
nt

Tja

Von: Tom | Datum: 28.05.2004 | #14
Wenn mann/frau einen gescheiten Router hat ist der MTU auch dort fix einstellbar. Ich arbeite schon seit Jahren mit dieser Methode! Dafür braucht es den Schalter im OSX nicht! Der ist wohl für all diejenigen gedacht, die nicht über einer Router mit dieser Funktion verfügen.

Schöne Pfingsten
Tom

MTU

Von: MetalSnake | Datum: 28.05.2004 | #15
Es gab/gibt doch auch ein Programm für OS X um den MTU Wert und viele andere einzustellen die man unter <10.3 nicht (per gui) einstellen konnte. Ich weiß aber nicht mehr wie das heißt und auch nicht wo es das gibt, hatte das mal auf irgendeiner Seite gefunden wo was über DSL Optimieren stand wo es dann auch eine kleine Mac sektion gab wo auf das Programm hingewiesen wurde.

@MetalSnake

Von: Zerwi | Datum: 28.05.2004 | #16
Das Tool, das Du meinst, heißt RMAC, ist japanischen Ursprungs und recht unbekannt. Habe ich benutzt und funktioniert super, wird aber jetzt nicht mehr benötigt.

MTU am Router und am Rechner oder nur am Router?

Von: Martin | Datum: 29.05.2004 | #17
Irgendwie ist meine Frage noch nicht gelöst. Wenn der Router den MTU umstellt, heisst das auch, daß er interne Pakete automatisch fragmentiert und kleinere draus macht?

Ach ja, von wegen tool: c't hatte da auch mal was gebaut, ich glaub, das konnte man dafür auch nutzen:

[Link]

@Klaus Major

Von: iLig | Datum: 29.05.2004 | #18
Ja ja! Komischerweise gibt Safari bei den Macguardians immer grundlos Fehlermeldungen aus. Nach dem vierten Versuch hab ich erst gemerkt, dass der Kommentar doch übertragen wurde. Beim nächsten mal denk ich hoffentlich drann. Zu deinen Fragen:

tritt das Problem tritt immer dann auf, wenn PPPoE im Spiel ist und man über einen Router an DSL angeschlossen ist?

Ja

Werden die 8 Byte für den Protokolloverhead für PPPoE gebraucht?

Ja, hab ich jedenfalls auf irgend so'ner Geekseite gelesen als ich mich selbst mit dem Problem rumgeschlagen hab, und klingt für mich logisch.

Wird der mtu Wert automatisch auf 1492 gesetzt, wenn der Rechner direkt am modem hängt und PPPoE eingeschaltet ist?

Ja


Sorry, konnte wirklich nicht widerstehen :-D

Ja

(c;

DSL-Modem -> AEBS -> W-LAN = MTU 1460 ?

Von: Mark Koch | Datum: 29.05.2004 | #19
Hat dafür jemand eine Erklärung?

Schlussendlich scheint T-Online immer noch Pakete > 1500 zu verwerfen. Meine Frage also, wo entsteht der zusätzliche Protokollaufwand? 1500 - 8 (PPTP) - 32 (???) = 1460 (die durchgehen)

@me

Von: Mark Koch | Datum: 29.05.2004 | #20
Sollte nat. PPPoE heißen... *schäm*

Schöne Pfingsten

Was die c't dazu meint

Von: Martin | Datum: 29.05.2004 | #21
Ich quote zur allgemeinen Aufklärung mal unverschämterweise eine Passage aus einem knapp zwei Jahre alten c't-Artikel:

"Das Problem hat mit der Maximum Transfer Unit (MTU) zu tun, die beim für DSL eingesetzten PPPoE die Paketgröße auf 1492 Byte limitiert. Die Client-Rechner sehen aber lediglich das lokale Netz mit einer MTU von 1500 und verwenden diese, um für TCP-Verbindungen die Maximum Segment Size (MSS) zu berechnen, die sie den externen Servern mitteilen. So kann es vorkommen, dass der Web-Server Pakete schickt, die zu groß für die PPPoE-Verbindung sind. Da mittlerweile fast alle Systeme Fragmentierung untersagen (DF-Bit im IP-Header), sendet der Router eine Kontrollmeldung an den Absender, dass das Paket zu groß war (ICMP: destination unreachable: need to fragment). Bei den betroffenen Servern verhindert jedoch eine falsch konfigurierte Firewall, dass der Absender das ICMP-Paket erhält, sodass er es immer wieder versucht - aber eben nur mit den zu großen Paketen, die nicht ankommen.

Um das Problem zu beseitigen, muss man auf allen betroffenen Clients die MTU herabsetzen. Ein Wert von 1472 hat sich bei unseren Versuchen als brauchbar erwiesen."

Ich finde, das erklärt eigentlich sehr genau, wo das Problem herkommt - Ach wenns die c't nicht gäb :-).

tja, wenn das alles währe...

Von: Georg Kipp | Datum: 29.05.2004 | #22
alle Theorie ist grau, praktisch gibt es immer wieder Probleme welche nicht vorgesehen sind:
trotz im WLAN-Router eingestelltem MTU 1492 bekommen auf einmal via WLAN angeschlossene Macs keine Apple Software-Aktualisierung mehr, immerhin: eBay läuft noch....
Keine Ahnung warum das so ist, aber aus völlig heiterem Himmel habe ich so 1x im Jahr das MTU-Problem, schön, daß dies unter Panther für Ethernet mittlerweile simpel konfiguriert werden kann. Hoffentlich gibt's auch unter Airport bald so einen schlichten Menüpunkt, ohne daß man sich jedesmal wieder mit der Materie zur MTU-Konfiguration via Startup-Skript befassen muß,
was ja so einfach ist (wenn man sonst nix besseres zu tun hat).

zu guter letzt ...

Von: mcj | Datum: 30.05.2004 | #23
... für alle die AirPort benutzen ein entsprechender Artikel aus der Apple KB, um ein kleines Script in die StartupItems zu tun, welches den MTU Wert beim Booten automatisch setzt (was RMAC uach macht):

[Link]

Gruss,m.

Schuld ist aber die Website

Von: Gaspode | Datum: 01.06.2004 | #24
Klar, das Problem tritt vor allem mit Routern und im Zusammenhang mit PPPoe auf.

Die eigentliche Ursache ist aber eine andere: Gewisse Websites können mit solchen Paketen nicht umgehen, antworten nicht oder fehlerhaft und der User wundert sich warum nix kommt. Prominentes Beispiel dafür ist gmx.de - eigentl. müsste man dort überall um Behebung bitten...