MTU-Mini-FAQ
Dominik Ruf
gerade zusammengeschustert...
Zu diesem doch Dauerbrenner-Thema fehlt uns ja bisher noch was brauchbares
in der FAQ, deshalb:
MTU-Mini-FAQ (für xDSL-Zugänge über PPPoE)
==========================================
Inhalt:
1. Einleitung und Begriffserklärungen
1.1 MTU
1.2 PPPoE
1.3 Zusammenhang MTU <-> PPPoE
1.4 MSS
2. Auswirkungen/Probleme
3. Abhilfe/Lösungsmaßnahmen
4. Links
4.X Die einzelnen Links, im Text als Verweis durch [4.X] gekennzeichnet.
1. Einleitung und Begriffserklärungen
1.1 MTU = Maximum Transmission Unit
Siehe auch [4.1].
Im Internet und auch in lokalen Netzen auf Ethernet Basis werden die Daten
in einzelnen Paketen (Ethernet Frames genannt) transportiert. Die maximale
Größe eines einzelnen Ethernet Frame Paketes ist 1518 Byte. Davon werden
14 Byte vom (Ethernet-) Header und 4 Byte von der Checksumme für das Frame
beansprucht, sodass also noch genau 1500 Bytes an Nutzdaten für ein solches
Ethernet Frame übrigbleiben. Deshalb ist die Maximum Transmission Unit (MTU)
einer Ethernet Schnittstelle (z.B. einer Netzwerkkarte im Rechner) 1500 Byte
groß. Diese Zahl gibt das größtmögliche IP Datenpaket an, das ohne
Fragmentierung (Aufsplittung in mehrere kleinere Pakete) über diese
Schnittstelle transportiert werden kann.
1.2 PPPoE Point-to-Point Protokoll over Ethernet
Siehe auch [4.2], [4.3] und [4.4].
Das Point-to-Point Protokoll stellt einen von Zugangsprovidern gerne
genutzten Standard für Punkt-zu-Punkt Verbindungen (z.B. zwischen dem
Einwahlrechner des Providers und dem PC des Kunden) dar. Viele xDSL Provider
nutzen daher dessen Erweiterung PPP over Ethernet für den Zugang. Wie der
Name schon sagt, wird die Punkt-zu-Punkt Verbindung über eine Ethernet
Verbindung hergestellt.
1.3 Zusammenhang MTU <-> PPPoE
Siehe auch [4.1].
"Normalerweise" würde man also für die Ethernet Verbindung PPPoE eine
MTU von 1500 Byte (siehe [1.1]) verwenden. Jedoch benötigt das PPPoE
Protokoll selbst auch 6 Byte zusätzlich und das PPP Protokoll nochmals
2 Byte. Deshalb ist also die korrekte MTU für eine PPPoE Schnittstelle
1492 Byte [1500 - (6 + 2)].
Genaugenommen (siehe auch [4.5]) sollte die MTU bei PPPoE genau 8 Byte
weniger (der zusätzliche PPPoE Protokoll Header) als jedes Interface zwischen
dem eigenen Rechner und dem Ziel sein. "Normalerweise" sollten alle Router
auf eine MTU von 1500 konfiguriert sein (siehe [1.1]), sodass 1492 korrekt
sein sollte. Trotzdem kann es aber mal vorkommen, dass sich ein Router nicht
daran hält. Abhilfe schafft hier nur ein ständiges Verringern der eigenen MTU,
bis es "funktioniert".
1.4 MSS = Maximum Segment Size
Siehe auch [4.1].
Während sich die MTU auf alle IP Pakete bezieht, gibt es den Begriff
der Maximum Segment Size (MSS) nur für TCP Pakete (also z.B. nicht für UDP).
Beim Aufbau einer TCP Verbindung kann jede Seite optional die
bevorzugte/gewünschte MSS angeben. Die MSS gibt die Größe der reinen
Nutzdaten eines TCP Paketes an. Im Regelfall wird dies die MTU (siehe oben)
minus 40 Byte (das ist genau die Größe der TCP und IP Header) sein, also
1460 Byte für Ethernet Verbindungen. Abzüglich der PPPoE Header (8 Byte,
siehe [1.3]) ergibt sich also eine MSS von 1452 Byte für PPPoE Verbindungen.
2. Auswirkungen/Probleme (bei "falscher" - will meist heißen: zu großer - MTU)
Siehe auch [4.1] und [4.7].
Manche Webseiten funktionieren/laden nicht richtig.
Der Internet Explorer zeigt bei diesen Seiten die Fehlermeldung
"Die Seite kann nicht angezeigt werden".
Der Browser bleicht bei diesen Seiten mit der Meldung
"...contacted, waiting for reply!" stehen.
Das Paradebeispiel sind die Seiten von GMX.
Ebenso kann z.B. die Post nicht via POP3 von GMX abgeholt werden.
Gründe:
a) Diese Websites blocken den (wichtigen) ICMP Datenverkehr, mit welchem
gemäß dem Path MTU Discovery Standard eine "automatische" Erkennung der
jeweils besten MTU möglich wäre. Eine genaue Erklärung wie das funtioniert
würde jedoch hier den Rahmen sprengen. Der interessierte Leser sei deshalb
auf die Dokumente [4.8] - [4.11] verwiesen.
b) Die jeweiligen Daten (die Webseiten bzw. die E-Mails) sind größer als die
("falsch") eingestellte MTU.
Zum genauen Ablauf dieses Vorgangs (und warum es dann nicht funktioniert)
verweise ich auf [4.1] (en) und [4.7] (de).
3. Abhilfe/Lösungsmaßnahmen
TODO
4. Links
4.1 [en] http://www.roaringpenguin.com/pppoe/als-pppoe-paper.pdf
Kapitel 4.5 The MTU
4.2 [en] http://www.faqs.org/rfcs/rfc1661.html
RFC 1661 - The Point-to-Point Protocol (PPP)
4.3 [en] http://www.faqs.org/rfcs/rfc2516.html
RFC 2516 - A Method for Transmitting PPP Over Ethernet (PPPoE)
4.4 [en] http://www.roaringpenguin.com/slides/pppoe-slides.pdf
PPPoE für Dummies. Three Thumbs up!
Neben dem "offiziellen" RFC auf jeden Fall Wert, gelesen zu werden.
4.5 [en] http://www.carricksolutions.com/pppoe.htm
PPPoE FAQ (auch viele andere gute Seiten zum Thema)
4.4 [de] http://www.adsl4linux.de/faq/
u.a. mit Abschnitten zur MTU
4.5 [en] http://www.linuxdoc.org/HOWTO/DSL-HOWTO/
u.a. mit Abschnitten zur MTU
4.6 [en] http://www.speedguide.net/editorials/packet_size.shtml
MTU, what difference does it make? [Allgemeines zur MTU]
4.7 [de] http://www.ruhr.de/home/nathan/FreeBSD/tdsl-freebsd.html
anschauliche Schilderung des Ablaufes und der Probleme mit der
MTU und MSS bei NAT
4.8 [en] http://www.faqs.org/rfcs/rfc1191.html
RFC 1191 - Path MTU Discovery
4.9 [en] http://www.faqs.org/rfcs/rfc2923.html
RFC 2923 - TCP Problems with Path MTU Discovery
4.10 [en] http://lartc.org/HOWTO/cvs/2.4routing/output/2.4routing-15.html#ss15.6
Circumventing Path MTU Discovery issues with per route MTU settings
4.11 [en] http://lartc.org/HOWTO/cvs/2.4routing/output/2.4routing-15.html#ss15.7 Circumventing Path MTU Discovery issues with MSS Clamping
Also:
Ok, ich weiß, der wichtigste Punkt [3] ist noch leer, kommt aber bald...
Die Zeilenlänge ist suboptimal, lässt sich aber auf Grund der Länge der URLs
nicht unbedingt ändern. - Noch bin ich ja genau bei 80. :-)
So, und jetzt warte ich darauf, doch bitte "verissen" zu werden. ;-)
Kritik erhelle mich, sodass es besser werden kann!
Sonstige Meinungen dazu?
Kürzen? (Wo?) Noch ausführlicher? (Wo?)
Fehlt was Wichtiges? (Was?)
Was ist falsch oder nicht gut/schön formuliert? (Wie besser?)
Dann mal gut'n8. :-)
Grüße Dominik
--
Genau. Das Konzept "Meine Postings nach dnq scheinen nicht anzukommen,
ich frage mal in dnq, ob das stimmt" enthält einen schwachen Punkt.
- Harald Effenberg in dnq
Andreas Schildbach
1. Auf welchen Rechnern muss ich die MTU veraendern, wenn es sich um ein
lokales Netz mit Router handelt?
Ich habe hier konkret den Fall:
Router: WinXP-Rechner mit ICS
Client: WinXP-Rechner
auf dem Router funktionieren die problematischen Seiten wie www.gmx.de,
www.spiegel.de einwandfrei.
auf dem Client tritt das bekannte Symptom auf.
Ich habe auf beiden Rechnern den T-DSL-SpeedManager installiert und die
Einstellungen optimieren lassen (eine andere Moeglichkeit die MTU unter XP
umzustellen kenn ich nicht).
2. Ist es noetig, die CSS auch umzustellen? Was passiert wenn man die CSS
"vergisst"?
Gruss,
Andreas
"Dominik Ruf" <domin...@stud.uni-karlsruhe.de> wrote in message
news:77n29a...@ID-136364.user.dfncis.de...
Dominik Ruf
> Wichtige Fragen, die sich mir stellen:
> 1. Auf welchen Rechnern muss ich die MTU veraendern, wenn es sich um ein
> lokales Netz mit Router handelt?
Hm... das gibt dann wohl das, was bei Punkt [3] "Lösungen" noch fehlt... ;-)
> Ich habe hier konkret den Fall:
> Router: WinXP-Rechner mit ICS
> Client: WinXP-Rechner
> auf dem Router funktionieren die problematischen Seiten wie www.gmx.de,
> www.spiegel.de einwandfrei.
> auf dem Client tritt das bekannte Symptom auf.
> Ich habe auf beiden Rechnern den T-DSL-SpeedManager installiert und die
> Einstellungen optimieren lassen (eine andere Moeglichkeit die MTU unter XP
> umzustellen kenn ich nicht).
www.speedguide.net verrät die "händische" Methode.
Also du hast mehrere Möglichkeiten (aber eine davon reicht):
a) Auf dem Router MSS-Clamping aktivieren (z.B. durch die Benutzung
vom RASPPPOE Treiber. Das richtig konfigurieren (Anleitung auf Roberts
Homepage) und die Client MTU auf 1500 belassen. Der Router hat dann
natürlich weiterhin MTU 1492 für das PPPoE Interface.
b) Wenn dein Router das nicht kann, musst du auf allen Clients die
MTU auf 1492 (oder wenn es dann noch nicht geht, noch niedriger)
setzen, z.B. 1452.
Zu b) hätte ich gerne noch Anmerkungen von "Leuten mit mehr Ahnung als ich".
Ist dem so, dass es ohne MSS Clamp auf einem Router mit MTU 1492 auf dem
Client funktionieren "sollte"? Ich bin mir da nicht sicher... Danke! :-)
> 2. Ist es noetig, die CSS auch umzustellen? Was passiert wenn man die CSS
> "vergisst"?
Du meinst MSS, oder? Die wird im Normalfall abhängig von der MTU
"automatisch" gewählt, da MSS = MTU - 40. - Stümmt dem so?!
> "Dominik Ruf" <domin...@stud.uni-karlsruhe.de> wrote in message
> news:77n29a...@ID-136364.user.dfncis.de...
Bitte führe dir mal http://www.afaik.de/usenet/faq/zitieren/ zu Gemüte.
Gruss Dominik
Robert Schlabbach
> b) Wenn dein Router das nicht kann, musst du auf allen Clients die
> MTU auf 1492 (oder wenn es dann noch nicht geht, noch niedriger)
> setzen, z.B. 1452.
>
> Zu b) hätte ich gerne noch Anmerkungen von "Leuten mit mehr Ahnung als
ich".
> Ist dem so, dass es ohne MSS Clamp auf einem Router mit MTU 1492 auf dem
> Client funktionieren "sollte"? Ich bin mir da nicht sicher... Danke! :-)
Wenn der Router bis zu 1492 Bytes grosse Pakete durch die weitergehende
Verbindung schicken mag, ja. Manche PPPoE-Software (z.B. der Enternet, der
Engel-Treiber unter Win9x, der XP-PPPoE) verwenden aber eine noch
niedrigere MTU...
> Du meinst MSS, oder? Die wird im Normalfall abhängig von der MTU
> "automatisch" gewählt, da MSS = MTU - 40. - Stümmt dem so?!
Ist so im RFC definiert (habe die Nummer gerade nicht zur Hand).
Gruss,
--
Robert Schlabbach
e-mail: nor...@cs.TU-Berlin.DE
Technical University of Berlin, Germany
Dominik Ruf
> Wenn der Router bis zu 1492 Bytes grosse Pakete durch die weitergehende
> Verbindung schicken mag, ja. Manche PPPoE-Software (z.B. der Enternet, der
> Engel-Treiber unter Win9x, der XP-PPPoE) verwenden aber eine noch
> niedrigere MTU...
Interessant. Kann man eigentlich sagen, dass die MTU für das PPPoE
Interface unter Windows-Systemen immer nur über den PPPoE Treiber und
nicht über die Windows Registry eingestellt wird? Diese also nur für
"gewöhnliche" Ethernet-Verbindungen zuständig ist?
> Ist so im RFC definiert (habe die Nummer gerade nicht zur Hand).
Merci. Dafür und auch für <a94s4r$tdk$00$1...@news.t-online.com> tauchst du
jetzt auch in der Mini-FAQ auf. Anschließend poste ich mal die aktuelle
Version, wobei ich aus Rücksicht auf die Bandbreite mal das weglasse, was
sich nicht geändert hat.
Im Anschluss werde ich dann noch anmerken, wo ich noch ein paar Kommentare
brauchen könnte... :-)
MTU-Mini-FAQ (für xDSL-Zugänge über PPPoE)
==========================================
Die aktuelle Version dieser Mini-FAQ ist online unter
http://ruf.2y.net/~dominik/txt/mtu-mini-faq.txt zu finden.
Inhalt:
1. Einleitung und Begriffserklärungen
1.1 MTU [leicht geändert]
1.2 PPPoE
1.3 Zusammenhang MTU <-> PPPoE
1.4 MSS
2. Auswirkungen/Probleme
3. Abhilfe/Lösungsmaßnahmen
3.1 Wie stelle ich die richtigen Parameter ein? [neu]
4. Links [ergänzt]
4.X Die einzelnen Links, im Text als Verweis durch [4.X] gekennzeichnet.
5. Danksagungen [neu]
5.1 Kommentare [neu]
1. Einleitung und Begriffserklärungen
1.1 MTU = Maximum Transmission Unit
[Nur ein bisschen umgestellt, aber am Textinhalt nichts verändert, deshalb
hier gekürzt.]
1.2, 1.3, 1.4
[nicht verändert]
2., 3.
[nicht verändert]
3.1 Wie stelle ich die richtigen Parameter ein?
3.1.1 Linux
$ ifconfig <device> mtu <wert>
$ man ifconfig
Hierbei sollte man beachten, dass das PPPoE <device> nicht ethX ist,
sondern pppX.
Der Roaring-Penguin (rp-pppoe) Treiber sollte die MTU automatisch auf
1492 Byte setzen, sodass keine weiteren Einstellungen (bzgl. der MTU)
notwendig sind.
Bei den Kernel-Treibern werden die Einstellungen in der Datei
/etc/ppp/options gesetzt. Die beiden Einträge heißen
mru 1492
mtu 1492
Eine Einstellung der MSS sollte bei keinem *nix System nötig sein,
da die MSS automatisch auf MTU - 40 Byte (TCP + IP Header) gesetzt wird.
3.1.2 OpenBSD
$ man ifconfig
Bzw. in der Datei /etc/ppp/ppp.conf die Einträge
set MTU max 1492
set MRU max 1492
3.1.3 FreeBSD
$ man ifconfig
Bzw. in der Datei /etc/ppp/ppp.conf die Einträge
set MTU 1492
set MRU 1492
3.1.4 Windows (allgemein)
MTU, MSS und andere Parameter werden in der Registry eingestellt.
Dies kann man entweder von Hand (mit dem Programm "regedit") machen,
oder über diverse "Tools", die einem diese Arbeit erleichtern.
Grundsätzlich gilt, dass Tools, die versprechen, die Verbindung "automatisch"
für DSL zu optimieren nur bedingt geeignet sind. Besser sind Tools, die es
erlauben, die einzelnen Parameter selbst zu setzen.
Empfehlenswertes Tool: DrTCP [4.15]
Wenn man den RASPPPOE Treiber [4.14] benutzt, kann man die MTU für die
PPPoE Verbindung über die "Eigenschaften" der Verbindung einstellen.
Genaueres findet sich in den README's, die der Software beiliegen und
auch auf der Homepage zu finden sind.
Ebenso ist der RASPPPOE Treiber der einzige Windows Treiber, der die
MSS Clamp Option beherrscht (wichtig, wenn der Windows PC als Router
für andere Clients im LAN fungiert).
3.1.5 Windows XP
Die MTU/MSS vom XP eigenen PPPoE Treiber lässt sich nicht einstellen, da
diese "fest" einprogrammiert ist. Die MTU/MSS für gewöhnliche
Netzwerkverbindungen werden genau so wie bei Windows 2000 eingestellt.
3.1.6 Windows 9x, ME und NT
Registry Einstellungen sind unter [4.12] zu finden.
3.1.7 Windows 2000
Registry Einstellungen sind unter [4.13] zu finden.
4. Links
4.1 - 4.11 [nicht verändert]
4.12 [en] http://www.speedguide.net/Cable_modems/cable_registry.shtml
DSL Registry Settings for Win 9x, ME and NT
4.13 [en] http://www.speedguide.net/Cable_modems/cable_reg_win2k.shtml
DSL Registry Settings for Windows 2000 and XP
4.14 [en] http://user.cs.tu-berlin.de/~normanb/
RASPPPOE Treiber von Robert Schlabbach. DER PPPoE Treiber!
4.15 [en] http://www.dslreports.com/front/drtcp.html
DrTCP, Tool zur Netzwerkoptimierung für Win 9x/ME/NT/2000/XP
5. Danksagungen
Dank für Anregungen und konstruktive Kritik geht an Robert Schlabbach,
Oliver Gobin und viele Andere.
5.1 Kommentare
Anregungen, Kommentare, Ergänzungen sind willkommen.
Bitte an Dominik Ruf, dominik+usenet (at) ruf.2y.net schicken. Danke.
<Ende - Gelände>
Ähm... Also:
Die *BSD Tipps sind von Oliver Gobin. Ich habe da keine Ahnung, ob das
stimmt. Ebenso habe ich von der Windows Geschichte ziemlich wenig Ahnung
und wäre deshalb dankbar, wenn mich da jemand korrigiert, sofern ich
irgendwo Müll geschrieben habe (oder man das besser formulieren könnte).
Kennt jemand noch andere empfehlenswerte Tools für Windows?
DFÜ-Speed finde ich nicht "so" doll, da es keine Unterstützung für W2K
hat und das auch nicht für zukünftige Versionen geplant ist. Außerdem
vermute ich, dass es nicht ganz so gut wie DrTCP ist. Aber wie gesagt,
ich kenne weder das eine, noch das andere persönlich. Deshalb sind
Kommentare erwünscht.
Kennt eigentlich jemand _deutschsprachige_ Seiten zu diesem Thema?
z.B. zu den Registry Einstellungen (aber auch anderes).
Merci, Dominik
--
^^^ DAS ist eine Signatur. ;-)
OjE kann das leider nicht. :-(
http://www.wschmidhuber.de/oeprob/ listet die bekannten Probleme von OE auf.
Norbert Micheel
"Robert Schlabbach" <nor...@cs.TU-Berlin.DE> schrieb im Newsbeitrag
news:a94sda$pm3$05$1...@news.t-online.com...
> Wenn der Router bis zu 1492 Bytes grosse Pakete durch die weitergehende
> Verbindung schicken mag, ja. Manche PPPoE-Software (z.B. der Enternet,
> der Engel-Treiber unter Win9x, der XP-PPPoE) verwenden aber eine noch
> niedrigere MTU...
Hi, Robert.
Könntest du mir das bitte etwas ausführlicher erläutern wie das beim
Engel-Treiber ist? Was das "niedrigere MTU verwenden" bedeuten soll?
Heisst das er überträgt nur kleinere Pakete?
Hast du das selbst überprüft?
Ich glaubte bisher, dass er Pakete der Länge 1492 Bytes überträgt...
Gruss Norbert
Norbert Micheel
"Dominik Ruf" <domin...@stud.uni-karlsruhe.de> schrieb im Newsbeitrag
news:77n29a...@ID-136364.user.dfncis.de...
> Hallo Beisammen,
>
> gerade zusammengeschustert...
>
> Zu diesem doch Dauerbrenner-Thema fehlt uns ja bisher noch was
> brauchbares
> in der FAQ, deshalb:
>
>
> MTU-Mini-FAQ (für xDSL-Zugänge über PPPoE)
> ==========================================
>
>
Hi, Dominik
Es wird wirklich Zeit, das dieses Thema mal _endgültig_ behandelt wird.
Dafür schon mal Danke für die Bemühungen.
Nun ein paar allgemeine Anmerkungen von mir.
Ich finde man sollte immer vom "einfachen Normalfall" ausgehen.
Für mich heißt das zunächst, zwei Rechner bauen eine TCP-Verbindung auf.
Dabei tauschen sie ihre MSS aus, die aus dem als MTU eingestellten Wert für
das Netzwerk-Medium ermittelt wird. Wäre das Internet nur eine Datenleitung
ohne Router, wäre damit alles erledigt. Die beiden Rechner würden sich auf
den kleineren der beiden MSS-Werte einigen und ihre Pakete übertragen.
Jetzt gibt es aber im Internet leider "Engstellen" zwischen den Routern
durch die nur kleinere Pakete mit weniger als 1500 Bytes "passen".
Wenn ich mich in einem lokalen Netz befinde, das über einen Soft- oder
Hardware-Router per PPPoE Zugang zum Internet hat, so ist auch diese PPPoE
Verbindung vom Router zum meinem Provider (und auch der umgekehrte Weg) eine
solche "Engstelle".
Das Problem der "Engstellen" wird eigentlich von "PMTU Discovery" gelöst,
wenn alle Router es korrekt implementieren/zulassen würden.
Andereseits wird das Problem (von einem gewissen Standpunkt aus) ja auch nur
von "PMTU discovery" verursacht, weil ja nur deswegen das "don't
fragment"-Flag gesetzt wird, oder?
Da man die Router im Internet nicht unter Kontrolle hat, bleibt einem zur
Problemlösung nur der/die eigene(n) Rechner. Man muss selbst dafür sorgen,
dass alle Pakete klein genug sind, um jede "Engstelle" im Internet
zu passieren.
Die einzige Möglichkeit auch den entfernten Rechner zu beeinflussen ist der
Austausch der MSS-Werte beim Verbindungsaufbau.
1. Möglichkeit:
Auf allen Rechnern im LAN den MTU-Wert klein genug wählen.
2. Möglichkeit:
Auf dem Router "MSS-Clamping" durchführen.
Konkrete Anmerkungen:
> 1.3 Zusammenhang MTU <-> PPPoE
>
> Siehe auch [4.1].
>
> "Normalerweise" würde man also für die Ethernet Verbindung PPPoE eine
> MTU von 1500 Byte (siehe [1.1]) verwenden. Jedoch benötigt das PPPoE
> Protokoll selbst auch 6 Byte zusätzlich und das PPP Protokoll nochmals
> 2 Byte. Deshalb ist also die korrekte MTU für eine PPPoE Schnittstelle
> 1492 Byte [1500 - (6 + 2)].
>
> Genaugenommen (siehe auch [4.5]) sollte die MTU bei PPPoE genau 8 Byte
> weniger (der zusätzliche PPPoE Protokoll Header) als jedes Interface
> zwischen dem eigenen Rechner und dem Ziel sein.
Es wird einem Laien bestimmt nicht klar, was du mit diesen zwei Absätzen
meinst. Denn du sprichst einmal von der "MTU einer PPPoE-Verbindung", was
eine feste Zahl _ist_, nämlich 1492 und später davon "die MTU sollte...
sein..." und meinst damit was man dem Rechner mitteilen soll, welchen Wert
er als MTU benutzen soll. Wenn man 88 als MTU-Wert für die PPPoE-Verbindung
konfiguriert, so bleibt die MTU "einer" PPPoE-Verbindung weiterhin 1492.
Allgemein würde ich eine genaue sprachliche Unterscheidung in der FAQ
zwischen "MTU" und "MTU-Wert" für sinnvoll halten.
Zu diesem Abschnitt der FAQ möchte ich sagen, dass mir der Abschnitt 5.1 von
Roberts http://user.cs.tu-berlin.de/~normanb/README98.HTM#Section5
sehr gut gefällt. Da wird in zwei Absätzen das Problem und (s)eine Lösung
beschrieben.
> Beim Aufbau einer TCP Verbindung kann jede Seite optional die
> bevorzugte/gewünschte MSS angeben. Die MSS gibt die Größe der reinen
> Nutzdaten eines TCP Paketes an. Im Regelfall wird dies die MTU (siehe
> oben) minus 40 Byte (das ist genau die Größe der TCP und IP Header) sein,
> also 1460 Byte für Ethernet Verbindungen. Abzüglich der PPPoE Header (8
> Byte, siehe [1.3]) ergibt sich also eine MSS von 1452 Byte für PPPoE
> Verbindungen.
optional? Wie schaltet man das denn ab?
Man sollte klar machen, dass man dafür sorgen _muss_, dass als MSS-Wert
beim Verbindungsaufbau "1452" (oder niedriger) gesendet wird. Sonst lässt
sich eben GMX.de oder ebay.de nicht im Browser anzeigen, weil der Server
dann zu große Pakete sendet. Du schreibst es "ergibt sich" eine MSS, damit
wird das nicht klar.
> 2. Auswirkungen/Probleme (bei "falscher" - will meist heißen: zu großer
> - MTU)
>
> Siehe auch [4.1] und [4.7].
>
> Manche Webseiten funktionieren/laden nicht richtig.
>
> Gründe:
> a) Diese Websites blocken den (wichtigen) ICMP Datenverkehr, mit welchem
> gemäß dem Path MTU Discovery Standard eine "automatische" Erkennung
> der jeweils besten MTU möglich wäre. Eine genaue Erklärung wie das
> funtioniert würde jedoch hier den Rahmen sprengen. Der interessierte
> Leser sei deshalb auf die Dokumente [4.8] - [4.11] verwiesen.
> b) Die jeweiligen Daten (die Webseiten bzw. die E-Mails) sind größer als
> die ("falsch") eingestellte MTU.
zu a): PMTU discovery ist eine Option, die das Problem beheben könnte. Aber
ist ihr Nicht-Funktionieren der _Grund_ für die Probleme?
was soll b) denn bedeuten? Das die Pakete zu gross sind? Oder das jede
Webpage<1492 Bytes funktioniert?
Der einzige Grund für Probleme ist eben das PPPoE Protokoll selbst.
Deshalb würde ich den FAQ-Lesern das Thema "PMTU discovery" ganz ersparen.
Gruss
Norbert
Dominik Ruf
Danke für deinen Beitrag, genau sowas wünsche ich mir! <freu>
* Norbert Micheel <n.mi...@gmx.de>:
> "Dominik Ruf" <domin...@stud.uni-karlsruhe.de> schrieb [Roman gekürzt]
>> MTU-Mini-FAQ (für xDSL-Zugänge über PPPoE)
> Ich finde man sollte immer vom "einfachen Normalfall" ausgehen.
> Für mich heißt das zunächst, zwei Rechner bauen eine TCP-Verbindung auf.
> Dabei tauschen sie ihre MSS aus, die aus dem als MTU eingestellten Wert für
> das Netzwerk-Medium ermittelt wird. Wäre das Internet nur eine Datenleitung
> ohne Router, wäre damit alles erledigt. Die beiden Rechner würden sich auf
> den kleineren der beiden MSS-Werte einigen und ihre Pakete übertragen.
> Jetzt gibt es aber im Internet leider "Engstellen" zwischen den Routern
> durch die nur kleinere Pakete mit weniger als 1500 Bytes "passen".
> Wenn ich mich in einem lokalen Netz befinde, das über einen Soft- oder
> Hardware-Router per PPPoE Zugang zum Internet hat, so ist auch diese PPPoE
> Verbindung vom Router zum meinem Provider (und auch der umgekehrte Weg) eine
> solche "Engstelle".
Jepp. Alles ACK. Ist bekannt.
Frage: Warum erzählst du mir das? (nicht böse auffassen, die Frage...)
Sollte das deiner Meinung nach in der Mini-FAQ auftauchen? :-)
"DAU"-freundlich formuliert ist das ja schon perfekt, würde ich sagen.
> Das Problem der "Engstellen" wird eigentlich von "PMTU Discovery" gelöst,
> wenn alle Router es korrekt implementieren/zulassen würden.
... wovon man wohl leider _nie_ ausgehen können wird. :-(
> Andereseits wird das Problem (von einem gewissen Standpunkt aus) ja auch nur
> von "PMTU discovery" verursacht, weil ja nur deswegen das "don't
> fragment"-Flag gesetzt wird, oder?
Wusste ich jetzt auch nicht, ob das DF Flag _nur_ deswegen gesetzt wird.
Habe mich aber etwas schlaugemacht. Dabei ist herausgekommen, dass es
u.a. z.b. auch für IP in IP Encapsulation und solche Dinge benötigt/
benutzt wird. Also zumindest nicht _nur_ für PMTUD.
Ich glaube allerdings fast, dass du Recht haben könntest: Würde man die
eigenen Pakete ohne das DF bit schicken, dann würde die (kaputte)
Gegenstelle es vielleicht einfach fragmentiert schicken?! Das wäre natürlich
auch eine Lösung. Ist da noch keiner draufgekommen, oder ist das einfach
hirnrissig, wegen ein paar "Spielverderbern" auf das eigentlich schöne
Feature PMTUD zu verzichten?
> Da man die Router im Internet nicht unter Kontrolle hat, bleibt einem zur
> Problemlösung nur der/die eigene(n) Rechner. Man muss selbst dafür sorgen,
> dass alle Pakete klein genug sind, um jede "Engstelle" im Internet
> zu passieren.
> Die einzige Möglichkeit auch den entfernten Rechner zu beeinflussen ist der
> Austausch der MSS-Werte beim Verbindungsaufbau.
> 1. Möglichkeit:
> Auf allen Rechnern im LAN den MTU-Wert klein genug wählen.
> 2. Möglichkeit:
> Auf dem Router "MSS-Clamping" durchführen.
Jepp. Alles ACK. Das wäre dann in etwa das, was ich mir im Punkt [3] als
"Lösungen" vorgestellt hätte. Soll/kann/darf ich das einfach übernehmen?
Eventuell auch mit kleinen Änderungen?
> Konkrete Anmerkungen:
>> 1.3 Zusammenhang MTU <-> PPPoE
>>
>> Siehe auch [4.1].
>>
>> "Normalerweise" würde man also für die Ethernet Verbindung PPPoE eine
>> MTU von 1500 Byte (siehe [1.1]) verwenden. [...]
>> Deshalb ist also die korrekte MTU für eine PPPoE Schnittstelle
>> 1492 Byte [1500 - (6 + 2)].
>>
>> Genaugenommen sollte die MTU bei PPPoE genau 8 Byte weniger [...] als
>> jedes Interface zwischen dem eigenen Rechner und dem Ziel sein.
> Es wird einem Laien bestimmt nicht klar, was du mit diesen zwei Absätzen
> meinst. Denn du sprichst einmal von der "MTU einer PPPoE-Verbindung", was
> eine feste Zahl _ist_, nämlich 1492 und später davon "die MTU sollte...
> sein..." und meinst damit was man dem Rechner mitteilen soll, welchen Wert
> er als MTU benutzen soll. Wenn man 88 als MTU-Wert für die PPPoE-Verbindung
> konfiguriert, so bleibt die MTU "einer" PPPoE-Verbindung weiterhin 1492.
> Allgemein würde ich eine genaue sprachliche Unterscheidung in der FAQ
> zwischen "MTU" und "MTU-Wert" für sinnvoll halten.
Aha. Das ist wohl die Kernaussage. Halte ich auch für sinnvoll. Werde
mich in Zukunft bemühen. Allerdings würde ich nicht sagen, dass _die_
MTU "einer" PPPoE-Verbindung _immer_ 1492 _ist_ (siehe Robert).
> Zu diesem Abschnitt der FAQ möchte ich sagen, dass mir der Abschnitt 5.1 von
> Roberts http://user.cs.tu-berlin.de/~normanb/README98.HTM#Section5
> sehr gut gefällt. Da wird in zwei Absätzen das Problem und (s)eine Lösung
> beschrieben.
Jepp. Die Seiten kenne ich. Ich werde sie nochmal in Bezug zu der Mini-FAQ
durchlesen und schauen, ob man da was "abgucken" könnte. - Ich hoffe mal,
Robert hätte da nichts dagegen?!
>> Beim Aufbau einer TCP Verbindung kann jede Seite optional die
>> bevorzugte/gewünschte MSS angeben. [...]
> optional? Wie schaltet man das denn ab?
Ich habe keine Ahnung, ob oder wie man das abschalten kann.
Die Info hatte ich von
http://www.roaringpenguin.com/pppoe/als-pppoe-paper.pdf Kap. 4.5:
| When a TCP connection is initiated, each side can optionally specify
| the Maximum Segment Size (MSS).
Ich gehe mal davon aus, dass die dort keine Scheiße schreiben, schließlich
haben die in ihrem Treiber das mit dem MSS-Clamp auch hervorragend gelöst.
Ein RFC wäre mir zwar lieber, aber ich bin da wohl gerade zu faul, einen
passenden rauszusuchen. ;-)
Übrigens, man sieht, ich schreibe eigentlich nur ab bzw. übersetze... ;-)
> Man sollte klar machen, dass man dafür sorgen _muss_, dass als MSS-Wert
> beim Verbindungsaufbau "1452" (oder niedriger) gesendet wird. Sonst lässt
> sich eben GMX.de oder ebay.de nicht im Browser anzeigen, weil der Server
> dann zu große Pakete sendet. Du schreibst es "ergibt sich" eine MSS, damit
> wird das nicht klar.
Da stimme ich dir zu. Aber der Abschnitt [1] soll ja erst mal einführen
und die Begriffe erklären. Was man dann konkret einstellen soll, das
würde ich dann im (im Moment noch leeren) Abschnitt [3] bei den Lösungen
schreiben. Da wird das dann auf jeden Fall auftauchen, was du schreibst.
Findest du diese Idee eigentlich gut oder eher schlecht?
Ich meine, ist die Inhaltsgliederung so Ok, oder hast du einen anderen
Vorschlag?
>> Manche Webseiten funktionieren/laden nicht richtig.
>>
>> Gründe:
>> a) Diese Websites blocken den (wichtigen) ICMP Datenverkehr, mit welchem
>> gemäß dem Path MTU Discovery Standard eine "automatische" Erkennung
>> der jeweils besten MTU möglich wäre. Eine genaue Erklärung wie das
>> funtioniert würde jedoch hier den Rahmen sprengen. Der interessierte
>> Leser sei deshalb auf die Dokumente [4.8] - [4.11] verwiesen.
>> b) Die jeweiligen Daten (die Webseiten bzw. die E-Mails) sind größer als
>> die ("falsch") eingestellte MTU.
> zu a): PMTU discovery ist eine Option, die das Problem beheben könnte. Aber
> ist ihr Nicht-Funktionieren der _Grund_ für die Probleme?
Naja, wie man es sieht. ;-)
IMHO: Würde PMTUD funktionieren, dann gäbe es die Probleme (Webseiten laden
nicht, wegen MTU) nicht. Also ist das schon der _Grund_. Sieht man ja auch
daran, dass es eben nur bei _den_ Seiten nicht geht, die ICMP alles
dichtmachen, alle anderen Seiten funktionieren ja problemlos.
Unten schreibst du ja selbst: Der eigentliche (und einzige) Grund ist
das PPPoE Protokoll (mit den 8 Byte zusätzlichen Headern). Ich denke, das
ist ein wichtiger Punkt, den man auf jeden Fall in der FAQ mit einbauen
sollte.
Aber trotzdem würde ich das Nichtfunktionieren von PMTUD als Grund ansehen.
Siehe oben: wie man es halt sieht. ;-)
Würdest du das anders formulieren/weglassen oder was schlägst du vor?
> was soll b) denn bedeuten? Das die Pakete zu gross sind? Oder das jede
> Webpage<1492 Bytes funktioniert?
Beides. :-)
Webpages (oder auch Mails) <1492 Byte
(oder besser gesagt < MTU + PPPoE Header) sollten funktionieren.
Da diese ja in einem einzigen Paket, welches kleiner der MTU + Header ist
übertragen werden und somit nie fragmentiert werden müssen. Probleme gibt
es erst, wenn Daten > MTU + Header im Spiel sind, da diese eben auf mehrere
Pakete (in der Größe der MTU) aufgeteilt werden müssen. Vorher spielt ja
die MTU praktisch keine Rolle (solange die Daten < MTU sind).
Insofern ist das eben auch ein _Grund_ für das Nichtfunktionieren, IMHO.
Aber vielleicht sollte ich das nochmal deutlicher formulieren, was ich
aussagen wollte, ok. :-)
> Der einzige Grund für Probleme ist eben das PPPoE Protokoll selbst.
Jepp. Siehe oben. Das wird (irgendwo) auf jeden Fall eingebaut.
> Deshalb würde ich den FAQ-Lesern das Thema "PMTU discovery" ganz ersparen.
Ich bin ja auch nicht näher drauf eingegangen, sondern habe dann auf die
Links verwiesen. Die Frage bleibt: Wo sieht man die Zielgruppe dieser FAQ?
Sicher in erster Linie Laien (ich vermeide das Wort 'DAU' bewusst *g*).
Aber sicher gibt es auch 'Fortgeschrittenere', die sich etwas _mehr_ für
das Thema interessieren. Und da stellt sich dann die Frage, inwieweit man
das unter einen Hut bringen kann. Deshalb war ich der Meinung, dass man
PMTUD zumindest mal erwähnen und mit weiterführenden Links bestücken sollte.
Wie sieht deine Meinung dazu aus?
Gruss Dominik
--
de.comm.technik.dsl FAQ - http://www.sauff.com/dsl-faq/dsl-faq.html
Diskussionsforum zur FAQ - http://sauff.homeip.net/dsl-faq/
MTU-Mini-FAQ - http://ruf.2y.net/~dominik/txt/mtu-mini-faq.html
Schönes Quoten lernen? - http://www.afaik.de/usenet/faq/zitieren/
Harald Sauff
> Danke für deinen Beitrag, genau sowas wünsche ich mir! <freu>
Komisch, bei der MTU-FAQ dauert es keine zwei Tage, bis sich jemand
beteiligt, bei der normalen FAQ kann man den Leuten nicht mal nach
Aufforderung ein paar Worte entlocken... Warum mache ich das eigentlich
noch?
Gruß,
Harry
Dominik Ruf
[FAQ]
> ... Warum mache ich das eigentlich noch?
Weil du ein guter Mensch bist. Ehrlich! :-)
Du tust _mir_ und sicher auch der Gruppe damit einen großen Gefallen,
auch wenn dir das vielleicht kaum jemand sagt, aber das ist so, glaube es.
Kopf hoch! Ich werde dich auch weiterhin unterstützen, aber ein bisschen
mehr Mithilfe wäre schon schön, da gebe ich dir Recht. Vielleicht solltest
du nochmal eine txt-Version der FAQ hier posten? Es besteht ja zumindest
die Wahrscheinlichkeit, dass sich jemand genötigt fühlt, etwas anzumerken.
Mangels OnTopic würde ich ja glatt nen F'up2 Poster setzen, lasse das
aber mal...
Liebe Grüße Dominik
--
Wer geht mit Kuscheln nach dtr? ;-)
Tipps für Usenet-Einsteiger in <news:de.newusers.infos> oder im WWW unter
http://www.kirchwitz.de/~amk/dni/
Für Outlook Express Benutzer - http://www.wschmidhuber.de/oeprob/
Norbert Micheel
> Hallo Norbert,
>
> Danke für deinen Beitrag, genau sowas wünsche ich mir! <freu>
>
>
> Jepp. Alles ACK. Ist bekannt.
> Frage: Warum erzählst du mir das? (nicht böse auffassen, die Frage...)
> Sollte das deiner Meinung nach in der Mini-FAQ auftauchen? :-)
>
> "DAU"-freundlich formuliert ist das ja schon perfekt, würde ich sagen.
Ich wollte es gar nicht "DAU"-freundlich formulieren, nur meine Art das
Thema zu betrachten erläutern.
In die FAQ sollte sowas eher nicht.
In einer FAQ müssen die Fakten stehen, die ich so lange lese bis ich es
verstehe.
Man kann keinen Text schreiben, den jeder nach einmaligem Lesen versteht.
> > Da man die Router im Internet nicht unter Kontrolle hat, bleibt einem
> > zur Problemlösung nur der/die eigene(n) Rechner. Man muss selbst dafür
> > sorgen, dass alle Pakete klein genug sind, um jede "Engstelle" im
> > Internet zu passieren.
> > Die einzige Möglichkeit auch den entfernten Rechner zu beeinflussen ist
> > der Austausch der MSS-Werte beim Verbindungsaufbau.
> >
> > 1. Möglichkeit:
> > Auf allen Rechnern im LAN den MTU-Wert klein genug wählen.
> >
> > 2. Möglichkeit:
> > Auf dem Router "MSS-Clamping" durchführen.
>
> Jepp. Alles ACK. Das wäre dann in etwa das, was ich mir im Punkt [3] als
> "Lösungen" vorgestellt hätte. Soll/kann/darf ich das einfach übernehmen?
> Eventuell auch mit kleinen Änderungen?
Ob du das sollst, müssen andere als ich sagen. Dürfen darfst du es, und
kannst es bestimmt auch ;-)
> > Allgemein würde ich eine genaue sprachliche Unterscheidung in der FAQ
> > zwischen "MTU" und "MTU-Wert" für sinnvoll halten.
>
> Aha. Das ist wohl die Kernaussage. Halte ich auch für sinnvoll. Werde
> mich in Zukunft bemühen. Allerdings würde ich nicht sagen, dass _die_
> MTU "einer" PPPoE-Verbindung _immer_ 1492 _ist_ (siehe Robert).
Bingo. Das ist die Kernaussage :-)
...weil ich die Hoffnung habe, dass macht das Verstehen einfacher.
Wenn ich MTU höre/lese, höre ich "maximum transfer unit". Und das Maximum an
Bytes einer PPPoE Verbindung (gemäss ihrer Protokollbeschreibung) ist 1492.
Wenn die verschiedenen Treiber unterschiedliche MTUs erzeugen würden
(Robert), wären sie ja inkompatibel mit der Gegenstelle. Solange Robert das
nicht näher erläutert hat, glaube/verstehe ich das erstmal nicht.
> >> Beim Aufbau einer TCP Verbindung kann jede Seite optional die
> >> bevorzugte/gewünschte MSS angeben. [...]
>
> > optional? Wie schaltet man das denn ab?
>
> Ich habe keine Ahnung, ob oder wie man das abschalten kann.
>
Nun die MSS wird ja in den "TCP-Options" gesendet, also ist es natürlich
eine Option. Mir war nur aufgefallen, dass zumindest in meinen
Beschreibungen des Windows-TCP-Stacks nichts enthalten ist, wie man das
abstellen könnte. (Bei Linux geht das bestimmt ;-)
> ...
> Ich meine, ist die Inhaltsgliederung so Ok, oder hast du einen anderen
> Vorschlag?
Ne ne, ist schon okay so. Es ging mir nur darum, dass die Formulierungen der
einleitenden Abschnitte nicht das Verstehen der Lösungen erschwert.
Ich würde bei "1.4 MSS" nur eben noch reinschreiben, dass jeder der beiden
Rechner den empfangenen MSS-Wert mit seinem MSS-Wert vergleicht und dann
_tatsächlich_ Pakete dieser Größe sendet.
Denn das hilft sowohl das Problem der Clients zu verstehen (Der Client und
der Server senden mit 1500 ==> Pakete am Router zu gross) als auch die
Lösung zu verstehen.
Für mich bleibt der Grund, warum manche seiten nicht angezeigt werden, dass
IP-Pakete gepackt werden, die für PPPoE zu groß sind. (dein Abschnitt 2)
Wenn ich dafür sorge ---ob durch a)Konfiguration, b)MSS-Clamping oder
c)funktionierendes PMTU discocery---, dass die Pakete klein genug sind
funktioniert es.(Abschnitt 3)
Wobei ich für b) einen speziellen Treiber brauche, c) nicht selbst erreichen
kann und a) eine Sache ist die Ahnung erfordert.
Wahrscheinlich ist es das Beste, es auch so in der FAQ rüberzubringen:
c) wäre schön
b) für die die sich nicht mit so einem Müll beschäftigen wollen
a) für den Interessierten mit den passenden Links
> Die Frage bleibt: Wo sieht man die Zielgruppe dieser FAQ?
>
Es geht doch darum, dass nicht jeden zweiten Tag jemand nach "GMX" fragt.
Bzw. dass man ihn mit gutem Gewissen auf die FAQ verweisen kann.
Also muss die FAQ das Problem für Leute lösen, die nicht mal auf die Idee
kommen, die alten Nachrichten der Newsgroup runterzuladen, welche sie gerade
aboniert haben um ihre Frage zu stellen.
Ich denke da kommt nur der RASPPPoE in Frage. Das Installieren eines neuen
Treibers mit funktionierenden Default-Einstellungen kann man den Leuten wohl
zumuten.
Für Andere (die vielleicht nur einen Client-Rechner haben) mag der RegEdit
die schnellere Lösung sein.
Ob eine FAQ mehr oder weniger Informationen enthält ist nicht so wichtig.
Wichtig ist, die Fakten müssen stimmen und die FAQs beantwortet werden.
Gruss
Norbert (wieder viel zu Windows-lastig)
Dominik Ruf
> "Dominik Ruf" <domin...@stud.uni-karlsruhe.de> schrieb im Newsbeitrag
> news:i8m69a...@ID-136364.user.dfncis.de...
Darf man auch dich auf http://www.afaik.de/usenet/faq/zitieren/ hinweisen?
Es sieht IMHO einfach nicht so schön aus, sobald mehrfach gequotet wird,
wenn da mehr als eine Zeile ist... (und unübersichtlich wird es auch)
<Esotherik>
>> "DAU"-freundlich formuliert ist das ja schon perfekt, würde ich sagen.
> Ich wollte es gar nicht "DAU"-freundlich formulieren, nur meine Art das
> Thema zu betrachten erläutern.
Eine sehr schöne Art. :-)
> In die FAQ sollte sowas eher nicht.
> In einer FAQ müssen die Fakten stehen, die ich so lange lese bis ich es
> verstehe.
Das sollte IMHO lieber den RFC's usw. vorbehalten bleiben - für den,
den es wirklich interessiert. Es gibt schon viel zu viel unverständliche
Literatur. :-(
> Man kann keinen Text schreiben, den jeder nach einmaligem Lesen versteht.
Es wäre mir schon ein Bedürfnis, dass zumindest möglichst viele es
verstehen. Wo liegt sonst der Sinn einer FAQ?
</Esotherik>
>> Soll/kann/darf ich das einfach übernehmen?
> Ob du das sollst, müssen andere als ich sagen. Dürfen darfst du es, und
> kannst es bestimmt auch ;-)
:-)
... und "Danke" übrigens! ;-)
>> > Allgemein würde ich eine genaue sprachliche Unterscheidung in der FAQ
>> > zwischen "MTU" und "MTU-Wert" für sinnvoll halten.
Auf den ersten Blick hatte sich das für mich voll logisch angehört.
Aber als ich das dann beim FAQ-Schreiben anwenden wollte und darüber
gegrübelt habe, wo ich jetzt welchen Begriff verwenden soll... - da
stand ich vor _echten_ Problemen. :-(
Mal "im Ernst" (dtl lässt grüßen *g*): Wo genau soll der Unterschied
zwischen "MTU" und "MTU-Wert" sein?
Ich könnte höchstens, wenn ich vom Einstellen eines bestimmten Wertes
rede, "MTU-Wert" sagen. - Aber auch das führt sich IMHO sofort ad
absurdum, da ich auch genauso sagen könnte, dass man die "MTU" einstellen
soll. Diese Begriffe sind IMHO äquivalent. - Ausser, du erklärst mir
jetzt den Unterschied. ;-)
Nichts destotrotz habe ich versucht, diese Unterscheidung nach bestem
Wissen und Gewissen anzuwenden. Was dabei rausgekommen ist, findet
sich weiter unten. Bitte also mal auf diese beiden Wörter "MTU" und
"MTU-Wert" achten und anmerken, falls ich mich für das flasche entschieden
haben sollte. (Wobei wie gesagt, _noch_ ist es IMHO immer richtig, da
das äquivalent ist. Das gilt jetzt bis zum Gegenbeweis. ;-)
> Wenn ich MTU höre/lese, höre ich "maximum transfer unit". Und das Maximum an
> Bytes einer PPPoE Verbindung (gemäss ihrer Protokollbeschreibung) ist 1492.
> Wenn die verschiedenen Treiber unterschiedliche MTUs erzeugen würden
> (Robert), wären sie ja inkompatibel mit der Gegenstelle. Solange Robert das
> nicht näher erläutert hat, glaube/verstehe ich das erstmal nicht.
Jepp. Die Betonung liegt auf dem Wort "Maximum", das auch genau so
im PPPoE RFC 2516 (Oh Gott, jetzt kann ich die Nummern schon auswendig.
Sollte mich das nachdenklich stimmen???1). Damit ist ausgesagt, dass
die MTU jederzeit kleiner sein kann. Es geht ja nur ums Maximum. Und
wenn mein PC MTU 1300 hat und die Gegenstelle 1492/1500, warum sollte
das nicht funktionieren? Kleiner geht doch immer, oder?
>> >> Beim Aufbau einer TCP Verbindung kann jede Seite optional die
>> >> bevorzugte/gewünschte MSS angeben. [...]
>>
>> > optional? Wie schaltet man das denn ab?
>>
>> Ich habe keine Ahnung, ob oder wie man das abschalten kann.
> Nun die MSS wird ja in den "TCP-Options" gesendet, also ist es natürlich
> eine Option.
Ja und Nein. Es wird in den TCP-Options gesendet, korrekt. Aber es ist
IMHO trotzdem optional, da bestehe ich drauf. Ich habe auch wegen dieser
Frage in den RFC's gestöbert. Mit stolz geschwellter Brust präsentiere
ich die Ergebnisse (Ruf (tm) Productions proudly presents...):
RFC 793 (TCP), Punkt 3.1 Ende
| Maximum Segment Size Option Data: 16 bits
| If this option is present, then it communicates the maximum
| receive segment size at the TCP which sends this segment.
| This field must only be sent in the initial connection request
| (i.e., in segments with the SYN control bit set). If this
| option is not used, any segment size is allowed.
Also es muss nicht unbedingt vorhanden sein. Allerdings (ein bisschen
weiter oben)...
"A TCP must implement all options."
... müssen immer alle Optionen implementiert sein. Das heißt aber nicht,
dass diese Option eben immer benutzt werden muss.
Dann gibt es aber noch den speziellen RFC 879,
"The TCP MSS and Related Topics"
"TCP provides an option that may be used ..."
"When opening a connection TCP can send an MSS option ..."
| Another way of asking this question is "What transmitted value for
| MSS has exactly the same effect of not transmitting the option at all?".
| If the TCP Maximum Segment Size option is not transmitted then the
| data sender is allowed to send ...
Es ist also sehr wohl optional und eine TCP Implementierung _müsste_
die MSS Option nicht mitsenden.
> Mir war nur aufgefallen, dass zumindest in meinen
> Beschreibungen des Windows-TCP-Stacks nichts enthalten ist, wie man das
> abstellen könnte. (Bei Linux geht das bestimmt ;-)
Das mag durchaus sein, dass es alle machen. Du darfst also auch ein
bischen Recht haben. ;-)
Du in der Praxis (wobei das noch zu beweisen wäre), ich in der Theorie.
Ob man es bei Linux abstellen könnte, weiß ich nicht. Allerdings hast du
wohl auf jeden Fall die Möglichkeit, den Source-Code zu ändern. :-)
[Inhaltsgliederung]
> Ne ne, ist schon okay so. Es ging mir nur darum, dass die Formulierungen
> der einleitenden Abschnitte nicht das Verstehen der Lösungen erschwert.
Ok, dann ist ja gut. Bei letzterem, ACK.
> Ich würde bei "1.4 MSS" nur eben noch reinschreiben, dass jeder der beiden
> Rechner den empfangenen MSS-Wert mit seinem MSS-Wert vergleicht und dann
> _tatsächlich_ Pakete dieser Größe sendet.
> Denn das hilft sowohl das Problem der Clients zu verstehen (Der Client und
> der Server senden mit 1500 ==> Pakete am Router zu gross) als auch die
> Lösung zu verstehen.
Jepp. So ähnlich eingebaut und 1.4 komplett neu geschrieben.
Schau' mal, wie du es jetzt findest...
Übrigens, den RFC 879 zur MSS kann ich nur empfehlen, sehr interessant.
Noch _einen_ Abschnitt "muss" ich einfach zitieren, weil er mir so gut
gefallen hat:
| [vorherigen sehr interessanten Teil aus Platzgründen gesnippt]
| The MSS can be used completely independently in each direction of
| data flow. The result may be quite different maximum sizes in the
| two directions.
> Für mich bleibt der Grund, warum manche seiten nicht angezeigt werden, dass
> IP-Pakete gepackt werden, die für PPPoE zu groß sind. (dein Abschnitt 2)
> Wenn ich dafür sorge ---ob durch a)Konfiguration, b)MSS-Clamping oder
> c)funktionierendes PMTU discocery---, dass die Pakete klein genug sind
> funktioniert es.(Abschnitt 3)
Ok, jetzt hast du mich wirklich mit deinen Argumenten überzeugt. :-)
Ist jetzt so eingebaut.
> Wobei ich für b) einen speziellen Treiber brauche, c) nicht selbst erreichen
> kann und a) eine Sache ist die Ahnung erfordert.
> Wahrscheinlich ist es das Beste, es auch so in der FAQ rüberzubringen:
> c) wäre schön
> b) für die die sich nicht mit so einem Müll beschäftigen wollen
> a) für den Interessierten mit den passenden Links
Genial einfach, diese Dreiteilung. Habe ich glatt so übernommen. :-)
Merci auch hier!
>> Die Frage bleibt: Wo sieht man die Zielgruppe dieser FAQ?
> Es geht doch darum, dass nicht jeden zweiten Tag jemand nach "GMX" fragt.
> Bzw. dass man ihn mit gutem Gewissen auf die FAQ verweisen kann.
> Also muss die FAQ das Problem für Leute lösen, die nicht mal auf die Idee
> kommen, die alten Nachrichten der Newsgroup runterzuladen, welche sie gerade
> aboniert haben um ihre Frage zu stellen.
Jepp. Gerade deshalb sollte es auch noch halbwegs verständlich sein,
zumindest die Teile, wo es drauf ankommt. Die "Theorie"-Teile sind ja
IMHO eh nur für "den Interessierten".
> Ich denke da kommt nur der RASPPPoE in Frage. Das Installieren eines neuen
> Treibers mit funktionierenden Default-Einstellungen kann man den Leuten wohl
> zumuten.
Jepp. Bekommt auch die Empfehlung der FAQ. Gruss an Robert! :-)
> Für Andere (die vielleicht nur einen Client-Rechner haben) mag der RegEdit
> die schnellere Lösung sein.
Dazu habe ich meine Frage von nebenan noch nicht beantwortet bekommen.
Wer weiß es? (Preisfrage: ;-)
Kann man bei Windows-Systemen sagen, dass man die MTU der PPPoE-Verbindung
_immer_ _nur_ über den PPPoE-Treiber einstellen kann und dass die
MTU-Geschichte in der Registry _immer_ _nur_ für "normale"
Ethernet-Verbindungen geht?
> Ob eine FAQ mehr oder weniger Informationen enthält ist nicht so wichtig.
> Wichtig ist, die Fakten müssen stimmen und die FAQs beantwortet werden.
ACK.
> Norbert (wieder viel zu Windows-lastig)
Das will ich gerade nicht verstehen, sorry. Du hast das "böse Wort"
nicht ein einziges Mal verwendet, oder?
Nunja, jetzt also im Anhang die neue Version der FAQ. Wo ich noch Hilfe
gebrauchen könnte, merke ich mal direkt im Text in [...] an. Vielen
Dank jetzt schon für weitere Kommentare (gern auch von anderen Leuten).
Inzwischen würde ich auch sagen, dass (fast) alles wichtige drin ist, und
man die Leute schon ohne Hemmungen drauf verweisen kann. Auch, wenn ich
an vielen Stellen noch kleinere Verbesserungen/Änderungen teilweise
auch schon im Kopf habe, meist aber einfach nicht weiß und auf externe
Hilfe angewiesen bin.
Eventuell werde ich später mal auch noch ein Perl-Skript o.ä. bauen,
was alle [X.Y] bzw. RFC XXXX automatisch in Links umwandelt und dann
eine HTML-Version auf der Homepage bereitstellen. Aber das erst, wenn
ich die Zeit dazu habe/sie mir nehme...
MTU-Mini-FAQ (für xDSL-Zugänge über PPPoE)
==========================================
Die aktuelle Version dieser Mini-FAQ ist online unter
http://ruf.2y.net/~dominik/txt/mtu-mini-faq.txt zu finden.
Inhalt:
1. Einleitung und Begriffserklärungen
1.1 MTU
1.2 PPPoE
1.3 Zusammenhang MTU <-> PPPoE
1.4 MSS
1.5 MSS Clamping
2. Auswirkungen/Probleme
3. Abhilfe/Lösungsmaßnahmen
3.1 Wie stelle ich die richtigen Parameter ein?
4. Links
4.1 RFC's
4.X Die einzelnen Links, im Text als Verweis durch [4.X] gekennzeichnet.
5. Danksagungen
5.1 Kommentare
1. Einleitung und Begriffserklärungen
1.1 MTU = Maximum Transmission Unit
[4.2], [4.3], [4.4]
Die Maximum Transmission Unit (MTU) einer Netzwerk Schnittstelle (Interface)
gibt das größtmögliche IP Datenpaket an, das ohne Fragmentierung (Aufsplittung
in mehrere kleinere Pakete) über diese transportiert werden kann.
Im Internet und auch in lokalen Netzen auf Ethernet Basis werden die Daten
in einzelnen Paketen (Ethernet Frames genannt) transportiert. Die maximale
Größe eines einzelnen Ethernet Frame Paketes ist 1518 Byte. Davon werden
14 Byte vom (Ethernet-) Header und 4 Byte von der Checksumme für das Frame
beansprucht, sodass also noch genau 1500 Bytes an Nutzdaten für ein solches
Ethernet Frame übrigbleiben. Deshalb ist die Maximum Transmission Unit (MTU)
einer Ethernet Schnittstelle (z.B. einer Netzwerkkarte im Rechner) 1500 Byte
groß.
1.2 PPPoE Point-to-Point Protokoll over Ethernet
[4.5], [4.6], RFC 2516, RFC 1661
Das Point-to-Point Protokoll (PPP) stellt einen von Zugangsprovidern gerne
genutzten Standard für Punkt-zu-Punkt Verbindungen (z.B. zwischen dem
Einwahlrechner des Providers und dem PC des Kunden) dar. Viele xDSL Provider
nutzen daher dessen Erweiterung PPP over Ethernet (PPPoE) für den Zugang.
Wie der Name schon sagt, wird die Punkt-zu-Punkt Verbindung über eine Ethernet
Verbindung hergestellt.
Das PPPoE Protokoll selbst benötigt pro Datenpaket 8 Byte zusätzlich im
Header.
1.3 Zusammenhang MTU <-> PPPoE
[4.2]
Für Ethernet-Verbindungen (wie u.a. PPPoE) ist laut Standard eine (maximale)
MTU von 1500 Byte vorgesehen. Hierbei sind allerdings noch nicht die 8 Byte
für das PPPoE-Protokoll berücksichtigt. Um also inklusive den PPPoE-Headern
noch standardkonforme Ethernet-Pakete zu senden, darf die MTU für
PPPoE-Verbindungen höchstens 1492 Byte groß sein (siehe RFC 2516).
Genaugenommen [4.8] sollte der MTU-Wert bei PPPoE genau 8 Byte weniger (der
zusätzliche PPPoE Protokoll Header) als jedes Interface zwischen dem eigenen
Rechner und dem Ziel sein. "Normalerweise" sollten alle Router auf eine MTU
von 1500 konfiguriert sein [1.1], sodass 1492 korrekt sein sollte. Trotzdem
kann es aber mal vorkommen, dass sich ein Router nicht daran hält. Abhilfe
schafft hier nur ein ständiges Verringern des eigenen MTU-Wertes, bis es
"funktioniert".
1.4 MSS = Maximum Segment Size
[4.2], RFC 793, RFC 879
Während sich die MTU auf alle IP-Pakete bezieht, gibt es den Begriff der
Maximum Segment Size (MSS) nur für TCP-Pakete (also z.B. nicht für UDP).
Die MSS gibt die Größe der reinen Nutzdaten eines TCP Paketes an. Im
Regelfall wird dies die MTU [1.1] minus 40 Byte (das ist genau die Größe
der TCP- und IP-Header) sein, also 1460 Byte für Ethernet-Verbindungen.
Abzüglich der PPPoE-Header (8 Byte, [1.3]) ergibt sich also eine MSS von
1452 Byte für PPPoE-Verbindungen.
Beim Aufbau einer TCP-Verbindung kann jede Seite optional die
bevorzugte/gewünschte MSS angeben. Die Gegenseite wird dann auf jeden Fall
Pakete mit der gewünschten MSS senden. Deshalb sind durchaus Verbindungen
möglich, in der beide Seiten mit unterschiedlicher MSS senden - eben jeweils
mit dem vom Anderen gewünschten Wert.
1.5 MSS Clamping
TODO
2. Auswirkungen/Probleme bei "falscher" - will meist heißen: zu großer - MTU
[4.2], [4.7], [4.8], [4.9], [4.10], [4.11]
[Wäre es hier besser, "[4.7] - [4.11]" zu schreiben? Wäre das
unmissverständlich zu verstehen oder könnte eventuell nicht verstanden
werden, was damit gemeint ist? - Ok, das sind Kinkerlitzchen, aber
trotzdem...]
Manche Webseiten funktionieren/laden nicht richtig.
Der Internet Explorer zeigt bei diesen Seiten die Fehlermeldung
"Die Seite kann nicht angezeigt werden".
Der Browser bleicht bei diesen Seiten mit der Meldung
"...contacted, waiting for reply!" stehen.
Das Paradebeispiel sind die Seiten von GMX.
Ebenso kann z.B. die Post nicht via POP3 von GMX abgeholt werden.
Gründe:
Beide Rechner - sowohl der eigene, als auch der von GMX (oder einer anderen
Site, die nicht funktioniert) - announcen eine MSS von 1460 beim
Verbindungsaufbau. Folglich senden beide Seiten mit dieser MSS. Leider
können beide nicht wissen, dass dazwischen die "Engstelle" der
PPPoE-Verbindung liegt, die eine MSS von maximal 1452 verkraftet. Und
somit gehen die zu großen Pakete auf der PPPoE-Strecke verlohren, ohne dass
dies jemand bemerkt. :-(
3. Abhilfe/Lösungsmaßnahmen
* Eine Lösungsmaßnahme wird mit der Path MTU Discovery Methode beschrieben.
Leider funktioniert dies Aufgrund von hirntot konfigurierten Firewalls
und Routern im Internet nicht. Darauf hat der Enduser keinen Einfluss,
sodass diese Methode leider nur bedingt tauglich ist und somit für eine
*endgültige* Lösung des Problems ausscheidet.
RFC 1191, RFC 2913, [4.2], [4.9], [4.10], [4.11]
* Bei Einzelplatz-Systemen, bei denen der Rechner direkt mit dem DSL-Modem
verbunden ist bzw. ein internes DSL-Modem verwendet...
... sollte es ausreichen, die MTU des PPPoE Interfaces auf 1492 Byte zu
setzen. (Oder gegebenenfalls - sprich: es funktionieren manche Sites
immer noch nicht - noch niedriger, was aber IMHO nicht nötig sein sollte.
Es ist mir auch noch kein solcher Fall bekannt.)
[Kennt etwa jemand einen solchen Fall? Sollte ich die Klammer eventuell
komplett weglassen?]
Die meisten (alle?!) PPPoE-Treiber werden dies per Default tun bzw.
eine noch niedrigere MTU als das zulässige Maximum (was die beste
Performance bringt [4.4]) von 1492 Byte verwenden.
[Wer kann hier Aussagen über mein "alle?!" machen? Welcher Treiber
benutzt welche Default-MTU? Gibt es PPPoE Treiber, die eine zu große,
also > 1492 Byte MTU per Default verwenden?]
Eine Anpassung sollte also bei Einzelplatz-Systemen i.A. nicht nötig sein.
Es existieren jedoch z.B. VPN-Implementierungen, die einen noch niedrigeren
MTU-Wert benötigen, sodass diese dann gegebenenfalls "von Hand" eingestellt
werden muss.
[Stimmt das überhaupt? - Ok, wenn es hier keiner weiß, frage ich mal
in dcsf nach... Ausser ihr sagt, den Satz oder Absatz soll ich ganz
weglassen.]
* Bei Mehrplatz-Systemen mit zentraler Einwahl über einen Router...
... gibt es 2 Möglichkeiten, von denen man nur genau *eine* anwenden
sollte:
* Der Router kann MSS-Clamping [1.5] betreiben bzw. er kann so umgestellt
werden, dass er dies tut. Dann sollte es ausreichen, im Router die
CLAMP-MSS auf 1452 Byte [1.4] einzustellen.
Dies ist sicher der zu bevorzugende Weg, da damit die Clients im
lokalen LAN weiterhin den (Ethernet-Standard-) MTU-Wert von 1500 Byte
benutzen können (minimal bessere Performance). Ausserdem müssen neu
hinzukommende Clients nicht speziell konfiguriert werden.
(Weniger Aufwand: einmal den Router richtig einstellen und für immer
Ruhe haben *g*)
* Auf *allen* Clients muss die MTU entsprechend angepasst und auf den
Wert der MTU des Routers gesetzt werden. Bei standardkonformen
PPPoE-Treibern des Routers also auf 1492 Byte.
Achtung! Diverse PPPoE-Treiber für Windows (darunter ...) verwenden
eine kleinere MTU als 1492 Byte. Somit ist auch die MTU auf
dahinterliegenden Clients kleiner als 1492 Byte zu setzen.
[Wer kann zu den 3 "..." genaue Aussagen machen und weiß vielleicht
sogar die verwendeten Werte? Robert hatte ein paar Treiber genannt,
ich muss aber nochmal nachlesen, ob er sich da sicher war, oder ob
das auch ein bisschen Spekulation war...]
3.1 Wie stelle ich die richtigen Parameter ein?
[Hier muss ich gestehen, dass ich bisher nur auf die MTU eingegangen
bin. Das MSS-Clamp bzw. MSS kommt dann in der nächsten Ausgabe. Und
dann taucht auch Harry's Vorschlag mit der iptables-Zeile endlich auf.]
3.1.1 Linux
$ ifconfig <device> mtu <wert>
$ man ifconfig
Der Roaring-Penguin (rp-pppoe) Treiber sollte die MTU automatisch auf
1492 Byte setzen, sodass keine weiteren Einstellungen (bzgl. der MTU)
notwendig sind.
Bei den Kernel-Treibern werden die Einstellungen in der Datei
/etc/ppp/options gesetzt. Die beiden Einträge heißen
mru 1492
mtu 1492
Eine Einstellung der MSS sollte bei keinem *nix System nötig sein,
da die MSS automatisch auf MTU - 40 Byte (TCP + IP Header) gesetzt wird.
3.1.2 OpenBSD
$ man ifconfig
$ man ppp.conf
Bzw. in der Datei /etc/ppp/ppp.conf die Einträge
set MTU max 1492
set MRU max 1492
Achtung! Das "max" ist anscheinend bei OpenBSD von entscheidender Bedeutung.
3.1.3 FreeBSD
$ man ifconfig
$ man ppp.conf
Bzw. in der Datei /etc/ppp/ppp.conf die Einträge
set MTU 1492
set MRU 1492
3.1.4 Windows (allgemein)
MTU, MSS und andere Parameter werden in der Registry eingestellt.
Dies kann man entweder von Hand (mit dem Programm "regedit") machen,
oder über diverse "Tools", die einem diese Arbeit erleichtern.
Grundsätzlich gilt, dass Tools, die versprechen, die Verbindung "automatisch"
für DSL zu optimieren nur bedingt geeignet sind. Besser sind Tools, die es
erlauben, die einzelnen Parameter selbst zu setzen.
Empfehlenswertes Tool: DrTCP [4.15]
[Hier ("Tools") noch Anmerkungen dazu?]
Wenn man den RASPPPOE Treiber [4.14] benutzt, kann man die MTU für die
PPPoE Verbindung über die "Eigenschaften" der Verbindung einstellen.
Genaueres findet sich in den README's, die der Software beiliegen und
auch auf der Homepage zu finden sind.
[Kann man das _so_ sagen?]
[Siehe oben, kann man sagen, dass die MTU für PPPoE-Verbindungen _immer_
nur über den jeweiligen Treiber einstellbar sind? Und umgekehrt?]
Ebenso ist der RASPPPOE Treiber der einzige Windows Treiber, der die
MSS Clamp Option beherrscht (wichtig, wenn der Windows PC als Router
für andere Clients im LAN fungiert).
[Ist das korrekt? Gibt es noch andere Treiber (für Dosen), die das
können?]
3.1.5 Windows XP
Die MTU/MSS vom XP-eigenen PPPoE Treiber lässt sich nicht einstellen, da
diese "fest" einprogrammiert ist. Die MTU/MSS für gewöhnliche
Netzwerkverbindungen werden genau so wie bei Windows 2000 eingestellt.
3.1.6 Windows 9x, ME und NT
Registry Einstellungen sind unter [4.12] zu finden.
3.1.7 Windows 2000
Registry Einstellungen sind unter [4.13] zu finden.
[Wer hat Ahnung von MAC bzw. den Treibern dafür bzw. den MTU, MSS,
eventuell MSS Clamp Einstellungen und möchte hier etwas zu beitragen?
Ich habe da selbst leider absolut NULL Ahnung.]
4. Links
4.1 RFC's - Request for Comments
Infos dazu gibt es unter http://www.rfc-editor.org/ [en].
* RFC 2516 - A Method for Transmitting PPP Over Ethernet (PPPoE)
* RFC 1661 - The Point-to-Point Protocol (PPP)
* RFC 1191 - Path MTU Discovery
* RFC 2913 - TCP Problems with Path MTU Discovery
* RFC 0793 - Transmission Control Protocol
* RFC 0879 - The TCP Maximum Segment Size and Related Topics
<just4fun - not related in any way>
* RFC 3251 - Electricity over IP
Man achte auf das Erstellungsdatum. Ein Schelm, wer Böses denkt! :-)
</just4fun>
MTU
4.2 [en] http://www.roaringpenguin.com/pppoe/als-pppoe-paper.pdf
Titel: A PPPoE Implementation for Linux
Speziell: Kapitel 4.5 The MTU
4.3 [en] http://penguin.dcs.bbk.ac.uk/~mick/academic/e-commerce/pdec/data-link/mtu.shtml
Maximum Transmission Unit (MTU)
4.4 [en] http://www.speedguide.net/editorials/packet_size.shtml
MTU, what difference does it make? [Allgemeines zur MTU]
PPPoE
4.5 [en] http://www.roaringpenguin.com/slides/pppoe-slides.pdf
Titel: PPPoE and Linux
PPPoE für Dummies. Three Thumbs up! Sehr anschaulich.
4.6 [en] http://www.carricksolutions.com/pppoe.htm
PPPoE FAQ (auch viele andere gute Seiten zum Thema)
Allgemeines, FAQ, HOWTO, ...
4.7 [de] http://www.adsl4linux.de/faq/
u.a. mit Abschnitten zur MTU
4.8 [en] http://www.linuxdoc.org/HOWTO/DSL-HOWTO/
u.a. mit Abschnitten zur MTU
4.9 [de] http://www.ruhr.de/home/nathan/FreeBSD/tdsl-freebsd.html
anschauliche Schilderung des Ablaufes und der Probleme mit der
MTU und MSS bei NAT
4.10 [en] http://lartc.org/HOWTO/cvs/2.4routing/output/2.4routing-15.html#ss15.6
Circumventing Path MTU Discovery issues with per route MTU settings
4.11 [en] http://lartc.org/HOWTO/cvs/2.4routing/output/2.4routing-15.html#ss15.7
Circumventing Path MTU Discovery issues with MSS Clamping
Seiten speziell zu Windows
4.12 [en] http://www.speedguide.net/Cable_modems/cable_registry.shtml
DSL Registry Settings for Win 9x, ME and NT
4.13 [en] http://www.speedguide.net/Cable_modems/cable_reg_win2k.shtml
DSL Registry Settings for Windows 2000 and XP
4.14 [en] http://user.cs.tu-berlin.de/~normanb/
RASPPPOE Treiber von Robert Schlabbach. DER PPPoE Treiber!
4.15 [en] http://www.dslreports.com/front/drtcp.html
DrTCP, Tool zur Netzwerkoptimierung für Win 9x/ME/NT/2000/XP
[Gilt eigentlich für alle Linkbereiche, aber aufgrund der IMHO vorhandenen
Korrelation zwischen OS und den Nutzern besonders für den Windows-Bereich:
Wer hat hier _deutschsprachige_ Linkempfehlungen? Ich weiß, keine
Verallgemeinerungen und Ausnahmen bestätigen die Regel usw...]
5. Danksagungen
Dank für Anregungen und konstruktive Kritik geht an
* Robert Schlabbach
* Oliver Gobin
* Norbert Micheel
* Harald Sauff
* und viele Andere.
5.1 Kommentare
Anregungen, Kommentare, Ergänzungen sind willkommen.
Bitte an Dominik Ruf, dominik+usenet (at) ruf.2y.net schicken. Danke.
[Bitte, bitte, lasst mich nicht hängen...]
/End.
Grüsse, Dominik
--
> wenn du jetzt auf frauen und die technik anspielst...dann bin ich in der
> hinsicht ein mann
Was nützt ein Schwanz beim Kernelkompilieren?
- Susi und Irina Rosenthal in de.talk.liebesakt
Oliver Gobin
>
> [...]
> 3.1.2 OpenBSD
>
> $ man ifconfig
> $ man ppp.conf
Das muss natuerlich 'man ppp' heissen. Entschuldigung, dass ich es dir
falsch gesagt habe.
Bei FreeBSD natuerlich auch...
Gruss,
Oliver
--
| Oliver Gobin | *----------------------------------------*
| WEB: http://www.ogobin.org | * Eine Null kann bestehende *
| MAIL: o...@ogobin.org | * Probleme verzehnfachen. *
| PGP: Finger me! | *----------------------------------------*
Oliver Gobin
* Dominik Ruf <domin...@stud.uni-karlsruhe.de> wrote:
> [...]
> Das Paradebeispiel sind die Seiten von GMX.
> Ebenso kann z.B. die Post nicht via POP3 von GMX abgeholt werden.
Bzw. man kann schon, solange die Post nicht 'zu gross' ist. Sollte
vielleicht noch rein, denn ich war etwas verwirrt, dass die meisten
Mails durchgekommen sind, und ploetzlich schluss war...
Gruss,
Oliver
--
| Oliver Gobin * Der Horizont vieler Menschen ist *
| WEB: http://www.OGobin.org/ * ein Kreis mit Radius Null - und *
| MAIL: o...@ogobin.org * das nennen sie ihren Standpunkt. *
| PGP: Finger me! * - Albert Einstein [1879-1955] *
Norbert Micheel
Noch zwei Antworten auf deine Fragen:
> Kann man bei Windows-Systemen sagen, dass man die MTU der PPPoE-
> Verbindung _immer_ _nur_ über den PPPoE-Treiber einstellen kann und dass
> die MTU-Geschichte in der Registry _immer_ _nur_ für "normale"
> Ethernet-Verbindungen geht?
Nein! Das Windows TCP/IP fragt den Treiber jedes Netzwerkinterfaces an das
es gebunden ist, was für eine MTU er gerne hätte, vergleicht das mit dem
Wert in der Registry für dieses Interface und benutzt den kleineren Wert.
Bei DSL über das Windows DFÜ-Netzwerk, ist die NIC für DSL der
Transportschicht _nicht_ als Interface bekannt (sie muss keine Bindung an
TCP/IP haben). Deshalb wird der PPPoE-Treiber nicht "gefragt".
Für Windows9X ist DSL dann eher ein "Pseudo-Modem", das über den DFÜ-Adapter
angesprochen wird.
Der DFÜ-Adapter ist als NDIS-Treiber implementiert und reagiert wie eine
Netzwerkkarte für die höheren Schichten. Er ist an TCP/IP gebunden und wird
als Netzwerk-Interface davon genutzt.
Wie alle an TCP/IP gebundenen NICs wird er nach seiner MTU "gefragt".
Da PPP aber keine Beschränkung der Paketgröße hat, meldet er glaube ich gar
nichts zurück (siehe auch Roberts Readme-Datei, der sich beschwert, das der
DFÜ-Adapter nicht seinen PPPoE-Treiber fragt).
Deshalb bleibt nur sein Registry-Eintrag:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Class\Net\000x:
IPMTU=xxx (Win9X)(IIRC default 576)
Diesen Parameter setzt aber jede DSL-Installation zumindest
"funktionierend", oder gar nicht (==> 576). Sonst hätte jeder
DSL-Einzelplatz schon das MTU-Problem.
Also zur Klarheit: Der NIC für DSL kannst du eine MTU verpassen wie du
willst, das wird die Paketgröße über PPPoE nicht verändern. Nur der
DFÜ-Adapter beeinflusst die Paketgröße.
> Ebenso ist der RASPPPOE Treiber der einzige Windows Treiber, der die
> MSS Clamp Option beherrscht (wichtig, wenn der Windows PC als Router
> für andere Clients im LAN fungiert).
>
> [Ist das korrekt? Gibt es noch andere Treiber (für Dosen), die das
> können?]
Das ICS von Windows kann so eine Art "einseitiges" MSS-Clamping. Es ersetzt
nur in den _rausgehenden_ TCP-Paketen mit SYN-Flag die MSS...
Gruss
Norbert
Norbert Micheel
Ich habe einfach mal so zum Vergleich einige Passagen etwas(brutal)
umformuliert:
> 1.1 MTU = Maximum Transmission Unit
>
> Die Maximum Transmission Unit (MTU) einer Netzwerk Schnittstelle
> (Interface) gibt das größtmögliche IP Datenpaket an, das ohne
> Fragmentierung (Aufsplittung in mehrere kleinere Pakete) über diese
> transportiert werden kann.
In Netzen auf Ethernet Basis (z.B. die meisten lokalen Netze) werden die IP
Datenpakete in sogenannten "Ethernet Frames" transportiert. Die maximale
Größe eines IP Datenpakets, das in einem einzelnen Ethernet Frame übertragen
werden kann ist 1500 Byte.
> Deshalb ist die Maximum Transmission Unit (MTU)
> einer Ethernet Schnittstelle (z.B. einer Netzwerkkarte im Rechner) 1500
> Byte groß.
> 1.2 PPPoE Point-to-Point Protokoll over Ethernet
> Viele xDSL Provider nutzen daher dessen Erweiterung PPP over Ethernet
> (PPPoE) für den Zugang.
Dabei werden -wie bei PPP- IP Pakete in PPP Pakete gepackt. Diese werden
dann aber in einem Ethernet Frame übertragen.
Ein PPPoE Paket hat einen 8 Byte großen Header.
1.3 MTU bei PPPoE
Eine Ethernet Verbindung hat laut Standard eine MTU von 1500 Byte.
In einem PPPoE Ethernet Frame werden 8 Byte für den PPPoE Header benötigt.
Es bleiben von den 1500 byte also noch 1492 Byte für den Inhalt des PPPoE
Paketes.
Ein übertragenes IP Datenpaket (der Inhalt eines PPPoE Paketes) kann also
1492 Bytes groß sein. Die MTU für PPPoE Verbindungen ist also 1492. (siehe
RFC 2516).
[ Das wir später den Rechner "verarschen", in dem wir einen anderen MTU-Wert
einstellen, hat hier meiner Meinung nach gar nichts verloren. ]
> 1.4 MSS = Maximum Segment Size
Während sich der Begriff MTU auf die Größe von IP-Paketen bezieht, gibt die
"Maximum Segment Size (MSS)" die maximale Größe des Datenanteils von
TCP-Paketen an.
Die MSS gibt also die Größe der reinen Nutzdaten eines TCP Paketes an. Im
> Regelfall wird dies die MTU [1.1] minus 40 Byte (das ist genau die Größe
> der TCP- und IP-Header) sein, also 1460 Byte für Ethernet-Verbindungen.
Für PPPoE-Verbindungen ergibt sich 1492 - 40 = 1452 Byte als MSS [1.3]
> Beim Aufbau einer TCP-Verbindung kann jede Seite optional die
> bevorzugte/gewünschte MSS angeben. Die Gegenseite wird dann auf jeden
Fall Pakete senden, die nicht größer sind als die gewünschte MSS.
> 2. Auswirkungen/Probleme bei "falscher" - will meist heißen: zu großer -
> MTU
>
Manche Webseiten funktionieren/laden nicht richtig, wenn sie auf einem
Client aufgerufen werden, der sich in einem lokalen Netz befindet, welches
mit DSL ans Internet angeschlossen ist.
> [Fehlerbeschreibungen]
>
Bilder auf der Website werden nicht angezeigt.
Das Paradebeispiel sind die Seiten von GMX, eBay.
> Ebenso kann z.B. die Post nicht via POP3 von GMX abgeholt werden.
>
> Gründe:
>
Der Server im Internet z.B. der von GMX (oder einer anderen Site, die nicht
funktioniert) sendet IP-Datenpakete mit mehr als 1492 Byte.
Er macht dies, wenn ihm vom Client eine MSS größer als 1452 beim
Verbindungsaufbau gesendet wurde, oder sein TCP/IP Header größer als der
Standard (40 Byte) ist.
Leider liegt zwischen den beiden Rechnern die "Engstelle" der
PPPoE-Verbindung, die eine MTU von 1492 hat - also größere Pakete nicht
weiterleiten kann.
> Und somit gehen die zu großen Pakete auf der PPPoE-Strecke verloren, ohne
> dass dies jemand bemerkt. :-(
> 3. Abhilfe/Lösungsmaßnahmen
> * Bei Einzelplatz-Systemen, bei denen der Rechner direkt mit dem DSL-
> Modem verbunden ist bzw. ein internes DSL-Modem verwendet...
>
... sollte es ausreichen, die MTU desjenigen Interfaces, an das die IP-
Datenpakete für die DSL-Verbindung gesendet werden, auf 1492 Byte zu
> setzen. (Oder gegebenenfalls - sprich: es funktionieren manche Sites
> immer noch nicht - noch niedriger, was aber IMHO nicht nötig sein
> sollte. Es ist mir auch noch kein solcher Fall bekannt.)
> * Bei Mehrplatz-Systemen mit zentraler Einwahl über einen Router...
> ... gibt es 2 Möglichkeiten, von denen man nur genau *eine* anwenden
> sollte:
>
* Der Router kann MSS-Clamping [1.5] betreiben. Dann sollte es
ausreichen, im Router die CLAMP-MSS auf 1452 Byte [1.4] einzustellen.
>
[END FAQ EDITING]
Gruss
Norbert
Dominik Ruf
> Und nochmal ich :)
Hey-ho Oliver, nur zu. Das "ppp.conf" habe ich in "ppp" umgeändert.
Danke für den Hinweis.
> * Dominik Ruf <domin...@stud.uni-karlsruhe.de> wrote:
>> [...]
>> Das Paradebeispiel sind die Seiten von GMX.
>> Ebenso kann z.B. die Post nicht via POP3 von GMX abgeholt werden.
> Bzw. man kann schon, solange die Post nicht 'zu gross' ist. Sollte
> vielleicht noch rein, denn ich war etwas verwirrt, dass die meisten
> Mails durchgekommen sind, und ploetzlich schluss war...
Der Abschnitt wurde jetzt durch
| Das Paradebeispiel sind die Seiten von GMX.
| Ebenso können z.B. E-Mails die größer als der momentan eingestellte
| MTU-Wert sind nicht via POP3 von GMX abgeholt werden. Die POP3-Verbindung
| "hängt" dann einfach.
ersetzt. Besser? ;-)
Übrigens sorry, dass ich hier im Thread jetzt schon zum 3. Mal so
ein Mega-Posting auf euch losgelassen habe. Dafür spare ich das ja
mit möglichst effektivem Quoting auf Dauer wo anders wieder locker ein. ;-)
Hat trotz dem langen Text vielleicht noch jemand ein paar Tipps zu
den markierten Stellen? *winsel* *fleh*
Gruss Dominik
--
"Nobody will ever need more than 640 kB RAM." (Bill Gates, 1983)
"Windows XP requires 64 MB RAM." (Bill Gates, 2001)
-> "Nobody will ever need Windows XP."