T_DSL und MTU Problem - such hilfe
ich kann bei t-dsl manche webseiten nicht erreichen. einen artikel von suse gibt es hier: http://sdb.suse.de/de/sdb/html/cg_pmtu.html (bitte lese - unten unter "Lösung") Ich muss von meiner netzwerkkarte die MTU auf 1400 verkleinern doch die dort vorgeschlagene methode geht nicht. Ich bin mir sicher dass dies mein Problem ist da lösung 3 (die temporäre Lösung wie sie da beschrieben ist, bis auf den syntaxfehler) funktioniert. ich habe IFCONFIG_0="10.0.0.1 broadcast 10.0.0.255 netmask 255.255.255.0 mtu 1440" IFCONFIG_1="192.168.0.1 dynamic pointopoint 192.168.0.99 netmask 255.255.255.255 up" in /etc/rc.config. (das mtu 1400 wird übrigens von yast2 immer gelöscht wenn ich die netzwerkkonfiguration ändere) es funktioniert aber nicht. linux:/home/neutrino # netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 217.5.98.94 0.0.0.0 255.255.255.255 UH 40 0 0 ppp0 192.168.0.99 0.0.0.0 255.255.255.255 UH 40 0 0 ippp0 10.0.0.0 0.0.0.0 255.255.255.0 U 40 0 0 eth0 0.0.0.0 217.5.98.94 0.0.0.0 UG 40 0 0 ppp0 linux:/home/neutrino # MSS 40 bei methode 3 wird MSS auf 1400 gesetzt und das funktionierte auch - es stnd im routing table MSS 1400.... leider kenne ichmich nicht sehr gut aus mit netzwerkhardwarekonfiguration und weiß nicht was ich weiter probieren soll. Aron Fischer PS ich bekomme auserdem folgende meldungen: (/var/log/warn) Oct 26 16:17:14 linux kernel: eth0: RealTek RTL-8029 found at 0xc400, IRQ 7, 00:20:18:39:0A:AF. linux pppd[1044]: Couldn't increase MTU to 1500. linux pppd[1044]: Couldn't increase MRU to 1500 sowie linux dhcpcd[7074]: timed out waiting for a valid DHCP server response was ist hier falsch? -- ################################################################################## # "I can't even remember what it was I came here to get away from" - Bob # Dylan on "Time out of Mind" # "Between air-conditioning and the pope, I'd choose the air-conditioning" - # Woody Allen in "Deconstructing Harry" ##################################################################################
Aron Fischer wrote:
Ich muss von meiner netzwerkkarte die MTU auf 1400 verkleinern doch die dort vorgeschlagene methode geht nicht.
Mein derzeitiger Workaround ist: Setzen von ppp0 (eth0 spielt keine Rolle) auf 1412. Konnte mich noch nicht darum kümmern, warum es gerade dieser Wert tut. Das in Manuals vorgeschlagene mtu=1492, das es eigentlich tun sollte (dsl overhead is 8 bytes, also 1500-8=1492) tat es bei mir nicht. - Matthias
On Friday 26 October 2001 17:52, Matthias Kleine wrote:
Aron Fischer wrote:
Ich muss von meiner netzwerkkarte die MTU auf 1400 verkleinern doch die dort vorgeschlagene methode geht nicht.
Mein derzeitiger Workaround ist:
Setzen von ppp0 (eth0 spielt keine Rolle) auf 1412. Konnte mich noch nicht darum kümmern, warum es gerade dieser Wert tut. Das in Manuals vorgeschlagene mtu=1492, das es eigentlich tun sollte (dsl overhead is 8 bytes, also 1500-8=1492) tat es bei mir nicht.
Setzen von ppp0 auf 1412. WIE?!
aron -- ################################################################################## # "I can't even remember what it was I came here to get away from" - Bob # Dylan on "Time out of Mind" # "Between air-conditioning and the pope, I'd choose the air-conditioning" - # Woody Allen in "Deconstructing Harry" ##################################################################################
Am Freitag, 26. Oktober 2001 18:36 schrieben Sie:
Setzen von ppp0 auf 1412.
WIE?!
$ ifconfig ppp0 mtu 1412 Des weiteren gibt es in der Datei /etc/ppp/options die Möglichkeit, den Eintrag mtu 1412 hinzuzufügen, um die Einstellung nicht nach jedem Aufbau des Interfaces händisch vornehmen zu müssen. - Matthias -- LPI Level 1 Certified http://www.selflinux.de
* Matthias Kleine schrieb am 27.10.01 um 01:01 Uhr:
Am Freitag, 26. Oktober 2001 18:36 schrieben Sie:
Setzen von ppp0 auf 1412.
WIE?!
$ ifconfig ppp0 mtu 1412
Des weiteren gibt es in der Datei /etc/ppp/options die Möglichkeit, den Eintrag
mtu 1412 hinzuzufügen, um die Einstellung nicht nach jedem Aufbau des Interfaces händisch vornehmen zu müssen.
1492 tuns auch. -Marc -- BUGS My programs never have bugs. They just develop random features. If you discover such a feature and you want it to be removed: please send an email to bug@links2linux.de
Am Samstag, 27. Oktober 2001 01:33 schrieb Marc Schiffbauer:
$ ifconfig ppp0 mtu 1412
1492 tuns auch.
Dem ist leider nicht so, da hast Du die Diskussion offenbar nicht verfolgt. - Matthias -- LPI Level 1 Certified http://www.selflinux.de
Hallo an alle Vorredner und Mitleser, verfolge hier seit geraumer Zeit die "MTU-Diskussion" teilweise mit einigem Verwundern weil ... bei uns läuft seit ziemlich genau einem Jahr ein T-DSL Anschluß mehr oder weniger fehlerfrei (2 x Reset des LTBBA bei der Telekom nötig da Totalausfall, ab und zu DNS Probs bei T-Online). Bei uns läuft auf dem Router Suse 7.0 (Kernel 2.2.16 nix dran gemacht weil Anfänger) alle Pakete für DSL etc von dieser Distri, zwei Netzwerkkarten (Karte für DSL = DEC Chip dc21x4x) die Einrichtung des DSL erfolgte manuell nach einer Anleitung aus www.linuxbu.ch und einer Readme-Datei von T-Online. Eingestellt von Anfang an war der MTU/MRU-Wert 1490 !!! (weil so in der Doku von T-Online) und funktionieren tuts auch. Hardware auf Seiten der Telekom ist Siemens Hi-Focus, Splitter und Modem somit auch von Siemens. Soweit so gut ... Hatte diese Woche Probleme mit einem Windows Einzelplatzrechner und DSL-Anschluß, produzierte die hier im Zusammenhang genannten Fehler - nach einigem Basteln und Empfehlung der Hotline MTU Wert auf 1492 zu ändern (was auch nicht zum Erfolg führte) wurde auf Anraten der Technischen Hotline der Telekom die Netzwerkkarte gegen eine mit "Freigabe-Segen" der Telekom ausgetauscht - und siehe da Fehler verschwunden ohne basteln an MTU o.ä. !!! Wäre somit interessant zu wissen wenn bei Rechner "A" DSL nur mit MTU 1412 und bei Rechner "B" mit 1452 ... läuft, welche Hardware im Rechner und bei der Telekom (ECI oder Siemens) vorhanden ist. Hintergrund: Ab Jahreswechsel liefert die Telekom keine kostenlosen und "passenden" Modem (NTBBA) mehr aus, da ab dann ein Universalprotokoll gefahren wird - mir graut's jetzt schon davor. Mfg Eric
Hallo, at Tuesday 30.10.2001 (20:19 +0100), Eric Scheen wrote:
verfolge hier seit geraumer Zeit die "MTU-Diskussion" teilweise mit einigem Verwundern weil ...
Bei mir läuft DSL seit Februar 2001 fehlerfrei. Zuerst auf einer Windowskiste (Win2k) und seit Ende August Anfang September auf Redhat Linux 7.0 mit einem 2.2.19 Kernel ebenfalls fehlerfrei. Ich habe mich an der Anleitung auf http://www.adsl4linux.de/ gehalten. Das DSL-Modem hängt direkt an einer Realtek Semiconductor Co., Ltd. RTL-8139 (rev 10). Das ist die Netzwerkkarte, die ich von der Telekom für 1,- DM erhalten habe. Von welcher Firma das DSL-Modem ist kann nicht sagen. Ich weiss nur, das es ein tierisch großes Teil ist, wo die LED's an der Seite angebracht sind. Auch ich musste das Teil nach ca. 650 Onlinestunden mal resetten. Mit dem Nameserver hatte ich allerdings keine Probleme. Aber Du hast Recht, das ein DSL-Modem nicht überall funktioniert. Da kannst Du dann rumdoktern wie Du willst, es klappt einfach nicht. Ein bekannter von mir hatte auch das Problem, das er keine DSL-Verbindung bekam. Als die dann das DSL-Modem ausgetauscht hatten, funktioniert alles einwandfrei. Aber T-Online geht erstmal davon aus, das der User unfähig ist, seinen Rechner zu konfigurieren. Auch wenn der Rechner X Stunden mit DSL einwandfrei gelaufen ist, ist der Rechner des Users aufeinmal falsch konfiguriert. Es rennt ja auch eine Herde Heinzelmännchen in meiner Bude rum ;-) Als Linuxuser hat man eh schlechte Karten. Denn die Hotline ist ja schon mit Windows 9X/NT überfordert. Gruß Michael -- Phone/Fax +49 7000 MACBYTE (+49 7000-6222983) Registered Linux User #228306 HomePage http://www.macbyte.info/ PGP-Key http://www.macbyte.info/shared/mykey.pkr ++ CGI-Hosting ++ Domains ++ Webspace ++ PHP Development ++
Eric Scheen wrote:
Wäre somit interessant zu wissen wenn bei Rechner "A" DSL nur mit MTU 1412 und bei Rechner "B" mit 1452 ... läuft, welche Hardware im Rechner und bei der Telekom (ECI oder Siemens) vorhanden ist.
Im Grunde müßte man hier mal ein Onlineformular ins Netz stellen, in dem verschiedene User Ihre Hardware + Konfig eintragen und angeben können, ob es so läuft oder nicht. Im Moment scheint mir das ganze wirklich ein ziemliches Verwirrspiel zu sein. Die einen fummeln an eth0, die anderen an ppp0, andere wiederum versuchens über mss-mangeling der firewall, aber es gibt offenbar keinen Königsweg. So blöd können wir ja nicht alle sein, da scheint es mir gut möglich, daß unterschiedliche Hardware die Unterschiede macht. - Matthias
Hallo,
Matthias Kleine
Eric Scheen wrote:
Wäre somit interessant zu wissen wenn bei Rechner "A" DSL nur mit MTU 1412 und bei Rechner "B" mit 1452 ... läuft, welche Hardware im Rechner und bei der Telekom (ECI oder Siemens) vorhanden ist.
Im Grunde müßte man hier mal ein Onlineformular ins Netz stellen, in dem verschiedene User Ihre Hardware + Konfig eintragen und angeben können, ob es so läuft oder nicht. Im Moment scheint mir das ganze wirklich ein ziemliches Verwirrspiel zu sein. Die einen fummeln an eth0, die anderen an ppp0, andere wiederum versuchens über mss-mangeling der firewall, aber es gibt offenbar keinen Königsweg. So blöd können wir ja nicht alle sein, da scheint es mir gut möglich, daß unterschiedliche Hardware die Unterschiede macht.
Ich denke, ein paar grundsätzliche Bemerkungen zu ADSL, Ethernet und TCP/IP zum Verständnis des Problems sind mal angebracht. Das Ethernet Protokoll kann nur Datenpakete bis 1500 byte behandeln. Das TCP/IP Protokoll benötigt für jedes Datenpaket einen Header von min. 8 byte, bleiben für ethernet netto 1492 byte übrig. Das Asynchrone Transfer Mode Protokoll (mit dem ADSL operiert) kann größere Datenpakete behandeln. Der Linux Kernel kann grundsätzlich größere Datenpakete behandeln, dies kann mit dem Parameter Allow_Large_Frames eingestellt werden, allerdings können Paketfilter diese großen Datenpakete nicht handhaben, daher erstellt und behandelt der Kernel als default nur Datenpakete bis zu 1500 byte. Sowohl über die Konfiguration der Ethernetkarte als auch über die Konfiguration des ppp Devices kann der Gegenstelle die mögliche Paketgrößere mitgeteilt werden. Die Aufgabe der Umwandlung von Datenpaketen in die unterschiedlichen Protokolle obligt dem Splitter und ich denke daß hier das Problem liegt, da im Header der Datenpakete noch weitere ATM relevante Daten enthalten sein können, die die Größe des Nettodatensatzes reduzieren. Ich vermute aber, daß dies ein Problem des jeweiligen Splittermodels ist, das konnte ich aber noch nicht verifizieren. -Dieter -- Dieter Kluenter | Systemberatung Tel:040.64861967 | Fax: 040.64891521 mailto: dkluenter@schevolution.com http://www.schevolution.com/tour
Dieter Kluenter wrote:
Das Ethernet Protokoll kann nur Datenpakete bis 1500 byte behandeln. Das TCP/IP Protokoll benötigt für jedes Datenpaket einen Header von min. 8 byte, bleiben für ethernet netto 1492 byte übrig.
Das ist AFAIK nicht korrekt. IIRC verbraucht TCP/IP 40 Bytes, nämlich je 20 für IP und für TCP. Die 8 Bytes sind DSL-Overhead. - Matthias
* Mittwoch, 31. Oktober 2001 um 12:06 (+0100) schrieb Dieter Kluenter:
Ich denke, ein paar grundsätzliche Bemerkungen zu ADSL, Ethernet und TCP/IP zum Verständnis des Problems sind mal angebracht.
Da stimme ich dir zu, die Bemerkungen sollten aber richtig sein...
Das Ethernet Protokoll kann nur Datenpakete bis 1500 byte behandeln. Das TCP/IP Protokoll benötigt für jedes Datenpaket einen Header von min. 8 byte, bleiben für ethernet netto 1492 byte übrig.
Dazu hat Matthias ja schon die Berichtigung gepostet.
Der Linux Kernel kann grundsätzlich größere Datenpakete behandeln, dies kann mit dem Parameter Allow_Large_Frames eingestellt werden,
Das gilt aber nur für Gigabit-Ethernet. Nur dort gibt es bisher die sog. "Jumbo-Frames".
allerdings können Paketfilter diese großen Datenpakete nicht handhaben, daher erstellt und behandelt der Kernel als default nur Datenpakete bis zu 1500 byte.
Nicht wegen des Paketfilters, sonder weil 10/100 Base-X-Ethernet keine größere MTU haben kann.
Sowohl über die Konfiguration der Ethernetkarte als auch über die Konfiguration des ppp Devices kann der Gegenstelle die mögliche Paketgrößere mitgeteilt werden.
Die MTU der Ethernetkarte (solange sie nur an das T-DSL-"Modem" angeschlossen ist) ist bei PPPoE _ohne_ Relevanz. Die MTU des ppp-Devices wird beim Verbindungsaufbau mit der Gegenstelle ausgehandelt. Ich habe noch keinen Fall (T-DSL) gesehen, wo dort nicht 1492 ausgehandelt wurde, unabhängig von den Optionen des pppd.
Die Aufgabe der Umwandlung von Datenpaketen in die unterschiedlichen Protokolle obligt dem Splitter
Dem Splitter mit Sicherheit nicht, das ist lediglich eine Frequenzweiche und sonst nichts... Eventuell meinst du den NTBBA (ADSL-"Modem"). Aber auch das nimmt keine Umwandlung der Datenpakete vor, sondern eine Kapselung: Die Ethernet-Frames, in denen schon die PPP-Pakete gekapselt sind, werden in ATM-Zellen gekapselt und über ADSL and den DSLAM übertragen.
und ich denke daß hier das Problem liegt, da im Header der Datenpakete noch weitere ATM relevante Daten enthalten sein können, die die Größe des Nettodatensatzes reduzieren.
Nein, sie ATM-Zellen sind um den ATM-Overhead größer als die Ethernet-Frames.
Ich vermute aber, daß dies ein Problem des jeweiligen Splittermodels ist, das konnte ich aber noch nicht verifizieren.
Sehr unwahrscheinlich, denn die MTU betriftt die Verbindung
Computer -- AC, der NTBBA und der DSLAM (in der Vermittlungsstelle)
sind für die Ethernet-Frames und erst recht für PPP transparent.
Falls man nach systematischen, hardwarebedingten Fehlern suchen will,
wäre eher der Typ und Ort des AC interessant, da es dort schon
Unterschiede geben kann.
Gruß
Andreas
--
Andreas Könecke "Andreas Koenecke
Setzen von ppp0 auf 1412.
WIE?!
$ ifconfig ppp0 mtu 1412
Des weiteren gibt es in der Datei /etc/ppp/options die Möglichkeit, den Eintrag
mtu 1412 hinzuzufügen, um die Einstellung nicht nach jedem Aufbau des Interfaces händisch vornehmen zu müssen.
- Matthias
tja und heute morgen hat suse den artikel im SDB noch mal erweitert. jetzt gehts auch bei mir. ich hatte einen mtu von 1400 am eth0 aber 1492 bei ppp0 (was nicht geht marc ;-) jetzt habe ich mtu und mru in /etc/ppp/options auf 1486 gesetzt und es geht alles. danke nochmal an alle. Aron Fischer -- ################################################################################## # "I can't even remember what it was I came here to get away from" - Bob # Dylan on "Time out of Mind" # "Between air-conditioning and the pope, I'd choose the air-conditioning" - # Woody Allen in "Deconstructing Harry" ##################################################################################
Hallo Matthias, * Samstag, 27. Oktober 2001 um 01:01 (+0200) schrieb Matthias Kleine:
Des weiteren gibt es in der Datei /etc/ppp/options die Möglichkeit, den Eintrag
mtu 1412 hinzuzufügen, um die Einstellung nicht nach jedem Aufbau des Interfaces händisch vornehmen zu müssen.
kannst du bei Gelegenheit einmal den pppd mit der 'debug'-Option
starten lassen und im Log kontrollieren, ob der Telekom-PPP-Server die
1412 auch annimmt.
Hier bei mir kann ich eine beliebige MTU/MRU vorgeben; beim
Verbindungsaufbau wird stets eine MTU/MRU von 1492 ausgehandelt. Mich
würde interessieren, ob das evtl. vom AC abhängig ist.
Gruß
Andreas
--
Andreas Könecke "Andreas Koenecke
Am Samstag, 27. Oktober 2001 13:31 schrieb Andreas Koenecke:
Hier bei mir kann ich eine beliebige MTU/MRU vorgeben; beim Verbindungsaufbau wird stets eine MTU/MRU von 1492 ausgehandelt. Mich würde interessieren, ob das evtl. vom AC abhängig ist.
Sieht bei mir wohl genausu aus. Obwohl ich die mtu in ppp/options auf 1490 gesetzt habe, wird das Interface bei Verbindung mit 1492 aufgebaut - was nicht funktioniert! Erst wenn ich das Interface (ppp0) danach wieder händisch auf 1490 runtersetze, geht es. Ich bin jetzt also so weit, daß mtu-Werte <= 1490 funktionieren, da überall genannte 1492 tut es jedoch nicht. Interessanterweise nennt jedoch auch SuSE den Wert 1490 in der SDB, und selbst in der Datei /etc/ppp/peers/pppoe ist dieser Wert Default, wird aber offenbar mit smpppd garnicht herangezogen. Einzige Unschönheit ist nun also noch, daß ich nach jedem Verbindungsaufbau ppp0 händisch konfigurieren muß, da ich keine andere Stelle als ppp/options kenne, wo ich die mtu vorkonfigurieren könnte bzw. da beim Verbindungsaufbau fälschlicherweise trotzdem immer 1492 ausgehandelt wird. Ich kann es noch verschmerzen, da ich wg. Flat ohnehin meist online bleiben kann, aber das will mal ja eigenltich auch nicht... - Matthias -- LPI Level 1 Certified http://www.selflinux.de
Hallo Matthias. * Samstag, 27. Oktober 2001 um 15:41 (+0200) schrieb Matthias Kleine:
Sieht bei mir wohl genausu aus. Obwohl ich die mtu in ppp/options auf 1490 gesetzt habe, wird das Interface bei Verbindung mit 1492 aufgebaut - was nicht funktioniert! Erst wenn ich das Interface (ppp0) danach wieder händisch auf 1490 runtersetze, geht es.
Das ist ja ziemlich seltsam...
Ich habe dazu noch einmal ein paar Fragen:
Macht der Router noch zusätzlich MSS-Clamping?
Hast du die MTU der Client-Netzwerkkarten oder der Netzwerkkarte, an
der die Clients "hängen", verändert?
Funktionieren die problematischen Sites _auf_dem_Router_ auch ohne das
Heruntersetzen der MTU?
Ich habe hier eine 7.3 inclusive der Patches/Updates aufgebaut, mit
deren Routing/Masquerading es keine Probleme gibt. (Zumindest nicht in
dem kurzen Test, den ich hier durchgeführt habe, inklusive der beiden
URLs (paulskaffebar und xmasshop), die hier als problematisch gepostet
wurden.)
Der einzige Unterschied zu einer Original-7.3 liegt in einem
selbsterstellten Kernel (2.4.10).
Ich habe langsam den Verdacht, dass das Problem in der Konfiguration
oder den Patches des SuSE-Kernels zu finden ist?
Gruß
Andreas
--
Andreas Könecke "Andreas Koenecke
Am Samstag, 27. Oktober 2001 23:47 schrieb Andreas Koenecke:
Sieht bei mir wohl genausu aus. Obwohl ich die mtu in ppp/options auf 1490 gesetzt habe, wird das Interface bei Verbindung mit 1492 aufgebaut - was nicht funktioniert! Erst wenn ich das Interface (ppp0) danach wieder händisch auf 1490 runtersetze, geht es.
Das ist ja ziemlich seltsam... Ich habe dazu noch einmal ein paar Fragen:
Macht der Router noch zusätzlich MSS-Clamping?
Also, zunächstmal: Die Maschine ist primär kein Router, es ist meine Workstation. Routing ist nur "nebenbei" von Bedeutung für einen weiteren Rechner in meinem Netz. MSS-Clamping habe ich aus meiner Konfiguration wieder entfernt, nachdem die Versuche damit nicht gefruchtet haben.
Hast du die MTU der Client-Netzwerkkarten oder der Netzwerkkarte, an der die Clients "hängen", verändert?
Nein, die Veränderung von eth0-Parametern zeitigte in meinen Versuchen keinerlei Ergebnisse. Wenn der Rechner allerdings als Router fungiert, muß auch der Client (also der zweiter Rechner hier im Netz) die MTU (diesmal von eth0, logischerweise) auf 1490 setzen.
Funktionieren die problematischen Sites _auf_dem_Router_ auch ohne das Heruntersetzen der MTU?
Eben nicht.
Ich habe hier eine 7.3 inclusive der Patches/Updates aufgebaut, mit deren Routing/Masquerading es keine Probleme gibt. (Zumindest nicht in dem kurzen Test, den ich hier durchgeführt habe, inklusive der beiden URLs (paulskaffebar und xmasshop), die hier als problematisch gepostet wurden.) Der einzige Unterschied zu einer Original-7.3 liegt in einem selbsterstellten Kernel (2.4.10).
Hier ist der original SuSE 2.4.10 im Einsatz. Fahr doch spaßeshalber einfach mal _diesen_ hoch.
Ich habe langsam den Verdacht, dass das Problem in der Konfiguration oder den Patches des SuSE-Kernels zu finden ist?
Dann stellt sich die Frage: wo? Ich bastele derzeit an der Konfig für 2.4.13, den ich dann irgendwann kommende Woche hochfahre. Diesbezügliche Erfahrungen kann ich ja dann ggf. posten. Grüße, Matthias -- LPI Level 1 Certified http://www.selflinux.de
* Sonntag, 28. Oktober 2001 um 02:38 (+0200) schrieb Matthias Kleine:
Am Samstag, 27. Oktober 2001 23:47 schrieb Andreas Koenecke:
MSS-Clamping habe ich aus meiner Konfiguration wieder entfernt, nachdem die Versuche damit nicht gefruchtet haben.
Hast du die MTU der Client-Netzwerkkarten oder der Netzwerkkarte, an der die Clients "hängen", verändert?
Nein, die Veränderung von eth0-Parametern zeitigte in meinen Versuchen keinerlei Ergebnisse.
Wenn der Rechner allerdings als Router fungiert, muß auch der Client (also der zweiter Rechner hier im Netz) die MTU (diesmal von eth0, logischerweise) auf 1490 setzen.
Diesen Vorgang könntest du dir IMHO durch das MSS-Clamping ersparen.
Ich habe hier eine 7.3 inclusive der Patches/Updates aufgebaut, mit deren Routing/Masquerading es keine Probleme gibt. [ ... ] Der einzige Unterschied zu einer Original-7.3 liegt in einem selbsterstellten Kernel (2.4.10).
Hier ist der original SuSE 2.4.10 im Einsatz. Fahr doch spaßeshalber einfach mal _diesen_ hoch.
Gute Idee! Da ich jedoch auch die lilo.conf verändert habe, habe ich einmal den "Failsafe-Eintrag" ohne die append-Zeile gebootet und hoffe, dass dieses Vorgehen dem Original-SuSE-Kernel entspricht. Fazit: Keine Probleme mit dem Internetzugang.
Ich habe langsam den Verdacht, dass das Problem in der Konfiguration oder den Patches des SuSE-Kernels zu finden ist?
Das nehme ich zurück: Es liegt offensichtlich nicht am SuSE-Kernel.
Nächste Hypothese: Ein fehlkonfigurierter Router auf der Strecke.
Falls du Zeit und Lust hast, und falls du an der Ursache des Problems
interessiert bist, könntest du noch folgendes untersuchen:
Setze die MTU/MRU _nicht_ auf 1490 herunter und "fahre" eine kleine
Testreihe mit
'traceroute -F -I www.paulskafebar.de
Am Sonntag, 28. Oktober 2001 13:29 schrieb Andreas Koenecke:
Setze die MTU/MRU _nicht_ auf 1490 herunter und "fahre" eine kleine Testreihe mit 'traceroute -F -I www.paulskafebar.de
', wobei du die von 1489 schrittweise um 1 erhöhst und dabei darauf achtest, bei welcher Paketgröße (wahrscheinlich 1491) und (wichtiger) bei welchem Hop du eine "traceroute: sendto: Message too long"-Meldung bekommst.
Sorry, aber die Optionen -F und -I sind meinem traceroute unbekannt. Ich erinnere mich allerdings, daß ich schon ganz zu Anfang meines Problems traceroute (ohne Parameter) auf die problematischen Rechner angewandt habe und die Route einwandfrei gefunden wurde. Wenn Du mir die gemeinten Optionen nochmal mitteilst, probier ich sie gerne aus. - Matthias -- LPI Level 1 Certified http://www.selflinux.de
Hallo Matthias. * Sonntag, 28. Oktober 2001 um 17:34 (+0200) schrieb Matthias Kleine:
Sorry, aber die Optionen -F und -I sind meinem traceroute unbekannt.
Hm, hat SuSE eine alte Version in die 7.3 gepackt?
Wenn Du mir die gemeinten Optionen nochmal mitteilst, probier ich sie gerne aus.
'-F' setzt das DF-Bit der Pakete (ist für den Test zwingend notwendig)
und
'-I' benutzt ICMP-Pakete statt UDP-Pakete (ist eventuell nicht
notwendig).
Gruß
Andreas
--
Andreas Könecke "Andreas Koenecke
Am Sonntag, 28. Oktober 2001 21:44 schrieb Andreas Koenecke:
Sorry, aber die Optionen -F und -I sind meinem traceroute unbekannt.
Hm, hat SuSE eine alte Version in die 7.3 gepackt?
# rpm -q traceroute traceroute-nanog_6.1.1-80 ?? - Matthias -- LPI Level 1 Certified http://www.selflinux.de
* Sonntag, 28. Oktober 2001 um 23:07 (+0200) schrieb Matthias Kleine:
Am Sonntag, 28. Oktober 2001 21:44 schrieb Andreas Koenecke:
Hm, hat SuSE eine alte Version in die 7.3 gepackt?
# rpm -q traceroute traceroute-nanog_6.1.1-80
Achso...
Na gut, diese traceroute-Variante kann so etwas Ähnliches wie die
gepostete kleine Versuchsreihe mit dem Parameter '-M' "automatisch.
Ansonsten gibt es das "andere" traceroute bei der 7.3 als
'traceroute-lbl' im gleichnamigen Paket.
Gruß
Andreas
--
Andreas Könecke "Andreas Koenecke
Hallo Liste, Ich habe nun endlich auch das DSL laufen so das ich alle Seiten im Netz aufrufen kann !!! Ich kann dazu nur abschließend sagen das die probleme die ich hatte an smpppd liegen der nicht funktioniert. habe jetzt wie schon einige hier das mit pppd laufen !!! ( pppoe ) Als erstes smpppd deaktivieren und rp_pppoe installieren ( Serie n ) !!!!!!!!! hier nun mal meine beispiel konfiguration dann müßte es bei jedem laufen! /etc/ppp/options einstellen # start of /etc/ppp/options #dial on demand demand connect /bin/true ipcp-accept-remote ipcp-accept-local #dial on demand idle 120 # nach 120 Sekunden ohne Datenverkehr wird aufgelegt noipdefault defaultroute user "[ANSCHLUSSKENNUNG][TONLINE-NR]#0001@t-online.de" hide-password noaccomp nopcomp nocrtscts lcp-echo-interval 10 lcp-echo-failure 3 lock nodetach # end of /etc/ppp/options /etc/ppp/pap-secrets einstellen # start of /etc/ppp/pap-secrets "[ANSCHLUSSKENNUNG][TONLINENR]#0001@t-online.de" * "password" # end of /etc/ppp/pap-secrets Die Klammern sind wegzulassen.Beispiel: 000634338173450005688779#0001@t-online.de /etc/init.d/boot.local einstellen. # start of /etc/init.d/boot.local /usr/sbin/pppd pty "pppoe -I eth0 -m 1452" > /dev/null & # end of /etc/init.d/boot.local /etc/init.d/halt.local einstellen. # start of /etc/init.d/halt.local kill -15 `cat /var/run/ppp0.pid` # end of /etc/init.d/halt.local dann noch denn Firwall konfigurieren und das wars !! ( Masquerading) cu swen
participants (9)
-
Andreas Koenecke
-
Aron Fischer
-
Dieter Kluenter
-
Eric Scheen
-
Marc Schiffbauer
-
Matthias Kleine
-
Matthias Kleine
-
Michael Raab
-
Swen