Kernelmeldung: pppd: Couldn't increase MRU to 1500 (T-DSL, SuSE 7.2 mit 4.2.2)
Hallo, Beim Start des pppoed und bei jeder Anwahl per T-DSL erscheint die Kernel-Meldung: pppd: Couldn't increase MRU to 1500. Zunächst dachte ich, ist nur ein Schönheitsfehler, da der Zugang und auch das Masquerading im Netzwerk funktioniert. Dann aber: beim Benutzen von z. B. Gnutella eines Clients "friert" der Server ein und ein Hard-Reboot ist nötig!! Einige Recherchen von mir ergaben, dass diese Meldung sich auf den pppoed bezieht, der keine Pakete größer als 1470 Byte weiterleiten kann. Dies bezog sich aber auf ältere Versionen des Kernels. Wer kann mir weiterhelfen und raten, was ich tun soll? Gruesse, Martin Kurz -- m_kurz@gmx.de
* Montag, 16. Juli 2001 um 11:53 (+0200) schrieb Martin Kurz:
Beim Start des pppoed und bei jeder Anwahl per T-DSL erscheint die Kernel-Meldung: pppd: Couldn't increase MRU to 1500.
Zunächst dachte ich, ist nur ein Schönheitsfehler, da der Zugang und auch das Masquerading im Netzwerk funktioniert.
"Im Prinzip" ist das auch nur ein Schönheitsfehler.
Dann aber: beim Benutzen von z. B. Gnutella eines Clients "friert" der Server ein und ein Hard-Reboot ist nötig!!
Kannst du "Einfrieren" genauer beschreiben.
Einige Recherchen von mir ergaben, dass diese Meldung sich auf den pppoed bezieht, der keine Pakete größer als 1470 Byte weiterleiten kann. Dies bezog sich aber auf ältere Versionen des Kernels.
Und ist IMHO falsch.
Wer kann mir weiterhelfen und raten, was ich tun soll?
Welche Meldungen erscheinen in '/var/log/messages' und/oder
'/var/log/warn' kurz vor dem "Einfrieren"?
Welchen PPPoE-Client verwendest du?
Welche pppd-Version? ('pppd -v')
Welche Kernel-Version?
Läuft ein Paketfilter? Wenn ja, welcher?
Gruß
Andreas
--
Andreas Könecke "Andreas Koenecke
On Mon, 16 Jul 2001 at 13:46 (+0200), Andreas Koenecke wrote:
* Montag, 16. Juli 2001 um 11:53 (+0200) schrieb Martin Kurz:
Beim Start des pppoed und bei jeder Anwahl per T-DSL erscheint die Kernel-Meldung: pppd: Couldn't increase MRU to 1500.
[...]
Einige Recherchen von mir ergaben, dass diese Meldung sich auf den pppoed bezieht, der keine Pakete größer als 1470 Byte weiterleiten kann. Dies bezog sich aber auf ältere Versionen des Kernels.
Und ist IMHO falsch. [...]
Laut Linux-Magazin 11/2000 (S. 34 ff.) liegt das an folgenden Gegebenheiten: - Die von der Telekom eingesetzten Cisco-Router erzwingen eine MTU/MRU von 1500 - durch den Protokoll-Overhead von PPPoE (PPP -> Ethernet -> ATM und zurück) sind max. 1472 Byte Nutzdaten möglich (bei NAT sogar nur 1412 Byte). Es wird dort empfohlen, die MRU / MTU auf diese Maximalwerte zu setzen. Ich kann das nicht aus eigener Erfahrung kommentieren (Isch abe gar kein DSL ;-), bei Bedarf einfach mal versuchen, diesen Artikel zu kriegen. Jan
* Montag, 16. Juli 2001 um 15:19 (+0200) schrieb Jan Trippler:
On Mon, 16 Jul 2001 at 13:46 (+0200), Andreas Koenecke wrote:
* Montag, 16. Juli 2001 um 11:53 (+0200) schrieb Martin Kurz:
Einige Recherchen von mir ergaben, dass diese Meldung sich auf den pppoed bezieht, der keine Pakete größer als 1470 Byte weiterleiten kann. Dies bezog sich aber auf ältere Versionen des Kernels.
Und ist IMHO falsch.
Laut Linux-Magazin 11/2000 (S. 34 ff.) liegt das an folgenden Gegebenheiten:
Das klingt arrogant, aber hier irrt das Linux-Magazin.
- Die von der Telekom eingesetzten Cisco-Router erzwingen eine MTU/MRU von 1500
Das ist -- salopp gesagt -- Quatsch. Die Telekom-Router erzwingen völlig korrekt eine MTU/MRU von 1492 (Wobei sich "korrekt" auf PPPoE bezieht, nicht aber auf PPP...). Sollte tatsächlich einmal ein fehlkonfigurierter Router ein MRU von 1500 erzwingen, dann geht _kein_ Paket mehr über die PPPoE-Verbindung (s.u). (Wobei ich noch anmerken möchte, dass die Cisco-Router die "besseren" sind, die anderen -- von einem "großen deutschen Hersteller"[tm] -- haben schon Probleme, ein fehlerfreies PPP-Handshake durchzuführen.)
- durch den Protokoll-Overhead von PPPoE (PPP -> Ethernet -> ATM und zurück) sind max. 1472 Byte Nutzdaten möglich (bei NAT sogar nur 1412 Byte).
Das ist genauso falsch. Begründung (Ich lasse mal die ATM- und ADSL-Layer weg, sie sind transparent): 1.) Ein Ethernet-Frame (Verbindung Computer -- Telekom-AC) kann eine maximale Nutzlast von 1500 Byte aufnehmen. 2.) In dieses Ethernet-Frame wird ein PPP-Datagramm gekapselt. Dabei "braucht" PPPoE 6 Byte und PPP 2 Byte (RFC 2516), ergibt zusammen 8 Byte und somit eine max. Nutzlast von 1492 Byte (=MRU/MTU) für den PPP-Link. 3.) Davon gehen noch einmal 20 Byte für den IP-Header und 20 Byte für den TCP-Header ab, so dass letztendlich 1452 Byte für die Nutzdaten bleiben ("Maximum Segement Size", MSS). Und zu NAT: Seit wann werden bei NAT die Header vergrößert? Die Header werden "umgeschrieben", da wird nichts dazugepackt. (Zumindest wenn es "echtes" NAT ist, also nicht wie beim ICS...)
Es wird dort empfohlen, die MRU / MTU auf diese Maximalwerte zu setzen.
Im Prinzip kann man die MTU/MRU-Optionen des 'pppd' auf beliebige Werte setzen, beim LCP-Chat mit dem Telekom-Router wird(/sollte) immer eine MRU von 1492 ausgehandelt.
bei Bedarf einfach mal versuchen, diesen Artikel zu kriegen.
Schade, er ist leider (noch) nicht online verfügbar, ich hätte ihn
gerne gelesen. Wer ist denn der Autor?
Gruß
Andreas
--
Andreas Könecke "Andreas Koenecke
On Mon, 16 Jul 2001 at 21:06 (+0200), Andreas Koenecke wrote: [Korrekturen zu den Aussagen eines LM-Artikels]
Schade, er ist leider (noch) nicht online verfügbar, ich hätte ihn gerne gelesen. Wer ist denn der Autor?
Michael Schlenstedt, ich habe leider keine Mailadresse gefunden. Frag doch bei Bedarf mal beim LM an. Der Artikel hieß: "Surferparadies - TDSL unter Linux". Interessante Infos - wenn (falls) ich demnächst TDSL kriege, werde ich das nutzen können (man glaubt es nicht, aber wenn die Telekom Konkurrenz durch ein örtliches Unternehmen kriegt, versprechen sie Dir den Zugang innerhalb von 2 Wochen ;-). Jan
* Montag, 16. Juli 2001 um 22:56 (+0200) schrieb Jan Trippler:
On Mon, 16 Jul 2001 at 21:06 (+0200), Andreas Koenecke wrote:
Wer ist denn der Autor?
Michael Schlenstedt, ich habe leider keine Mailadresse gefunden.
Kein Problem, "man" kennt sich aus Usenet und PM... Ich vermute, dass Michael jene Teile des Artikels heute eher peinlich sind. "Zum Ausgleich" ;-) hat er jedoch "http://www.adsl4linux.de" aufgebaut, wo die PPPoE-Konfiguration ausführlich beschrieben wird.
(man glaubt es nicht, aber wenn die Telekom Konkurrenz durch ein örtliches Unternehmen kriegt, versprechen sie Dir den Zugang innerhalb von 2 Wochen ;-).
Wenn sie wollen, dann können sie auch. Aber bis sie wollen... ;-)
Gruß
Andreas
--
Andreas Könecke "Andreas Koenecke
On Monday, 16. July 2001 21:06, Andreas Koenecke wrote:
Im Prinzip kann man die MTU/MRU-Optionen des 'pppd' auf beliebige Werte setzen, beim LCP-Chat mit dem Telekom-Router wird(/sollte) immer eine MRU von 1492 ausgehandelt.
Schoen, aber wie kommt es zu dieser Fehlermeldung (siehe Subject) - nebenbei, ich benutze natuerlich die Kernelversion 2.4.4, nicht 4.2.2 ;-) Ich habe spaßeshalber mal eine neuere Version des pppd ausprobiert (LinuxUser 08/2001), der fuer pppoed gepacht war. Abgesehen davon, dass bei der Verbindung irgendeine Kleinigkeit nicht klappte, hatte dieses Modul die gleiche Fehlermeldung zur Folge: pppd: Couldn't increase MRU to 1500. pppd: Couldn't increase MTU to 1500. Mein Verdacht ist jetzt, dass es gar nicht an pppd bzw. pppoed liegt, sondern an den Kernel 2.4.4 bzw. irgendeine Konfiguration des lokalen Netzwerkes. Koennte dies moeglich sein? Den MRU bzw. MTU fuer die Netzwerkkarten zu veraendern, z. B. runterzusetzen, hat gar nichts gebracht! Die Meldung des pppd blieb. Wer kann helfen? Martin -- m_kurz@gmx.de
* Montag, 16. Juli 2001 um 22:59 (+0200) schrieb Martin Kurz:
Schoen, aber wie kommt es zu dieser Fehlermeldung (siehe Subject)
Erst einmal vorneweg: Die beiden Meldungen haben *keine* Auswirkungen auf die Funktionalität von PPPoE und sind *nicht* Ursache deines Problems. Diese Meldungen bekommt jeder, der PPPoE mit dem gepatchten pppd benutzt. Die Meldungen wurden hier in der Liste schon vor 1-2 Wochen diskutiert, die wahre Ursache wird aber wohl nur Michael Ostrowski, der Entwickler der PPPoE-Erweiterungen des pppd, erklären können. Vielleicht ist es "nur" eine Warnung, dass PPPoE den RFC 1661 (PPP) verletzt?
Mein Verdacht ist jetzt, dass es gar nicht an pppd bzw. pppoed liegt, sondern an den Kernel 2.4.4 bzw. irgendeine Konfiguration des lokalen Netzwerkes. Koennte dies moeglich sein?
"Nichts ist unmöglich."[tm] Nur ohne weitere Informationen tappen wir
im Dunkeln. Beantworte doch bitte noch die ausstehenden Fragen plus
Zusatzfrage: Was für eine Netzwerkkarte benutzt du?
(Falls Thilko Cullmann, der ja anscheinend ein ähnliches Problem hat,
diesen Thread gefunden hat, bitte hier mit einsteigen...)
Gruß
Andreas
--
Andreas Könecke "Andreas Koenecke
On Mon, 16 Jul 2001, Martin Kurz wrote:
pppd: Couldn't increase MRU to 1500. pppd: Couldn't increase MTU to 1500. Die Meldung des pppd blieb. Wer kann helfen?
# grep 'm[rt]u' /etc/ppp/options
# mru 576
# mtu 576
(das ist mit Modem und auskommentiert, aber eben pppd)
Vielleicht sollte man diese Werte mal anpassen, wie's scheint
werden die einem der beteiligten Programme/config-Dateien auf
1500 gesetzt[1]... Soweit ich das mitbekommen habe, sollten die
bei ADSL auf
mru 1452
mtu 1452
(oder kleiner) stehen...
-dnh
[1] oder von der Einwahlgegenstelle so "angefordert", da muesste
sich dann aber entsprechendes in /var/log/messages finden:
rcvd [LCP ConfReq id=0x1
pppd: Couldn't increase MTU to 1500. Die Meldung des pppd blieb. Wer kann helfen?
Hallo Martin, wäre interessant zu vergleichen, ob Deine Systemkonfig. unserer ähnelt. Wir setzen folgendes ein: Server: alter Celeron 433 Linux: SuSE 7.2 mit 2.4er Kernel Netzwerkkarten: 2x 3Com905B-TX intern sind wir im 192.168.0.x Bereich Weiterhin läuft Squid, SAMBA, IP-Tables-Firewall mit Masq./Routing. Ich bin auch der Ansicht, dass es nicht unbedingt mit der MRU-1500-Meldung zusammenhängt. Ansonsten ist es noch merkwürdig, dass der Verbindungsaufbau bis zu 10 Sekunden dauert. - Ist das normal? Die sagen doch das das extrem schnell sein soll (Standleitungsmässig)??? Der Fehler ist übrigens ähnlich: Das System friert ohne weitere Einträge in den Logfiles ein. Neustart geht nur noch mit Reset. Im Normalbetrieb läufts reibungslos... Hat vielleicht noch jemand einen anderen Ansatz (Kernel/3Com-Karte)? Gruss Thilko
Hi,
Hat vielleicht noch jemand einen anderen Ansatz (Kernel/3Com-Karte)?
andere Konfiguration, gleiches Problem: SuSE 7.2, Kernel 2.4.4 NE2000-Clone mit REALTEC 8029 Chip zum ADSL-Modem REALTEC 8139 zum lokalen Netz PPOED und PPP von der SuSE 7.2 Firewall mit IPTABLES (SuSEfirewall2) Rechner bleibt ohne jede Ausgabe auf Konsole oder Logfile stehen - unregelmaessig bei Mail-Verkehr - reproduzierbar, falls ein Client Limewire startet Alle nicht notwendigen Services (Samba, DNS, SQUID, Apache..) auf dem Linux sind abgeschaltet - keine Veränderung. Probeweise auf Firewall1 mit ipchains zurück - keine Verbesserung. Nach zwei Tagen Basteln und Probieren bin ich jetzt wieder auf 2.2.18 zurück - damit läuft ADSL hier im Netz problemlos und stabil. Hans Peter
On Tuesday, 17. July 2001 12:45, Thilko Cullmann wrote:
pppd: Couldn't increase MTU to 1500. Die Meldung des pppd blieb. Wer kann helfen?
Hallo Martin,
Hallo Thilko, hallo auch Andreas Koenecke,
wäre interessant zu vergleichen, ob Deine Systemkonfig. unserer ähnelt. Wir setzen folgendes ein: Server: alter Celeron 433 Linux: SuSE 7.2 mit 2.4er Kernel
Ja, genau, habe ich auch: Standard-Installation SuSE7.2 mit Kernel 2.4.4
Netzwerkkarten: 2x 3Com905B-TX
Stimmt fast auch, benutze die gleiche Karte und eine Fast-Ethernet-PCI-Karte Realtek-Chip.
intern sind wir im 192.168.0.x Bereich Weiterhin läuft Squid, SAMBA, IP-Tables-Firewall mit Masq./Routing.
ja, Squid läuft und Masq. mit ipchains
Ich bin auch der Ansicht, dass es nicht unbedingt mit der MRU-1500-Meldung zusammenhängt. Ansonsten ist es noch merkwürdig, dass der Verbindungsaufbau bis zu 10 Sekunden dauert. - Ist das normal? Die sagen doch das das extrem schnell sein soll (Standleitungsmässig)??? Der Fehler ist übrigens ähnlich: Das System friert ohne weitere Einträge in den Logfiles ein. Neustart geht nur noch mit Reset. Im Normalbetrieb läufts reibungslos...
Das ist auch mein Symptom (Sorry, Andreas, aber das mit der Meldung war mir nicht gleich klar.).
Hat vielleicht noch jemand einen anderen Ansatz (Kernel/3Com-Karte)?
Ich denke, es liegt irgendwie am SuSE 7.2 System mit dem Kernel - ist nur ein Gefühl ... Grüße, Martin -- m_kurz@gmx.de
* Dienstag, 17. Juli 2001 um 12:45 (+0200) schrieb Thilko Cullmann:
Ansonsten ist es noch merkwürdig, dass der Verbindungsaufbau bis zu 10 Sekunden dauert. - Ist das normal? Die sagen doch das das extrem schnell sein soll (Standleitungsmässig)???
Nein, "normal" ist das nicht. Aber vermutlich hängt dein Anschluss an
einem Siemens-AC, die machen (wohl immer noch) Fehler beim
PPP-Handshake. Das kannst du prüfen, wenn du in der Optionen-Datei des
'pppd' (evtl. '/etc/ppp/options', auch bei 7.2?) die Option "debug"
setzt und in '/var/log/messages' das Handshake beobachtest.
Gruß
Andreas
--
Andreas Könecke "Andreas Koenecke
participants (6)
-
Andreas Koenecke -
David Haller -
Hans Peter Dittler -
Jan.Trippler＠t-online.de -
Martin Kurz -
Thilko Cullmann