T-DSL , Nameserver & Defaultgatway
Ich hab immer noch das Problem, dass ich nicht
alle Seiten aufrufen kann - außer einer WIN98-Kiste -
die kann alles aufrufen.
http://www.paulskafebar.de
http://members.tripod.com/torontoxmasshop/
gehen z.B. nur von einer Windows-Kiste!!
Auf allen WIN98-Kisten ist DFÜSpeed installiert und
die MTU auf 1492 gesetzt.
Auf dem SuSE 7.3-Router benutze ich folgende Einstellungen:
**************************
route -N:
**************************
Ziel Router Genmask Flags Metric Ref Use Iface
217.5.98.32 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
192.168.22.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
0.0.0.0 217.5.98.32 0.0.0.0 UG 0 0 0 ppp0
**************************
/etc/resolve.conf
**************************
### BEGIN INFO
#
# Modified_by: pppd
# Backup: /etc/resolv.conf.saved.by.pppd.ppp0
# Process: pppd
# Process_id: 820
# Script: /etc/ppp/ip-up
# Saveto:
# Info:
# This is a temporary resolv.conf created by pppd. The
# previous file has been saved as
From: "Jochen Kächelin"
Ich hab immer noch das Problem, dass ich nicht alle Seiten aufrufen kann - außer einer WIN98-Kiste - die kann alles aufrufen.
http://www.paulskafebar.de http://members.tripod.com/torontoxmasshop/
gehen z.B. nur von einer Windows-Kiste!! Auf allen WIN98-Kisten ist DFÜSpeed installiert und die MTU auf 1492 gesetzt. Auf dem SuSE 7.3-Router benutze ich folgende Einstellungen:
Hallo Jochen, ich hatte das Problem auch und habe folgendes gemacht: -auf meiner Linuxschleuder: ifconfig eth0 mtu 1412 - auf meiner Windowskiste mit einem Tweaktool: ebenfalls eine MTU von 1412 Alles blind, nach einen Tip von der Liste. Seitdem geht es. ACHTUNG: Ich kann mich nicht mehr erinnern, aber es musste glaubich unter Win die MTU-Einstellung der _Netzwerkkarte_ sein - nicht etwa die des DFÜ-Netzwerkes, das brauchst du ja nicht mehr. Deswegen würde ich (ohne es zu kennen) erstmal dieses DFÜ-Speed kicken, das funkt dir ja doch nur rein, und der Name DFÜ suggeriert sowieso Unbrauchbarkeit. Das DFÜ-Netzwerk kannst du ja jetzt deinstallieren, du connectest ja über LAN. Gruß, Ratti
* On Wed, Oct 24, 2001 at 09:55:42PM +0200, Ratti wrote:
From: "Jochen Kächelin"
Ich hab immer noch das Problem, dass ich nicht alle Seiten aufrufen kann - außer einer WIN98-Kiste - die kann alles aufrufen.
http://www.paulskafebar.de http://members.tripod.com/torontoxmasshop/
gehen z.B. nur von einer Windows-Kiste!! Auf allen WIN98-Kisten ist DFÜSpeed installiert und die MTU auf 1492 gesetzt. Auf dem SuSE 7.3-Router benutze ich folgende Einstellungen:
ich hatte das Problem auch und habe folgendes gemacht:
-auf meiner Linuxschleuder: ifconfig eth0 mtu 1412
Aha, und dann? Schonma mails gefetcht?? Nicht? Geht auch schlecht, denn die paketgroese kann 1412 schnell uebersteigen. Vergiss den Tipp, schlechter Tip.
- auf meiner Windowskiste mit einem Tweaktool: ebenfalls eine MTU von 1412
Alles blind, nach einen Tip von der Liste. Seitdem geht es.
Auch mails fetchen??? Also, ich hab seit 1 jahr das scheiss Prob das ich mit ADSL gerad ma auf modem-speed komm. Downloads sind Klasse im speed. Die Geruechte mit der mtu sind doch "gammelig"! Das ppp-dev hat/soll eine MTU von 1492 haben, der Rest (mein locales LAN, eth0 und 1) haben alle eine MTU von 1500. Ich hab alles schon probiert, ohne Erfolg. Was ich aber mal versuchte gestern war MTU=1412. Da wars aus mit fetchen von mail. Ich bin mir nicht sicher wie gross die pakete sind incl. header, aber bei mit tats nichts mit MTU 1412 auf eth0. Das ppp0 fass ich nicht an (eth1 auch nicht) weil das vom rp-pppoe gesetzt wird. Da ist auf dem ppp-dev nakla 1492, da die Paketgroesse bei DSL bekanntermassen anders ist. Gruß Clemens -- sig_29 Mit statserial/setserial serielle Infos abfragen: $ statserial /dev/ttyS0 (Ausgabe u.a. Signal und Pin) $ setserial /dev/ttyS0 (Ausgabe u.a. Port und IRQ) [Info: man setserial; man statserial] -------------------------------------------------------
From: "Clemens Wohld"
ich hatte das Problem auch und habe folgendes gemacht:
-auf meiner Linuxschleuder: ifconfig eth0 mtu 1412
Aha, und dann? Schonma mails gefetcht?? Nicht? Geht auch schlecht, denn die paketgroese kann 1412 schnell uebersteigen.
Moin, Der Rechner arbeitet unter anderem als Mailserver. Null Probleme. Er fetcht Mail, wird gefetcht, holt auch News, ist Router für sämtliche Webzugriffe, Downloadsklave, was du willst. Ein eiziges Mal ein Problem gehabt: DSL-Modem war abgestürzt. Modem aus-an, rcpppoed restart, alles wieder fein. Erklär mal bitte, was das Protokoll mit der MTU-Größe zu tun hat? MTU regelt doch die Größe der IP-Pakete, wenn ich das richtig verstehe. Verwirft ein Router "zu große" Pakete, wegen der zusätzlichen Protokoll-Daten über 1500 Bytes, gehen die Daten nicht durch (zum Besipiel www.gmx.de) Also kann die MTU (in normalen Grenzen) nur zu groß, aber nicht zu klein sein. Macht man sie winzig, gibt es mehr Pakete, also mehr Verwaltungskram, also weniger Speed. Wenn ich den Dreisatz noch kann, dürfte eine Änderung von 1500 auf 1412 nicht wirklich Performance ziehen. Und wenn das dann gut läuft, werd' ich eine Teufel tun und gucken, ob auch 1413 oder 1414 oder... gehen. Bringt nix.
Vergiss den Tipp, schlechter Tip.
..außer natürlich, daß er funktioniert hat...
Auch mails fetchen???
Jepp.
Also, ich hab seit 1 jahr das scheiss Prob das ich mit ADSL gerad ma auf modem-speed komm. Downloads sind Klasse im speed.
Ich bekomme im Download bis zu 93 Kb/s angezeigt. Das kann zwar nicht sein, da rechnet ein Tool wohl "hübsch", sollte aber wohl als Beleg reichen, daß die Kiste Vollgas gibt. Verstehe ich das richtig: Deine Kiste fährt DSL mit Modem-Speed, und meine fährt DSL mit DSL-Speed, und du erzählst, meine Tips taugen nix? :-)) Gruß, Ratti
* On Sun, Oct 28, 2001 at 06:49:27PM +0100, Ratti wrote:
From: "Clemens Wohld"
ich hatte das Problem auch und habe folgendes gemacht:
-auf meiner Linuxschleuder: ifconfig eth0 mtu 1412
Aha, und dann? Schonma mails gefetcht?? Nicht? Geht auch schlecht, denn die paketgroese kann 1412 schnell uebersteigen.
Der Rechner arbeitet unter anderem als Mailserver. Null Probleme.
Wunderte mich.
Er fetcht Mail, wird gefetcht, holt auch News, ist Router für sämtliche Webzugriffe, Downloadsklave, was du willst. Ein eiziges Mal ein Problem gehabt: DSL-Modem war abgestürzt. Modem aus-an, rcpppoed restart, alles wieder fein.
Erklär mal bitte, was das Protokoll mit der MTU-Größe zu tun hat?
Nichts! Das hab _ich_ sicherlich auch nicht behauotet MTU=Paketgroessen(begrenzung)
MTU regelt doch die Größe der IP-Pakete, wenn ich das richtig verstehe.
Jo
Verwirft ein Router "zu große" Pakete, wegen der zusätzlichen Protokoll-Daten über 1500 Bytes, gehen die Daten nicht durch (zum Besipiel www.gmx.de)
ACK, und das _Problem_ erwaehnte ich. Mit ner MTU=1412 wird 's bei GMX also schwer.
Also kann die MTU (in normalen Grenzen) nur zu groß, aber nicht zu klein sein.
Ja, natuerlich, nur zu gross.
Macht man sie winzig, gibt es mehr Pakete, also mehr Verwaltungskram, also weniger Speed. Wenn ich den Dreisatz noch kann, dürfte eine Änderung von 1500 auf 1412 nicht wirklich Performance ziehen. Und wenn das dann gut läuft, werd' ich eine Teufel tun und gucken, ob auch 1413 oder 1414 oder... gehen. Bringt nix.
Und wie regelst du die ankommenden IP-Pakete? Zerlegts du die...
Vergiss den Tipp, schlechter Tip.
..außer natürlich, daß er funktioniert hat...
OK, denn guter Tip. Hab ich kein Problem mit. Bei mir hats das nicht.
Auch mails fetchen??? Jepp.
Bei GMX? ;))
Also, ich hab seit 1 jahr das scheiss Prob das ich mit ADSL gerad ma auf modem-speed komm. Downloads sind Klasse im speed.
Ich bekomme im Download bis zu 93 Kb/s angezeigt. Das kann zwar nicht sein, da rechnet ein Tool wohl "hübsch", sollte aber wohl als Beleg reichen, daß die Kiste Vollgas gibt.
Gibt meine auch, bis 98Kb/s blaa..., nur nicht mit browser surfen. Was das ist? Sags...
Verstehe ich das richtig: Deine Kiste fährt DSL mit Modem-Speed, und meine fährt DSL mit DSL-Speed, und du erzählst, meine Tips taugen nix? :-))
Nein, verstehst du nicht richtig. Macht aber nichts ;) Gruß Clemens -- sig_46 RPM in Aktion Vol.2: INFOS vor Install! [Info man rpm] $ rpm -qpi <paketname> ==> query package info $ rpm -qpl <paketname> ==> listet files die inst. werden auf $ rpm --help | less ==> zeigt alle rpm-Optionen auf --------------------------------------------------------------
Am Sonntag, 28. Oktober 2001 21:16 schrieben Sie:
ACK, und das _Problem_ erwaehnte ich. Mit ner MTU=1412 wird 's bei GMX also schwer.
Ist hier kein Problem. Mit 1492 hingegen klappts nicht. Größtmöglicher Wert (übrigens auf ppp0! Spielen mit der mtu von eth0 brachte rein garnichts) ist 1490. Ab 1492 geht hier weder Mail holen (POP3) bei GMX noch das Aufrufen kritischer Webseiten (gmx.de, tchibo.de usw.). - Matthias -- LPI Level 1 Certified http://www.selflinux.de
From: "Clemens Wohld"
Verwirft ein Router "zu große" Pakete, wegen der zusätzlichen Protokoll-Daten über 1500 Bytes, gehen die Daten nicht durch (zum Besipiel www.gmx.de)
ACK, und das _Problem_ erwaehnte ich. Mit ner MTU=1412 wird 's bei GMX also schwer.
Theoretisch? Kann sein, da habe ich kein ausreichendes Know-How. Praktisch scheint TCP/IP das auch nicht zu wissen und funktioniert fälschlicherweise. :-) Ich hatte das MTU-Problem ja auch. Ich habe zwar keinen Account bei GMX, aber meine Freundin, die auch in meinem Netz hängt. Die holt allerdings ihre Mails "direkt" beim Server ab, will sagen: In ihrem Outlook Express ist GMX als smtp/pop eingetragen. Als das nach meiner letzten Linux-Serverinstallation plötzlich nicht mehr ging, wollte ich auf die Website gucken ("Hallo, wir sind wie üblich offline..." oder so), und auch das ging nicht. Nach den MTU-Verbiegungen auf dem Linux-Server und auf unseren Windows-Kisten (Einmal 2000, einmal XP) kriegen wir die Website über den Browser, und sie kriegt ihre Post. Ein Szenario ist darin nicht enthalten: Der Versuch, vom Server aus auf GMX zuzugreifen, aber da er korrekt maskiert wird das ja wohl direkt erst recht gehen. Ich ringe mich also zu der Behauptung durch: Geht, auch Mail. Wenn es dir helfen würde, könnte ich mich dazu durchringen, einen GMX-Account zu beantragen und in meine fetchmailrc einzutragen. Ich kriege sowieso zu wenig Spam. ;-)
Und wie regelst du die ankommenden IP-Pakete? Zerlegts du die...
Schätz ich mal. Ist das nicht das übliche Router-Verhalten, außer ein paar Spezis, wie z.B. der vor GMX? Ich kenn mich da nicht so aus. Ich habe rumprobiert, es geht, und angelegentlich sollte ich das glaub ich mal backuppen, wenn ich sehe, wie oft hier wegen MTU-Ärger angefragt wird... :-) Gruß, Ratti
* On Sun, Oct 28, 2001 at 10:36:59PM +0100, Ratti wrote:
From: "Clemens Wohld"
Verwirft ein Router "zu große" Pakete, wegen der zusätzlichen Protokoll-Daten über 1500 Bytes, gehen die Daten nicht durch (zum Besipiel www.gmx.de)
ACK, und das _Problem_ erwaehnte ich. Mit ner MTU=1412 wird 's bei GMX also schwer.
Theoretisch? Kann sein, da habe ich kein ausreichendes Know-How. Praktisch scheint TCP/IP das auch nicht zu wissen und funktioniert fälschlicherweise. :-)
Glaubs mir, ich hab nur mal so getestet, es ging mit $ ifconfig eth1 MTU 1412 && ifconfig eth0 MTU 1412 definitiv nicht. Und das war der Grund warum ich bei dem Tipp eingegriffen hab und meine Erfahrungen geschildert hab.
Ich hatte das MTU-Problem ja auch.
Ich hab kein Problem. Das was ich hier hab hat nichts mit der MTU zutun und wird auch so schnell keiner fixen.
Ich habe zwar keinen Account bei GMX,
Ich aber ;) Mach, seit 2 jahren, alles ueber GMX, weil .. die sind gut und t-online account will ich nicht tragen muessen.
Ich ringe mich also zu der Behauptung durch: Geht, auch Mail.
Kenn weder Outlook noch Windows (nein stimmt nicht, Windows kenmn ich ;)
Wenn es dir helfen würde, könnte ich mich dazu durchringen, einen GMX-Account zu beantragen und in meine fetchmailrc einzutragen. Ich kriege sowieso zu wenig Spam. ;-)
Aehh, wir rden glaub ich aneinander vorbei. ICH HAB KEIN PROBLEM! Das war nur eine versuchte Hilfestellung an der ich mich beteiligt hab. Ich hab nur aus Bock deinen Tipp mit der MTU getestet und festgestellt (reproduzierbar) das es anschl. _keine_ mails mehr gefetcht werden koennen. Probier es doch aus ;)
Und wie regelst du die ankommenden IP-Pakete? Zerlegts du die...
Schätz ich mal.
Aha...
Ist das nicht das übliche Router-Verhalten, außer ein paar Spezis, wie z.B. der vor GMX?
Dafuer lehnst du dich aber weit aus dem Fenster ;)
Ich kenn mich da nicht so aus. Ich habe rumprobiert, es geht, und angelegentlich sollte ich das glaub ich mal backuppen, wenn ich sehe, wie oft hier wegen MTU-Ärger angefragt wird... :-)
Die Aussage ist ganz klar, auch wenn im Internet verschiedene Tiups/fixes koursieren. Das external_IF ppp0, was die Verbindung aufbaut beim DSL, bekommt vom script (zumindest Debian/rp-pppoe) die richtigen Optionen gesetzt. Sprich ppp0 mtu=1492. ALLE _anderen_ Interfaces sollten eine mtu von 1500 tragen. Das alles. Aber wioe gesagt, das dev ppp0 wird eh vom start-scrip adsl-start aufgesetzt. Gruß Clemens -- sig_45 RPM in Aktion Vol.1: [Info: man rpm] $ rpm -qa | less ===> listet alle inst. Pakete auf. $ rpm -qi <paketname> ===> listet Infos zum Paket auf. $ rpm -qa | grep ftp ===> suche nach Paket ftp.rpm ---------------------------------------------------------
From: "Clemens Wohld"
Ich hab nur aus Bock deinen Tipp mit der MTU getestet und festgestellt (reproduzierbar) das es anschl. _keine_ mails mehr gefetcht werden koennen. Probier es doch aus ;)
Wahrscheinlich können wir's totdiskutieren. :-) Ich will gar nicht behaupten, ich hätte irgendwie tolles Fachwissen. Was ich hier habe, funktioniert 100%ig. Das ist alles, was ich sagen kann. Bevor ich's so konfiguriert habe, funktionierte es nicht. Ich liste es hier einfach nochmal für's Archiv auf, vielleicht kann es ja jemandem von Nutzen sein: Auf dem Server fetchmail, Masquerading, ftpServer/Client, Routing, NNTP, ssh-Server, Webserver, smtp- und POP3server, Samba, Nameserver, und mehr fällt mir gerade nicht ein. :-) Auf den Clients: ftp, Bearshare, Browser, ssh-Client, Newsreader, ... das übliche. Ich kann mit dem Browser auf gmx.de zugreifen, ein anderer Client im Netz kann Post direkt von GMX abholen. GMX ist aber nicht Bestandteil der fetchmail-Config. Meine Config: Linux-Server: ppp0 hat 1490 (War ich glaubich nicht, wohl auch per Script...) eth1 (Server an internem Netzwerk) hat 1500. eth0 (Server zu DSL-Modem) hat 1412. Windows Clients (2000 und XP): MTU für DFÜ-Netzwerk nicht angefasst (Sollte 1500 sein) MTU für Netzwerkkarte ist 1412. Gruß, Ratti
* Montag, 29. Oktober 2001 um 21:25 (+0100) schrieb Ratti:
Meine Config:
Linux-Server: ppp0 hat 1490 (War ich glaubich nicht, wohl auch per Script...)
Bist du sicher das ppp0 auch bei _bestehender_ Verbindung eine MTU von
1490 Bytes hat?
Gruß
Andreas
--
Andreas Könecke "Andreas Koenecke
From: "Andreas Koenecke"
Bist du sicher das ppp0 auch bei _bestehender_ Verbindung eine MTU von 1490 Bytes hat?
Hallo, Ihr macht mich irgendwie nervös. Ist irgendwas an meiner Config? ;-)))) Fast hätte ich gesagt: Ich kann ja auch nix dafür, daß es läuft. ;-))) Also: ich habe gerade erfolgreich meine Domain angepingt, bin also online, und ifconfig ppp0 ergibt: ppp0 Link encap:Point-to-Point Protocol inet addr:217.227.29.226 P-t-P:217.5.98.19 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1490 Metric:1 RX packets:2493163 errors:0 dropped:0 overruns:0 frame:0 TX packets:2322639 errors:0 dropped:424 overruns:0 carrier:0 collisions:0 txqueuelen:3 RX bytes:1416478883 (1350.8 Mb) TX bytes:498112880 (475.0 Mb) Ich schicke ihn offline: gesindel:~ # rcpppoed stop Shutting down pppoed: done gesindel:~ # ifconfig ppp0 ppp0: error fetching interface information: Device not found gesindel:~ # rcpppoed start Starting pppoed: done gesindel:~ # ifconfig ppp0 ppp0 Link encap:Point-to-Point Protocol inet addr:192.168.99.1 P-t-P:192.168.99.99 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:3 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) Ich schick ihn wieder online: gesindel:~ # ping www.gesindel.de PING www.gesindel.de (217.27.128.110): 56 data bytes 64 bytes from 217.27.128.110: icmp_seq=10 ttl=248 time=82.635 ms gesindel:~ # ifconfig ppp0 ppp0 Link encap:Point-to-Point Protocol inet addr:217.81.80.111 P-t-P:217.5.98.19 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1490 Metric:1 RX packets:60 errors:0 dropped:0 overruns:0 frame:0 TX packets:69 errors:0 dropped:6 overruns:0 carrier:0 collisions:0 txqueuelen:3 RX bytes:16205 (15.8 Kb) TX bytes:4127 (4.0 Kb) Gruß, Ratti
* Mittwoch, 31. Oktober 2001 um 20:41 (+0100) schrieb Ratti:
Ihr macht mich irgendwie nervös. Ist irgendwas an meiner Config? ;-))))
Lass dich bloss nicht auch noch nervös machen... ;-)
Fast hätte ich gesagt: Ich kann ja auch nix dafür, daß es läuft. ;-)))
Ja, das sagt jeder. Aber das lässt sich ändern... ;-) Spaß beiseite:
ich habe gerade erfolgreich meine Domain angepingt, bin also online, und
ifconfig ppp0
ergibt:
ppp0 Link encap:Point-to-Point Protocol inet addr:217.227.29.226 P-t-P:217.5.98.19 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1490 Metric:1
Das ist interessant und IMHO neu.
Kannst du mal in '/etc/ppp/options' "debug" einfügen und die Zeilen
des Verbindungsaufbaus (zwischen "Sending PADI" und "Script
/etc/ppp/ip-up started") posten. (Benutzerkennung vorher unkenntlich
machen.)
Danke.
Gruß
Andreas
--
Andreas Könecke "Andreas Koenecke
* Mittwoch, 31. Oktober 2001 um 21:29 (+0100) schrieb Andreas Koenecke:
* Mittwoch, 31. Oktober 2001 um 20:41 (+0100) schrieb Ratti:
ifconfig ppp0
ergibt:
ppp0 Link encap:Point-to-Point Protocol inet addr:217.227.29.226 P-t-P:217.5.98.19 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1490 Metric:1
Das ist interessant und IMHO neu.
Ratti hat mir inzwischen den Log-Auszug zugeschickt und ich möchte die
Ergebnisse der Liste nicht vorenthalten.
Hier die relevanten Teile des Logs:
Oct 31 22:49:24 gesindel pppd[27104]: sent [LCP ConfReq id=0x1
Andreas Koenecke wrote:
Das Verhalten des pppd kann ich allerdings auch nicht ganz nachvollziehen, eventuell fehlt ihm aber auf seinen ersten MRU-Vorschlag ein "ConfNack" des ACs. (Aber warum nimmt er dann im ersten Durchlauf die 1492 an?)
Sieht am plausibelsten aus: Er hat ja gewissermaßen auf seinen Vorschlag noch keine Antwort erhalten, einen Gegenvorschlag versteht er nicht als Antwort, also versucht er es von neuem. Das wäre freilich eindeutig eine kleine Race-Condition, die immer dann auftritt, wenn beide fast gleichzeitig vorschlagen und der pppd schneller bestätigt als die Gegenstelle.
Matthias (Kleine), falls du noch mitliest: Kannst du mir auch einen Debug-Output des pppd zum Vergleich zukommen lassen?
Muß ich dann heute abend tun, bis dahin ... - Matthias
Am Donnerstag, 1. November 2001 22:39 schrieb Andreas Koenecke: Hallo Andreas,
Matthias (Kleine), falls du noch mitliest: Kannst du mir auch einen Debug-Output des pppd zum Vergleich zukommen lassen?
Nov 2 21:18:12 delphin pppd[32396]: Plugin pppoe.so loaded.
Nov 2 21:18:12 delphin pppd[32396]: PPPoE Plugin Initialized
Nov 2 21:18:12 delphin pppd[32396]: Plugin passwordfd.so loaded.
Nov 2 21:18:12 delphin pppd[32396]: pppd 2.4.1 started by root, uid 0
Nov 2 21:18:12 delphin pppd[32396]: Sending PADI
Nov 2 21:18:12 delphin pppd[32396]: HOST_UNIQ successful match
Nov 2 21:18:12 delphin pppd[32396]: HOST_UNIQ successful match
Nov 2 21:18:12 delphin pppd[32396]: Got connection: 1684
Nov 2 21:18:12 delphin pppd[32396]: Connecting PPPoE socket: 00:90:1a:10:22:29 8416 eth0 0x8086678
Nov 2 21:18:12 delphin pppd[32396]: using channel 25
Nov 2 21:18:12 delphin pppd[32396]: Using interface ppp0
Nov 2 21:18:12 delphin pppd[32396]: Connect: ppp0 <--> eth0
Nov 2 21:18:12 delphin pppd[32396]: Couldn't increase MTU to 1500.
Nov 2 21:18:12 delphin pppd[32396]: Couldn't increase MRU to 1500
Nov 2 21:18:12 delphin pppd[32396]: sent [LCP ConfReq id=0x1
Hallo Matthias, * Freitag, 02. November 2001 um 21:20 (+0100) schrieb Matthias Kleine:
Nov 2 21:18:12 delphin pppd[32396]: sent [LCP ConfReq id=0x1
] Nov 2 21:18:13 delphin pppd[32396]: rcvd [LCP ConfReq id=0xd7 <auth pap> ] Nov 2 21:18:13 delphin pppd[32396]: sent [LCP ConfAck id=0xd7 <auth pap> ] Nov 2 21:18:14 delphin pppd[32396]: sent [LCP ConfReq id=0x1 ] Nov 2 21:18:14 delphin pppd[32396]: rcvd [LCP ConfAck id=0x1 ]
Jetzt wird es wirklich lustig...
Das ist prinzipiell das gleiche LCP-Handshake wie bei Ratti, nur das
dein pppd offensichtlich die MRU der ersten Verhandlung übernimmt.
Jetzt könnte ich mir auch eine Ursache für dein Problem vostellen:
Dein pppd übernimmt die MRU der ersten Verhandlung (1492) und der AC
übernimmt die MRU der zweiten Verhandlung (1490) (wie auch bei
Ratti). Und das passt dann halt nicht...
Matthias, bitte versuche doch (nochmal) folgendes:
Schmeiss alle MTU-Manipulationen aus 'ip-up*' heraus und setze die
'mtu'- und 'mru'-Optionen in '/etc/ppp/peers/pppoe' und
'/etc/ppp/options' auf 1492, starte den pppd (smpppd) neu und stelle
dann eine Verbindung her... Ich glaube fest daran, dass dann alles
funktioniert.
Gruß
Andreas
--
Andreas Könecke "Andreas Koenecke
Am Freitag, 2. November 2001 22:00 schrieb Andreas Koenecke:
Jetzt könnte ich mir auch eine Ursache für dein Problem vostellen: Dein pppd übernimmt die MRU der ersten Verhandlung (1492) und der AC übernimmt die MRU der zweiten Verhandlung (1490) (wie auch bei Ratti). Und das passt dann halt nicht...
Matthias, bitte versuche doch (nochmal) folgendes: Schmeiss alle MTU-Manipulationen aus 'ip-up*' heraus und setze die 'mtu'- und 'mru'-Optionen in '/etc/ppp/peers/pppoe' und '/etc/ppp/options' auf 1492, starte den pppd (smpppd) neu und stelle dann eine Verbindung her... Ich glaube fest daran, dass dann alles funktioniert.
Bingo! So läuft das ganze nach Einwahl und mit einer mtu=1492 problemlos. Vielen Dank, Andreas, für die ausdauernde Fehlersuche. Ausschlaggebend muß übrigens der Eintrag in /etc/ppp/peers/pppoe sein, da ich zuerst nur diesen Wert auf 1492 hochgesetzt habe, während die Werte in /etc/ppp/options nach wie vor auf 1486 standen und es auch so funktionierte. Ich habe jetzt alle Werte auf 1492 stehen, und es geht. Ursache ist somit die falsche Konfiguration in /etc/ppp/peers/pppoe. Der Eintrag in der SDB schlägt am Ende eine Modifikation dieser Werte vor, sagt aber nicht, auf welchen Wert genau der Wert zu modifizieren ist. Nach der Logik der Dinge dürfte hier (zumindest für mich) 1492 der einzig richtige Wert sein. Eigentliche Ursache sollte jedoch ein Kommunikationsfehler (vermutlich in smpppd?!) sein, der es zuläßt, daß die beiden Partner unterschiedliche Werte akzeptieren. Ist ggf. einen Bugreport wert, was meinst Du?! - Matthias -- LPI Level 1 Certified http://www.selflinux.de
Hallo Matthias. * Freitag, 02. November 2001 um 22:52 (+0100) schrieb Matthias Kleine:
Bingo! So läuft das ganze nach Einwahl und mit einer mtu=1492 problemlos.
Prima!
Ursache ist somit die falsche Konfiguration in /etc/ppp/peers/pppoe. Der Eintrag in der SDB schlägt am Ende eine Modifikation dieser Werte vor, sagt aber nicht, auf welchen Wert genau der Wert zu modifizieren ist. Nach der Logik der Dinge dürfte hier (zumindest für mich) 1492 der einzig richtige Wert sein.
Ja unbedingt, und nicht nur für dich, sondern für alle und ganz
besonders für die, die an einem Siemens-AC hängen. Für die Anderen,
die an einem Cisco-AC hängen, spielt die Einstellung keine Rolle, da
dort die PPP-Verhandlungen ordentlich durchgeführt werden und somit
_immer_ die richtige MTU/MRU von 1492 ausgehandelt wird. Zur
Vervollständigung dazu mal den Log-Auszug einer korrekten
MRU-Verhandlung:
Nov 2 23:41:19 KoCom pppd[18102]: sent [LCP ConfReq id=0x1
Eigentliche Ursache sollte jedoch ein Kommunikationsfehler (vermutlich in smpppd?!) sein, der es zuläßt, daß die beiden Partner unterschiedliche Werte akzeptieren.
Den smpppd würde ich ausschliessen, AFAIR startet (und stoppt) er lediglich den pppd, die Verhandlungen sind allein Aufgabe des pppd. Ich sehe die Ursache eher im Siemens-AC, der das "ConfNak" vergisst.
Ist ggf. einen Bugreport wert, was meinst Du?!
Ja, SuSE sollte IMHO die SDB zu dem Problem so überarbeiten, eine
MTU/MRU von 1492 Bytes konkret zu nennen und zukünftige SuSE-Versionen
mit diesen Werten vorkonfigurieren.
Aber wie schreibt man so einen Bugreport?
Vielleicht liest ja Henne Vogelsang zufällig mit und kann das auf dem
"kleinen Dienstweg" veranlassen.
Gruß
Andreas
--
Andreas Könecke "Andreas Koenecke
Ratti wrote: done
gesindel:~ # ifconfig ppp0 ppp0 Link encap:Point-to-Point Protocol inet addr:192.168.99.1 P-t-P:192.168.99.99 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 ~~~~~~~~ Ich schick ihn wieder online:
gesindel:~ # ping www.gesindel.de PING www.gesindel.de (217.27.128.110): 56 data bytes 64 bytes from 217.27.128.110: icmp_seq=10 ttl=248 time=82.635 ms
gesindel:~ # ifconfig ppp0 ppp0 Link encap:Point-to-Point Protocol inet addr:217.81.80.111 P-t-P:217.5.98.19 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1490 Metric:1 ~~~~~~~~
Das ist ja schick! Die mtu stellt sich bei Dir automatisch ein?! Ich muß immernoch Hand anlegen an ppp0, das heißt nach jedem Verbindungsaufbau von neuem ifconfig machen. Möglichkeit zur Automatisierung hab ich noch nicht gefunden, ppp/options half hier nicht weiter. - Matthias
From: "Matthias Kleine"
gesindel:~ # ifconfig ppp0 ppp0 Link encap:Point-to-Point Protocol inet addr:217.81.80.111 P-t-P:217.5.98.19 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1490 Metric:1
Das ist ja schick! Die mtu stellt sich bei Dir automatisch ein?! Ich muß immernoch Hand anlegen an ppp0, das heißt nach jedem Verbindungsaufbau von neuem ifconfig machen. Möglichkeit zur Automatisierung hab ich noch nicht gefunden, ppp/options half hier nicht weiter.
Hi, "automatisch" würde ich nicht beschwören. Wenn man einen Nachmittag an dem Problem schraubt, ist schnell mal was geändert und vergessen. Bevorzugt an Stellen, die kein Profi anfassen würde. :-) Mir ist aber nicht so. Wenn ihr mir sagt, wo, kann ich auch gerne nochmal gucken, ob ich wohlmöglich Scripte geändert habe. Ich habe alles angeguckt, was mir in den Kopf kommt, das sieht alles nach "Okinalteile" aus. (Werner(TM)) Wohlmöglich ist auch von Interesse, daß ein (lt. ML) Bug ein Kernelupdate notwendig macht, wenn man maskieren will, was ich mit ipchains tue. Auch das habe ich gemacht, das Updatefile hiess "k_deflt-2.4.7-16.i386.rpm". Gruß, Ratti
From: "Matthias Kleine"
Wenn ihr mir sagt, wo, kann ich auch gerne nochmal gucken, ob ich wohlmöglich Scripte geändert habe.
Schau doch mal in /etc/ppp/ip-up bzw. in /etc/ppp/ip-up.local, ob dort irgendwo ein ifconfig gemacht wird.
Jepp. ip-up verbietet sich ohnehin, da potetielles Update-Opfer. Ich schaue mal nach... da wird ein ifconfig aufgerufen im "interface=ippp*"-case, m.E. ist der aber doch nicht betroffen(?) ippp ist doch ISDN, oder? Im "ppp*"-case findet sich kein ifconfig mehr. Machen wir doch mal den arme-Leute-diff: Länge meiner ip-up ist 7387 Bytes. ip-up.local macht nur diversen Spielkram: fetchmail, dyndns, Statistik. Wenn ip-up.* läuft, müsste die Verbindung aber an sich schon bestehen. Akzeptiert er dann noch MTU-Änderungen? ...werfe ich jetzt mal so in die Runde... Gruß, Ratti
Matthias Kleine wrote:
gesindel:~ # ifconfig ppp0 ppp0 Link encap:Point-to-Point Protocol inet addr:217.81.80.111 P-t-P:217.5.98.19 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1490 Metric:1
~~~~~~~~
Das ist ja schick! Die mtu stellt sich bei Dir automatisch ein?! Ich muß immernoch Hand anlegen an ppp0, das heißt nach jedem Verbindungsaufbau von neuem ifconfig machen. Möglichkeit zur Automatisierung hab ich noch nicht gefunden, ppp/options half hier nicht weiter.
habe das bei mir (suse7.3) in /etc/ppp/peers/pppoe geändert -- viele Gruesse Rolf Hillen GPG/PGP-key 55BEEFD0
participants (7)
-
Andreas Koenecke -
Clemens Wohld -
Jochen Kächelin -
Matthias Kleine -
Matthias Kleine -
Ratti -
Rolf Hillen