24h Dauerbetrieb unter SuSE 10.0 - DSL Reconnect nach Zwangstrennung funktioniert nicht
HI, vorweg gleich die wichtigtse Nachricht. Ja, ich habe mir 1.000x den Kopf zerbrochen und ich hab' mir auch stundenlang alle möglichen googl-Ergebnisseiten angekuckt. Aber ich habe nichts gefunden, was mir entscheidend weiterhilft. Wo fang' ich an. Ich denke am einfachsten ganz von vorne. Bis vor ein paar Tagen hatte ich eine äußerst zuverlässige SuSE 8.1 am laufen. Aber wie's der Teufel wohl wollte, habe ich mich hinreißen lassen und versucht mein System upzudaten. Hintergrund war mein missglückter Versuch die CAPI für meinen Asterisken zu integrieren. Egal, nachdem 100e von Paketabhängigkeiten manuell beseitigt wurden, ging der Update los, genau etwa bis zum 3ten Paket und dann verabschiedete sich die neue Version mit dem Hinweis, dass ein irgendein Paket nicht installierbar sei. Also was macht man dann? Neu installieren, nachdem ich die vermeintlich wichtigen Konfigurationsdateien gesichert hatte. Die SuSE 10.0 installieren war ja absolut kein Problem. Auch die wichtigsten Hardwarekomponenten wie Dienste ließen sich einfach und schnell installieren. War schon richtig stolz auf mich. Nur was mich stutzig machte war, dass ich so einmal am Tag keinen Namen mit meinem selbergestrickten Nameserver für meine SOHO-Umgebung auflösen konnte. Ich hatte da natürlich gleich mal meinen bind in Verdacht und hatte da tagelang herumgesucht, bis ich dann mal zufälliger Weise versuchte einen host anzupingen, von dem ich mir die IP-Adresse aufgeschrieben hatte. Und siehe da, das ging plötzlich nicht mehr. Ein ifconfig brachte es dann zu Tage: Die DSL-Verbindung wird nach der Zwangstrennung durch den Provider nicht mehr automatisch aufgebaut - ohne dsl-Verbindung kann ich dann natürlich auch keinen Rechner wie www.t-logline.de anpingen. Als braver und naiver Möchtegern-Linux-Spezialist habe ich dann versucht mittels YAST der Kiste beizubringen, dass er nach der Zwangstrennung automatisch wieder die Verbindung aufbauem soll. Doch da ist nix! <grrr>. Die manuellen Versuche dies via "AUTO_RECONNECT='yes'" in der /etc/sysconfig/network/providers/provider0 zu machen tut' irgendwie nicht. Was nun sprach Zeus. Was und wie muss ich denn der Dreggskiste denn nun sagen, damit es funktioniert? Die 8.1er lief seinerzeit ohne Probleme, da ging's doch auch. Und soweit ich via google herausgefunden habe, gab's wohl ähnliche Probleme auch schon bei 9.x Bin für jeden Tip dankbar! Pfiadseich, Michael
Am Sonntag, 9. April 2006 20:14 schrieb Michael Nausch:
Was nun sprach Zeus. Was und wie muss ich denn der Dreggskiste denn nun sagen, damit es funktioniert? Die 8.1er lief seinerzeit ohne Probleme, da ging's doch auch. Und soweit ich via google herausgefunden habe, gab's wohl ähnliche Probleme auch schon bei 9.x
Eine Mögliche Lösung: per Cron und dem Kommando cinternet -i dsl0 -s testen, ob Verbindung steht - und wenn nicht, neu aufbauen. cinternet -i dsl0 -D Dafür muss aber DSL als "dial on demand" konfiguriert sein. Sollte aber nicht das Problem darstellen, wenn du einfach keine "time out" Zeit angibst. Dann legt er nicht automatisch auf. So würde ich es machen. Gruß Timothy -- "Es gibt zwei Dinge im Leben, die du nicht zurücknehmen kannst: Den Pfeil den du verschossen und das Wort, das du gesprochen" - altes indianisches Sprichwort
Am Sonntag, 9. April 2006 22:14 schrieb Michael Nausch:
HI,
Am Sonntag, 9. April 2006 20:06 schrieb Timothy Kesten:
So würde ich es machen.
Na ja, das wäre aber nur ein Kaschieren des problems und die die Beseitigung des eigentlichen Übels,
Man nennt so etwas wohl auch "work around" ;-) Hauptsache es funzt (bis jemand die "richtige" Lösung kennt/nennt) Bye Timothy -- "Es gibt zwei Dinge im Leben, die du nicht zurücknehmen kannst: Den Pfeil den du verschossen und das Wort, das du gesprochen" - altes indianisches Sprichwort
Griasdebou! Am Sonntag, 9. April 2006 21:59 schrieb Timothy Kesten:
Man nennt so etwas wohl auch "work around" ;-) Hauptsache es funzt (bis jemand die "richtige" Lösung kennt/nennt)
Logisch dazu hab' ich ja auch nen workaround ala "rcnetwork restart" - mich würd' aber dennoch schon interessieren, was da nun schief läuft und was da den Herren von Novell eigentlich treibt, derartiges zu fabrizieren. Pfiade, BC
* Montag, 10. April 2006 um 18:42 (+0200) schrieb Michael Nausch:
Logisch dazu hab' ich ja auch nen workaround ala "rcnetwork restart" - mich würd' aber dennoch schon interessieren, was da nun schief läuft
Dann schreibe doch mal "PPPD_OPTIONS='dump debug'" in die "/etc/sysconfig/network/ifcfg-dsl?", beende die laufende Verbindung, starte den 'smpppd' neu, gebe 'cinternet --debug=on' ein, baue die Verbindung wieder auf und poste alle Meldungen aus /var/log/messages des 'smpppd' und des 'pppd' beim Verbindungsaufbau und beim Verbindungsabbau plus ca. 10 min... Gruß Andreas -- XMMS spielt gerade nichts... PGP-ID/Fingerprint: BD7C2E59/3E 11 E5 29 0C A8 2F 49 40 6C 2D 5F 12 9D E1 E3 PGP-Key on request or on public keyservers --
Griasde, Am Montag, 10. April 2006 19:09 schrieb Andreas Koenecke:
... und poste alle Meldungen aus /var/log/messages des 'smpppd' und des 'pppd' beim Verbindungsaufbau und beim Verbindungsabbau plus ca. 10 min...
O.K. Verbindungsaufbau erzwungen durch "rcnetwork restart":
Apr 10 19:23:00 server SuSEfirewall2: Warning: ip6tables does not support
state matching. Extended IPv6 support disabled.
Apr 10 19:23:00 server SuSEfirewall2: batch committing...
Apr 10 19:23:00 server SuSEfirewall2: Firewall rules unloaded.
Apr 10 19:23:00 server SuSEfirewall2: Warning: ip6tables does not support
state matching. Extended IPv6 support disabled.
Apr 10 19:23:00 server SuSEfirewall2: batch committing...
Apr 10 19:23:00 server SuSEfirewall2: Firewall rules set to CLOSE.
Apr 10 19:23:00 server SuSEfirewall2: Warning: ip6tables does not support
state matching. Extended IPv6 support disabled.
Apr 10 19:23:00 server SuSEfirewall2: Setting up rules
from /etc/sysconfig/SuSEfirewall2 ...
Apr 10 19:23:01 server SuSEfirewall2: batch committing...
Apr 10 19:23:01 server SuSEfirewall2: Firewall rules successfully set
Apr 10 19:23:03 server smpppd[5698]: terminating on signal 15
Apr 10 19:23:03 server smpppd[5694]: terminating on signal 15
Apr 10 19:24:38 server smpppd[6185]: smpppd version 1.59 started
Apr 10 19:24:58 server smpppd[6186]: terminating on signal 15
Apr 10 19:24:58 server smpppd[6216]: smpppd version 1.59 started
Apr 10 19:25:21 server pppd[4642]: Terminating on signal 15
Apr 10 19:25:21 server pppd[4642]: Connect time 99.9 minutes.
Apr 10 19:25:21 server pppd[4642]: Sent 1027406 bytes, received 4110712 bytes.
Apr 10 19:25:21 server pppd[4642]: restoring old default route to eth1
[192.168.10.1]
Apr 10 19:25:21 server pppd[4642]: Couldn't increase MTU to 1500
Apr 10 19:25:21 server pppd[4642]: Couldn't increase MRU to 1500
Apr 10 19:25:21 server pppd[4642]: Connection terminated.
Apr 10 19:25:22 server ip-down: SuSEfirewall2: Warning: ip6tables does not
support state matching. Extended IPv6 support disabled.
Apr 10 19:25:22 server SuSEfirewall2: Warning: ip6tables does not support
state matching. Extended IPv6 support disabled.
Apr 10 19:25:22 server SuSEfirewall2: Setting up rules
from /etc/sysconfig/SuSEfirewall2 ...
Apr 10 19:25:22 server SuSEfirewall2: batch committing...
Apr 10 19:25:23 server SuSEfirewall2: Firewall rules successfully set
Apr 10 19:25:23 server pppd[4642]: Script /etc/ppp/ip-down finished (pid
6313), status = 0x0
Apr 10 19:25:23 server pppd[4642]: Exit.
Apr 10 19:25:24 server SuSEfirewall2: Warning: ip6tables does not support
state matching. Extended IPv6 support disabled.
Apr 10 19:25:24 server SuSEfirewall2: Setting up rules
from /etc/sysconfig/SuSEfirewall2 ...
Apr 10 19:25:25 server SuSEfirewall2: batch committing...
Apr 10 19:25:25 server SuSEfirewall2: Firewall rules successfully set
Apr 10 19:25:25 server dhcpcd[4397]: terminating on signal 15
Apr 10 19:25:25 server dhcpcd-hook: Skipping 'ifdown $INTERFACE -o dhcp' call
Apr 10 19:25:26 server ifdown: No configuration found for eth2
Apr 10 19:25:26 server ifdown: Nevertheless the interface will be shut down.
Apr 10 19:25:27 server ifdown: No configuration found for eth3
Apr 10 19:25:27 server ifdown: Nevertheless the interface will be shut down.
Apr 10 19:25:35 server ifup-route: Warning: Could not set up default route via
interface
Apr 10 19:25:35 server ifup-route: Command ip route replace to default via
192.168.10.1 returned:
Apr 10 19:25:35 server ifup-route: . RTNETLINK answers: Network is unreachable
Apr 10 19:25:35 server ifup-route: Configuration line: default 192.168.10.1 -
-
Apr 10 19:25:35 server ifup-route: This needs NOT to be AN ERROR if you set up
multiple interfaces.
Apr 10 19:25:35 server ifup-route: See man 5 routes how to avoid this warning.
Apr 10 19:25:36 server ifup: No configuration found for eth2
Apr 10 19:25:36 server ifup: No configuration found for eth3
Apr 10 19:25:36 server pppd[7496]: Plugin rp-pppoe.so loaded.
Apr 10 19:25:36 server pppd[7496]: RP-PPPoE plugin version 3.3 compiled
against pppd 2.4.3
Apr 10 19:25:36 server pppd[7496]: Plugin passwordfd.so loaded.
Apr 10 19:25:36 server pppd[7496]: pppd options in effect:
Apr 10 19:25:36 server pppd[7496]: debug # (from command line)
Apr 10 19:25:36 server pppd[7496]: nodetach # (from command line)
Apr 10 19:25:36 server pppd[7496]: idle 0 # (from command line)
Apr 10 19:25:36 server pppd[7496]: logfd 7 # (from command line)
Apr 10 19:25:36 server pppd[7496]: ifname dsl0 # (from command line)
Apr 10 19:25:36 server pppd[7496]: dump # (from command line)
Apr 10 19:25:36 server pppd[7496]: plugin rp-pppoe.so #
(from /etc/ppp/peers/pppoe)
Apr 10 19:25:36 server pppd[7496]: plugin passwordfd.so #
(from /etc/ppp/peers/pppoe)
Apr 10 19:25:36 server pppd[7496]: active-filter xxx # [don't know how to
print value] # (from /etc/ppp/filters)
Apr 10 19:25:36 server pppd[7496]: noauth #
(from /etc/ppp/peers/pppoe)
Apr 10 19:25:36 server pppd[7496]: user irgendwea@provider-x.org # (from
command line)
Apr 10 19:25:36 server pppd[7496]: passwordfd 8 # (from command line)
Apr 10 19:25:36 server pppd[7496]: eth0 # (from command line)
Apr 10 19:25:36 server pppd[7496]: eth0 # (from command line)
Apr 10 19:25:36 server pppd[7496]: asyncmap 0 #
(from /etc/ppp/options)
Apr 10 19:25:36 server pppd[7496]: mru 1492 # (from command line)
Apr 10 19:25:36 server pppd[7496]: mtu 1492 # (from command line)
Apr 10 19:25:36 server pppd[7496]: nopcomp #
(from /etc/ppp/peers/pppoe)
Apr 10 19:25:36 server pppd[7496]: lcp-echo-failure 4 #
(from /etc/ppp/options)
Apr 10 19:25:36 server pppd[7496]: lcp-echo-interval 30 #
(from /etc/ppp/options)
Apr 10 19:25:36 server pppd[7496]: lcp-restart 2 #
(from /etc/ppp/options)
Apr 10 19:25:36 server pppd[7496]: lcp-max-configure 60 #
(from /etc/ppp/options)
Apr 10 19:25:36 server pppd[7496]: novjccomp #
(from /etc/ppp/peers/pppoe)
Apr 10 19:25:36 server pppd[7496]: ipcp-accept-local # (from
command line)
Apr 10 19:25:36 server pppd[7496]: ipcp-accept-remote # (from
command line)
Apr 10 19:25:36 server pppd[7496]: ipparam 'ifcfg-dsl0' 'provider0'
# (from command line)
Apr 10 19:25:36 server pppd[7496]: noipdefault #
(from /etc/ppp/options)
Apr 10 19:25:36 server pppd[7496]: defaultroute # (from command line)
Apr 10 19:25:36 server pppd[7496]: replacedefaultroute # (from
command line)
Apr 10 19:25:36 server pppd[7496]: noccp #
(from /etc/ppp/peers/pppoe)
Apr 10 19:25:36 server pppd[7496]: noipx #
(from /etc/ppp/options)
Apr 10 19:25:36 server pppd[7496]: pppd 2.4.3 started by root, uid 0
Apr 10 19:25:37 server pppd[7496]: PADS: Service-Name: ''
Apr 10 19:25:37 server pppd[7496]: PPP session is 53679
Apr 10 19:25:37 server pppd[7496]: using channel 12
Apr 10 19:25:37 server pppd[7496]: Renamed interface ppp0 to dsl0
Apr 10 19:25:37 server pppd[7496]: Using interface dsl0
Apr 10 19:25:37 server pppd[7496]: Connect: dsl0 <--> eth0
Apr 10 19:25:37 server pppd[7496]: Couldn't increase MTU to 1500
Apr 10 19:25:37 server pppd[7496]: Couldn't increase MRU to 1500
Apr 10 19:25:37 server pppd[7496]: sent [LCP ConfReq id=0x1
Guten Morgen! Am Montag, 10. April 2006 19:09 schrieb Andreas Koenecke:
...und poste alle Meldungen aus /var/log/messages des 'smpppd' und des 'pppd' beim Verbindungsaufbau und beim Verbindungsabbau plus ca. 10 min...
Beim Durchforsten des syslog sind mir beim Abbau der Verbindung noch folgende "verdächtige Zeilen" aufgefallen. Vielleicht hilft dies ja beim Eingrenzen des Fehlers: Apr 10 16:15:36 server pppd[30357]: Script /etc/ppp/ip-down finished (pid 3220), status = 0x0 Apr 10 16:15:36 server pppd[30357]: Connection terminated. Apr 10 16:15:36 server pppd[30357]: Modem hangup Apr 10 16:15:36 server pppd[30357]: Exit. Pfiade, Michael
Griaseich, Am Montag, 10. April 2006 19:09 schrieb Andreas Koenecke: Also nun der syslogteil beim reconnect der DSL-Verbindung: Apr 11 19:25:40 server pppd[7496]: rcvd [LCP TermReq id=0x60] Apr 11 19:25:40 server pppd[7496]: LCP terminated by peer Apr 11 19:25:40 server pppd[7496]: Connect time 1440.1 minutes. Apr 11 19:25:40 server pppd[7496]: Sent 5711017 bytes, received 22842238 bytes. Apr 11 19:25:40 server pppd[7496]: restoring old default route to eth1 [192.168.10.1] Apr 11 19:25:40 server pppd[7496]: Script /etc/ppp/ip-down started (pid 11544) Apr 11 19:25:40 server pppd[7496]: Couldn't increase MTU to 1500 Apr 11 19:25:40 server pppd[7496]: Couldn't increase MRU to 1500 Apr 11 19:25:40 server pppd[7496]: sent [LCP TermAck id=0x60] Apr 11 19:25:40 server ip-down: SuSEfirewall2: Warning: ip6tables does not support state matching. Extended IPv6 support disabled. Apr 11 19:25:40 server SuSEfirewall2: Warning: ip6tables does not support state matching. Extended IPv6 support disabled. Apr 11 19:25:40 server SuSEfirewall2: Setting up rules from /etc/sysconfig/SuSEfirewall2 ... Apr 11 19:25:41 server SuSEfirewall2: batch committing... Apr 11 19:25:41 server SuSEfirewall2: Firewall rules successfully set Apr 11 19:25:41 server pppd[7496]: Script /etc/ppp/ip-down finished (pid 11544), status = 0x0 Apr 11 19:25:42 server pppd[7496]: Connection terminated. Apr 11 19:25:42 server pppd[7496]: Modem hangup Apr 11 19:25:42 server pppd[7496]: Exit. Apr 11 19:25:42 server SuSEfirewall2: Warning: ip6tables does not support state matching. Extended IPv6 support disabled. Apr 11 19:25:42 server SuSEfirewall2: Setting up rules from /etc/sysconfig/SuSEfirewall2 ... Apr 11 19:25:43 server SuSEfirewall2: batch committing... Apr 11 19:25:43 server SuSEfirewall2: Firewall rules successfully set Wohlgemerkt, der reconnect hatte beim selben Provider mit der selben Hardware ohne Probleme funktioniert. Werd' mir mal den "röhrenden Tux" heute Abned zu Gemüte führen. Pfiadseich, BC
Hallo. * Dienstag, 11. April 2006 um 20:12 (+0200) schrieb Michael Nausch:
Also nun der syslogteil beim reconnect der DSL-Verbindung:
[ ... ]
Wohlgemerkt, der reconnect hatte beim selben Provider mit der selben Hardware ohne Probleme funktioniert. Werd' mir mal den "röhrenden Tux" heute Abned zu Gemüte führen.
Warum nicht gleich Windows installieren...? Zur Fehlersuche: Sowohl Verbindungsaufbau als auch Verbindungsabbau sind unauffällig. Die Frage ist, warum der 'smpppd' die Verbindung nicht wieder aufbaut. Die "AUTO_RECONNECT*"-Optionen hast du in "provider/<irgendeinprovider>" eingetragen? Welcher STARTMODE steht in "ifcg-dsl?"? Poste noch die Ausgaben aus "/var/log/smpppd/smpppd.log" von gestern bis heute Abend. Gruß Andreas -- XMMS spielt gerade nichts... PGP-ID/Fingerprint: BD7C2E59/3E 11 E5 29 0C A8 2F 49 40 6C 2D 5F 12 9D E1 E3 PGP-Key on request or on public keyservers --
Habedieehre! Am Dienstag, 11. April 2006 20:03 schrieb Andreas Koenecke:
Warum nicht gleich Windows installieren...?
Häää, wie bitte? Das ist doch kein ernst gemeinter Vorschlag, oder? ;) Was war das gleich nochmal, ich dachte DSL geht bei Win95 nicht?
Zur Fehlersuche: Sowohl Verbindungsaufbau als auch Verbindungsabbau sind unauffällig.
Soweit war ich schon mal.
Die Frage ist, warum der 'smpppd' die Verbindung nicht wieder aufbaut. Die "AUTO_RECONNECT*"-Optionen hast du in "provider/<irgendeinprovider>" eingetragen?
Uno Momento: server:/etc/sysconfig/network/providers # cat provider0 ASKPASSWORD='no' AUTODNS='no' DEMAND='no' DSLSUPPORTED='yes' IDLETIME='0' ISDNSUPPORTED='no' MODEMSUPPORTED='no' MODIFYDNS='no' PASSWORD='sogened!' PHONE='' PROVIDER='M"net' USERNAME='irgendwer@mdsl.mnet-online.de' DEFAULTROUTE='yes' IPADDR='' MODIFYIP='yes' REMOTE_IPADDR='' AUTO_RECONNECT='yes' AUTO_RECONNECT_DELAY='0' AUTO_RECONNECT_EXITS='0 15'
Welcher STARTMODE steht in "ifcg-dsl?"?
server:/etc/sysconfig/network # cat ifcfg-dsl0 BOOTPROTO='none' DEVICE='eth-id-00:05:5d:71:8d:00' MODEM_IP='10.0.0.138' NAME='DSL-Verbindung' PPPD_OPTIONS='' PPPMODE='pppoe' PROVIDER='provider0' STARTMODE='auto' UNIQUE='' USERCONTROL='no' VPIVCI='' PPPD_OPTIONS='dump debug'
Poste noch die Ausgaben aus "/var/log/smpppd/smpppd.log" von gestern bis heute Abend.
Tja, da steht aber verdächtig wenig drinnen: server:/var/log/smpppd # cat smpppd.log SuSE Meta pppd (smpppd), Version 1.59 on server. No interface configured. Use YaST2 to configure your dialup connections. Pfiadenachad, Michael
Hallo.
Ich habe seit einigen Jahren hier einen Server mit DSL von T-Online.
Mir sind bei den Einstellungen zwei/drei Unterschiede aufgefallen.
Ich habe noch die beiden Konfig-Dateien angehängt. Erstellt mit yast2.
Wichtig: Ich verwende SuSE 9.2
Am Tuesday, April 11, 2006 8:59 PM schrieb Michael Nausch
Habedieehre!
Am Dienstag, 11. April 2006 20:03 schrieb Andreas Koenecke:
Warum nicht gleich Windows installieren...?
Häää, wie bitte? Das ist doch kein ernst gemeinter Vorschlag, oder? ;) Was war das gleich nochmal, ich dachte DSL geht bei Win95 nicht?
Zur Fehlersuche: Sowohl Verbindungsaufbau als auch Verbindungsabbau sind unauffällig.
Soweit war ich schon mal.
Die Frage ist, warum der 'smpppd' die Verbindung nicht wieder aufbaut. Die "AUTO_RECONNECT*"-Optionen hast du in "provider/<irgendeinprovider>" eingetragen?
Uno Momento:
server:/etc/sysconfig/network/providers # cat provider0 ASKPASSWORD='no' AUTODNS='no' DEMAND='no' DSLSUPPORTED='yes' IDLETIME='0' ISDNSUPPORTED='no' MODEMSUPPORTED='no' MODIFYDNS='no' PASSWORD='sogened!' PHONE='' PROVIDER='M"net' USERNAME='irgendwer@mdsl.mnet-online.de' DEFAULTROUTE='yes' IPADDR='' MODIFYIP='yes' REMOTE_IPADDR='' AUTO_RECONNECT='yes' AUTO_RECONNECT_DELAY='0' AUTO_RECONNECT_EXITS='0 15'
Müßte hier nicht heißen: AUTODNS='yes' DEMAND='yes' Bei mir stehen keine AUTO_RECONNECT*-Einträge
Welcher STARTMODE steht in "ifcg-dsl?"?
server:/etc/sysconfig/network # cat ifcfg-dsl0 BOOTPROTO='none' DEVICE='eth-id-00:05:5d:71:8d:00' MODEM_IP='10.0.0.138' NAME='DSL-Verbindung' PPPD_OPTIONS='' PPPMODE='pppoe' PROVIDER='provider0' STARTMODE='auto' UNIQUE='' USERCONTROL='no' VPIVCI='' PPPD_OPTIONS='dump debug'
Hier steht bei mir: STARTMODE='onboot'
Poste noch die Ausgaben aus "/var/log/smpppd/smpppd.log" von gestern bis heute Abend.
Tja, da steht aber verdächtig wenig drinnen:
server:/var/log/smpppd # cat smpppd.log SuSE Meta pppd (smpppd), Version 1.59 on server. No interface configured. Use YaST2 to configure your dialup connections.
Pfiadenachad, Michael
Best regards, (auch) Michael /etc/sysconfig/network/providers/tonline-dsl: ASKPASSWORD='no' AUTODNS='yes' COUNTRY='Germany' DEMAND='yes' DSLSUPPORTED='yes' HOMEPAGE='http://www.tonline.de' IDLETIME='0' ISDNSUPPORTED='no' MODEMSUPPORTED='no' MODIFYDNS='yes' PASSWORD='<steht hier>' PHONE='' PRODUCT='T-Online' PROVIDER='T-Online' UIMODE='T-Online DSL' USERNAME='<kennung>@t-online.de' /etc/sysconfig/network/ifcfg-dsl0: BOOTPROTO='none' DEVICE='eth-id-00:e0:7d:7c:58:a3' MODEM_IP='10.0.0.138' PPPD_OPTIONS='' PPPMODE='pppoe' PROVIDER='tonline-dsl' STARTMODE='onboot' UNIQUE='' USERCONTROL='no' VPIVCI=''
HI! Am Dienstag, 11. April 2006 21:05 schrieb Heinrich Michael Schmitz:
Ich habe seit einigen Jahren hier einen Server mit DSL von T-Online. Mir sind bei den Einstellungen zwei/drei Unterschiede aufgefallen.
Na, dann schau'n ma mal, was da der Unterschied ist.
Müßte hier nicht heißen: AUTODNS='yes'
Nö, da hier ein eigener DNS läuft und der hat als forwarder die IP-Adressen des Providers drinnen.
DEMAND='yes'
Hmmm, könnte ich mal ausprobieren
Bei mir stehen keine AUTO_RECONNECT*-Einträge
Hatte ich auch mal zu Testzwecken eingetragen, weil hier in der Mailingliste Jan Ritzerfeld mir den Tip mal gab'.
Welcher STARTMODE steht in "ifcg-dsl?"? Hier steht bei mir: STARTMODE='onboot'
Na, das könnte/werde ich ja auch mal ausprobieren. Mal sehen, was passiert. Ciao, Michael
Moin. * Dienstag, 11. April 2006 um 20:59 (+0200) schrieb Michael Nausch:
Am Dienstag, 11. April 2006 20:03 schrieb Andreas Koenecke:
Poste noch die Ausgaben aus "/var/log/smpppd/smpppd.log" von gestern bis heute Abend.
Tja, da steht aber verdächtig wenig drinnen:
server:/var/log/smpppd # cat smpppd.log SuSE Meta pppd (smpppd), Version 1.59 on server. No interface configured. Use YaST2 to configure your dialup connections.
OK, mein Fehler... Poste dann die "/var/log/smpppd/ifcfg-dsl?.log". Gruß Andreas -- XMMS spielt gerade nichts... PGP-ID/Fingerprint: BD7C2E59/3E 11 E5 29 0C A8 2F 49 40 6C 2D 5F 12 9D E1 E3 PGP-Key on request or on public keyservers --
HI! Am Dienstag, 11. April 2006 21:28 schrieb Andreas Koenecke:
OK, mein Fehler...
Kein Problem.
Poste dann die "/var/log/smpppd/ifcfg-dsl?.log".
server:/var/log/smpppd # cat ifcfg-dsl0.log
SuSE Meta pppd (smpppd-ifcfg), Version 1.59 on server.
Status is: disconnected
trying to connect to smpppd
could not connect to smpppd
Interface is eth0.
Status is: connecting
pppd[0]: Plugin rp-pppoe.so loaded.
pppd[0]: RP-PPPoE plugin version 3.3 compiled against pppd 2.4.3
pppd[0]: Plugin passwordfd.so loaded.
pppd[0]: pppd options in effect:
pppd[0]: debug # (from command line)
pppd[0]: nodetach # (from command line)
pppd[0]: idle 0 # (from command line)
pppd[0]: logfd 7 # (from command line)
pppd[0]: ifname dsl0 # (from command line)
pppd[0]: dump # (from command line)
pppd[0]: plugin rp-pppoe.so # (from /etc/ppp/peers/pppoe)
pppd[0]: plugin passwordfd.so # (from /etc/ppp/peers/pppoe)
pppd[0]: active-filter xxx # [don't know how to print value] #
(from /etc/ppp/filters)
pppd[0]: noauth # (from /etc/ppp/peers/pppoe)
pppd[0]: user X0039198@mdsl.mnet-online.de # (from command line)
pppd[0]: passwordfd 8 # (from command line)
pppd[0]: eth0 # (from command line)
pppd[0]: eth0 # (from command line)
pppd[0]: asyncmap 0 # (from /etc/ppp/options)
pppd[0]: mru 1492 # (from command line)
pppd[0]: mtu 1492 # (from command line)
pppd[0]: nopcomp # (from /etc/ppp/peers/pppoe)
pppd[0]: lcp-echo-failure 4 # (from /etc/ppp/options)
pppd[0]: lcp-echo-interval 30 # (from /etc/ppp/options)
pppd[0]: lcp-restart 2 # (from /etc/ppp/options)
pppd[0]: lcp-max-configure 60 # (from /etc/ppp/options)
pppd[0]: novjccomp # (from /etc/ppp/peers/pppoe)
pppd[0]: ipcp-accept-local # (from command line)
pppd[0]: ipcp-accept-remote # (from command line)
pppd[0]: ipparam 'ifcfg-dsl0' 'provider0' # (from command line)
pppd[0]: noipdefault # (from /etc/ppp/options)
pppd[0]: defaultroute # (from command line)
pppd[0]: replacedefaultroute # (from command line)
pppd[0]: noccp # (from /etc/ppp/peers/pppoe)
pppd[0]: noipx # (from /etc/ppp/options)
pppd[0]: using channel 13
pppd[0]: Renamed interface ppp0 to dsl0
pppd[0]: Using interface dsl0
Status is: connecting
pppd[0]: Connect: dsl0 <--> eth0
pppd[0]: Couldn't increase MTU to 1500
pppd[0]: Couldn't increase MRU to 1500
pppd[0]: sent [LCP ConfReq id=0x1
Gruß
Andreas
-- XMMS spielt gerade nichts...
PGP-ID/Fingerprint: BD7C2E59/3E 11 E5 29 0C A8 2F 49 40 6C 2D 5F 12 9D E1 E3 PGP-Key on request or on public keyservers --
Hallo. * Dienstag, 11. April 2006 um 22:17 (+0200) schrieb Michael Nausch:
Am Dienstag, 11. April 2006 21:28 schrieb Andreas Koenecke:
Poste dann die "/var/log/smpppd/ifcfg-dsl?.log".
server:/var/log/smpppd # cat ifcfg-dsl0.log [ ... ] pppd[0]: Script /etc/ppp/ip-up started (pid 12924) pppd[0]: Script /etc/ppp/ip-up finished (pid 12924), status = 0x0 Status is: connected
(Logs ohne Zeitstempel sind schlecht.)
Der Rest ist natürlich von meinem "rcnetwork-restart".
Interessant wären die Zeilen vom Verbindungsabbau und die darauf folgende Zeilen. Gruß Andreas -- XMMS spielt gerade nichts... PGP-ID/Fingerprint: BD7C2E59/3E 11 E5 29 0C A8 2F 49 40 6C 2D 5F 12 9D E1 E3 PGP-Key on request or on public keyservers --
HI!
Am Dienstag, 11. April 2006 22:10 schrieb Andreas Koenecke:
(Logs ohne Zeitstempel sind schlecht.)
So, das ganze aus'm syslog mit Zeitstempel:
Apr 10 19:20:10 server smpppd[5693]: smpppd version 1.59 started
Apr 10 19:20:33 server smpppd[5697]: smpppd version 1.59 started
Apr 10 19:21:05 server smpppd[5698]: connected on local frontend socket from
uid 0
Apr 10 19:23:00 server SuSEfirewall2: Warning: ip6tables does not support
state matching. Extended IPv6 support disabled.
Apr 10 19:23:00 server SuSEfirewall2: batch committing...
Apr 10 19:23:00 server SuSEfirewall2: Firewall rules unloaded.
Apr 10 19:23:00 server SuSEfirewall2: Warning: ip6tables does not support
state matching. Extended IPv6 support disabled.
Apr 10 19:23:00 server SuSEfirewall2: batch committing...
Apr 10 19:23:00 server SuSEfirewall2: Firewall rules set to CLOSE.
Apr 10 19:23:00 server SuSEfirewall2: Warning: ip6tables does not support
state matching. Extended IPv6 support disabled.
Apr 10 19:23:00 server SuSEfirewall2: Setting up rules
from /etc/sysconfig/SuSEfirewall2 ...
Apr 10 19:23:01 server SuSEfirewall2: batch committing...
Apr 10 19:23:01 server SuSEfirewall2: Firewall rules successfully set
Apr 10 19:23:03 server smpppd[5698]: terminating on signal 15
Apr 10 19:23:03 server smpppd[5694]: terminating on signal 15
Apr 10 19:24:38 server smpppd[6185]: smpppd version 1.59 started
Apr 10 19:24:58 server smpppd[6186]: terminating on signal 15
Apr 10 19:24:58 server smpppd[6216]: smpppd version 1.59 started
Apr 10 19:25:21 server pppd[4642]: Terminating on signal 15
Apr 10 19:25:21 server pppd[4642]: Connect time 99.9 minutes.
Apr 10 19:25:21 server pppd[4642]: Sent 1027406 bytes, received 4110712 bytes.
Apr 10 19:25:21 server pppd[4642]: restoring old default route to eth1
[192.168.10.1]
Apr 10 19:25:21 server pppd[4642]: Couldn't increase MTU to 1500
Apr 10 19:25:21 server pppd[4642]: Couldn't increase MRU to 1500
Apr 10 19:25:21 server pppd[4642]: Connection terminated.
Apr 10 19:25:22 server ip-down: SuSEfirewall2: Warning: ip6tables does not
support state matching. Extended IPv6 support disabled.
Apr 10 19:25:22 server SuSEfirewall2: Warning: ip6tables does not support
state matching. Extended IPv6 support disabled.
Apr 10 19:25:22 server SuSEfirewall2: Setting up rules
from /etc/sysconfig/SuSEfirewall2 ...
Apr 10 19:25:22 server SuSEfirewall2: batch committing...
Apr 10 19:25:23 server SuSEfirewall2: Firewall rules successfully set
Apr 10 19:25:23 server pppd[4642]: Script /etc/ppp/ip-down finished (pid
6313), status = 0x0
Apr 10 19:25:23 server pppd[4642]: Exit.
Apr 10 19:25:24 server SuSEfirewall2: Warning: ip6tables does not support
state matching. Extended IPv6 support disabled.
Apr 10 19:25:24 server SuSEfirewall2: Setting up rules
from /etc/sysconfig/SuSEfirewall2 ...
Apr 10 19:25:25 server SuSEfirewall2: batch committing...
Apr 10 19:25:25 server SuSEfirewall2: Firewall rules successfully set
Apr 10 19:25:26 server ifdown: No configuration found for eth2
Apr 10 19:25:26 server ifdown: Nevertheless the interface will be shut down.
Apr 10 19:25:27 server ifdown: No configuration found for eth3
Apr 10 19:25:27 server ifdown: Nevertheless the interface will be shut down.
Apr 10 19:25:35 server ifup-route: Warning: Could not set up default route via
interface
Apr 10 19:25:35 server ifup-route: Command ip route replace to default via
192.168.10.1 returned:
Apr 10 19:25:35 server ifup-route: . RTNETLINK answers: Network is unreachable
Apr 10 19:25:35 server ifup-route: Configuration line: default 192.168.10.1 -
-
Apr 10 19:25:35 server ifup-route: This needs NOT to be AN ERROR if you set up
multiple interfaces.
Apr 10 19:25:35 server ifup-route: See man 5 routes how to avoid this warning.
Apr 10 19:25:36 server ifup: No configuration found for eth2
Apr 10 19:25:36 server ifup: No configuration found for eth3
Apr 10 19:25:36 server pppd[7496]: Plugin rp-pppoe.so loaded.
Apr 10 19:25:36 server pppd[7496]: RP-PPPoE plugin version 3.3 compiled
against pppd 2.4.3
Apr 10 19:25:36 server pppd[7496]: Plugin passwordfd.so loaded.
Apr 10 19:25:36 server pppd[7496]: pppd options in effect:
Apr 10 19:25:36 server pppd[7496]: debug # (from command line)
Apr 10 19:25:36 server pppd[7496]: nodetach # (from command line)
Apr 10 19:25:36 server pppd[7496]: idle 0 # (from command line)
Apr 10 19:25:36 server pppd[7496]: logfd 7 # (from command line)
Apr 10 19:25:36 server pppd[7496]: ifname dsl0 # (from command line)
Apr 10 19:25:36 server pppd[7496]: dump # (from command line)
Apr 10 19:25:36 server pppd[7496]: plugin rp-pppoe.so #
(from /etc/ppp/peers/pppoe)
Apr 10 19:25:36 server pppd[7496]: plugin passwordfd.so #
(from /etc/ppp/peers/pppoe)
Apr 10 19:25:36 server pppd[7496]: active-filter xxx # [don't know how to
print value] # (from /etc/ppp/filters)
Apr 10 19:25:36 server pppd[7496]: noauth #
(from /etc/ppp/peers/pppoe)
Apr 10 19:25:36 server pppd[7496]: user username@mdsl.mnet-online.de
# (from command line)
Apr 10 19:25:36 server pppd[7496]: passwordfd 8 # (from command line)
Apr 10 19:25:36 server pppd[7496]: eth0 # (from command line)
Apr 10 19:25:36 server pppd[7496]: eth0 # (from command line)
Apr 10 19:25:36 server pppd[7496]: asyncmap 0 #
(from /etc/ppp/options)
Apr 10 19:25:36 server pppd[7496]: mru 1492 # (from command line)
Apr 10 19:25:36 server pppd[7496]: mtu 1492 # (from command line)
Apr 10 19:25:36 server pppd[7496]: nopcomp #
(from /etc/ppp/peers/pppoe)
Apr 10 19:25:36 server pppd[7496]: lcp-echo-failure 4 #
(from /etc/ppp/options)
Apr 10 19:25:36 server pppd[7496]: lcp-echo-interval 30 #
(from /etc/ppp/options)
Apr 10 19:25:36 server pppd[7496]: lcp-restart 2 #
(from /etc/ppp/options)
Apr 10 19:25:36 server pppd[7496]: lcp-max-configure 60 #
(from /etc/ppp/options)
Apr 10 19:25:36 server pppd[7496]: novjccomp #
(from /etc/ppp/peers/pppoe)
Apr 10 19:25:36 server pppd[7496]: ipcp-accept-local # (from
command line)
Apr 10 19:25:36 server pppd[7496]: ipcp-accept-remote # (from
command line)
Apr 10 19:25:36 server pppd[7496]: ipparam 'ifcfg-dsl0' 'provider0'
# (from command line)
Apr 10 19:25:36 server pppd[7496]: noipdefault #
(from /etc/ppp/options)
Apr 10 19:25:36 server pppd[7496]: defaultroute # (from command line)
Apr 10 19:25:36 server pppd[7496]: replacedefaultroute # (from
command line)
Apr 10 19:25:36 server pppd[7496]: noccp #
(from /etc/ppp/peers/pppoe)
Apr 10 19:25:36 server pppd[7496]: noipx #
(from /etc/ppp/options)
Apr 10 19:25:36 server pppd[7496]: pppd 2.4.3 started by root, uid 0
Apr 10 19:25:37 server pppd[7496]: PADS: Service-Name: ''
Apr 10 19:25:37 server pppd[7496]: PPP session is 53679
Apr 10 19:25:37 server pppd[7496]: using channel 12
Apr 10 19:25:37 server pppd[7496]: Renamed interface ppp0 to dsl0
Apr 10 19:25:37 server pppd[7496]: Using interface dsl0
Apr 10 19:25:37 server pppd[7496]: Connect: dsl0 <--> eth0
Apr 10 19:25:37 server pppd[7496]: Couldn't increase MTU to 1500
Apr 10 19:25:37 server pppd[7496]: Couldn't increase MRU to 1500
Apr 10 19:25:37 server pppd[7496]: sent [LCP ConfReq id=0x1
Hallo. * Dienstag, 11. April 2006 um 23:19 (+0200) schrieb Michael Nausch:
So, das ganze aus'm syslog mit Zeitstempel:
[ ... ]
Danke, aber das hilft leider nicht weiter, da der 'smpppd' (und der ist für das Wiederverbinden zuständig) nur in seine eigenen Logs schreibt und nicht über den syslog. Der 'smpppd' sollte dort eigentlich u.a. Meldungen schreiben wie z.B. "Status is: disconnected", "Auto reconnect in 1 seconds." usw. Das macht er bei dir aber anscheinend nicht... Etwas ungewöhnlich ist in "smpppd.log" die Meldung "No interface configured...". Was gibt denn 'cinternet -I' (großes "i") aus? Gruß Andreas -- XMMS spielt gerade nichts... PGP-ID/Fingerprint: BD7C2E59/3E 11 E5 29 0C A8 2F 49 40 6C 2D 5F 12 9D E1 E3 PGP-Key on request or on public keyservers --
HI, Am Dienstag, 11. April 2006 23:28 schrieb Andreas Koenecke: Schon ein paar Tage her, aber die letzten paar Tage war ich im Krankenhaus und hatte dort leider keinen Internet-Zugriff. Wo waren wir stehen geblieben? Muss mich erst mal etwas einlesen in die Thematik, damit ich selber wieder auf dem aktuellen Stand bin. Meld' mich dann später wieder ... cu, BC
Griasade Andreas! Am Dienstag, 11. April 2006 23:28 schrieb Andreas Koenecke:
Danke, aber das hilft leider nicht weiter, da der 'smpppd' (und der ist für das Wiederverbinden zuständig) nur in seine eigenen Logs schreibt und nicht über den syslog.
Der war auch nicht sonderlich gesprächig. Mag wohl daran liegen, dass ich bei der Installation angegeben hatte, nur eine LINUX-Grundsystem, also ohne X-Server & Co., ausgewählt hatte. Hat sich aber nunmehr erledigt! Verwende nun seit ein paar Tagen den rp-pppoe, der läuft zuverlässig ohne Probleme bei der Wiedereinwahl nach der Zwangstrennung. Danke nochmals für Deine Unterstützung! Pfiade, BC
Griasde, Am Tue, 11 Apr 2006, Michael Nausch schrieb:
Am Dienstag, 11. April 2006 20:03 schrieb Andreas Koenecke:
Warum nicht gleich Windows installieren...?
Häää, wie bitte? Das ist doch kein ernst gemeinter Vorschlag, oder? ;) Was war das gleich nochmal, ich dachte DSL geht bei Win95 nicht?
Dann habe ich mir das wohl unter Win95b nur eingebildet? Aber die T-Software, die auf CD dabei war hat den Rechner direkt nach dem Start der Installation abstuerzen lassen. Mit dem freien Treiber (Name vergessen) gings dann aber problemlos. -dnh -- "Wo wir gerade bei dummen Frauen sind: Andy Möller soll von der nächsten Saison an den Oberliga-Nachwuchs der Frankfurter Eintracht trainieren. Auf dem Trainingsplan steht laut Rückspiegel-Informationen unter anderem: Heulsusen gegen Schwalbenkönige. Vom Feeling her haben wir da ehrlich gesagt kein gutes Gefühl." -- Matthias Hohnecker, im "Rückspiegel" der StZ vom 15.10.2005
Am Sonntag, 9. April 2006 20:14 schrieb Michael Nausch:
(...). Die manuellen Versuche dies via "AUTO_RECONNECT='yes'" in der /etc/sysconfig/network/providers/provider0 zu machen tut' irgendwie nicht. (...).
In meinen router-freien Tagen unter SL 9.2 hatte ich dort zusätzlich zu AUTO_RECONNECT='yes' noch folgendes eingetragen: AUTO_RECONNECT_DELAY='0' AUTO_RECONNECT_EXITS='0 15' HTH Jan -- The government that governs least governs best.
Am Montag, 10. April 2006 00:42 schrieb Jan Ritzerfeld:
Am Sonntag, 9. April 2006 20:14 schrieb Michael Nausch:
(...). Die manuellen Versuche dies via "AUTO_RECONNECT='yes'" in der /etc/sysconfig/network/providers/provider0 zu machen tut' irgendwie nicht. (...).
In meinen router-freien Tagen unter SL 9.2 hatte ich dort zusätzlich zu AUTO_RECONNECT='yes' noch folgendes eingetragen: AUTO_RECONNECT_DELAY='0' AUTO_RECONNECT_EXITS='0 15'
Und wenn das nicht hilft, nimmst du halt einfach rp-pppoe Das setze ich auch auf Servern ein, die abgeschottet irgendwo alleine vor sich hinlaufen und die ich nur über die DSL-Leitung administrieren kann. Ist in meinen Augen eigentlich zuverlässiger. Mfg, Thomas
HI, Am Montag, 10. April 2006 16:42 schrieb Thomas Gräber:
Und wenn das nicht hilft, nimmst du halt einfach rp-pppoe
Jo, das werd' ich dann auch wohl tun, hatte seinerzeit bei 7.irgendwas auch mit dem "röhrenden Pinguin" angefangen, das lief astrein. Mal sehen, wer morgen das Rennen macht. :) ttyl, Michael
Hallo, Am Mon, 10 Apr 2006, Michael Nausch schrieb:
Am Montag, 10. April 2006 16:42 schrieb Thomas Gräber:
Und wenn das nicht hilft, nimmst du halt einfach rp-pppoe
Jo, das werd' ich dann auch wohl tun, hatte seinerzeit bei 7.irgendwas auch mit dem "röhrenden Pinguin" angefangen, das lief astrein. Mal sehen, wer morgen das Rennen macht. :)
Und dann gibt's da noch den Kernel-Treiber. Und die Config ist denkbar einfach. Hat bei mir jahrelang ohne jegliche Mucken zuverlaessig funktioniert. Da reicht dann ein 'pppd eth0' (bzw. ein passendes Startscript). Den reconnect kann man mit 'persist' und 'holdoff N machen. Details auf Anfrage. -dnh -- Idiot, n.: A member of a large and powerful tribe whose influence in human affairs has always been dominant and controlling. -- Ambrose Bierce, "The Devil's Dictionary"
David Haller schrieb:
Hallo,
Am Mon, 10 Apr 2006, Michael Nausch schrieb:
Am Montag, 10. April 2006 16:42 schrieb Thomas Gräber:
Und wenn das nicht hilft, nimmst du halt einfach rp-pppoe Jo, das werd' ich dann auch wohl tun, hatte seinerzeit bei 7.irgendwas auch mit dem "röhrenden Pinguin" angefangen, das lief astrein. Mal sehen, wer morgen das Rennen macht. :)
Und dann gibt's da noch den Kernel-Treiber. Und die Config ist denkbar einfach. Hat bei mir jahrelang ohne jegliche Mucken zuverlaessig funktioniert. Da reicht dann ein 'pppd eth0' (bzw. ein passendes Startscript). Den reconnect kann man mit 'persist' und 'holdoff N machen. Details auf Anfrage.
Diesen Weg würde ich auch empfehlen. Ich hatte mal mit einem ISDN-Modem das Problem, das es sich nach einer Zwangstrennung wieder einwählen wollte, aber dann ein besetzt bekommen hat. Ergo: Man darf nicht sofort nach der abgebrochenen Verbindung eine neue aufbauen. Mit 5 Minuten bist du auf der sicheren Seite, 3 dürften auch noch reichen. Ist aber Provider- und Erfahrungsabhängig. Martin
Griasde David, bin mir nicht mehr sicher, ob'st mich noch kennst, war vor Jahren hier in der Mailingliste sehr aktiv. Die letzten Jahre ware ich nur stiller Teilhaber, weil zum einen alles wunderbar lief und ich mit VDR eine neue Spielwiese gefunden hatte. Nun gut ... Am Montag, 10. April 2006 20:02 schrieb David Haller:
Und dann gibt's da noch den Kernel-Treiber. Und die Config ist denkbar einfach.
Das hört sich doch sehr vielversprechend an!
Hat bei mir jahrelang ohne jegliche Mucken zuverlaessig funktioniert. Da reicht dann ein 'pppd eth0' (bzw. ein passendes Startscript). Den reconnect kann man mit 'persist' und 'holdoff N machen. Details auf Anfrage.
Aha, wie wollma des dann machen, hier in der ML oder per pm? FReu' mich schon auf Antwort ... ;) Pfiadebou! Michael Nausch
Hallo, Am Tue, 11 Apr 2006, Michael Nausch schrieb:
bin mir nicht mehr sicher, ob'st mich noch kennst, war vor Jahren hier in der Mailingliste sehr aktiv.
Aber klar. Das war das mit dem Bilder-PDF mit Makefile und nem LaTeX-Template ;)
Am Montag, 10. April 2006 20:02 schrieb David Haller:
Und dann gibt's da noch den Kernel-Treiber. Und die Config ist denkbar einfach.
Das hört sich doch sehr vielversprechend an!
Die Kernel-Module pppoe und pppox sind ja beim SuSE Kernel dabei, das entfaellt schonmal, bei nem eigenen Kernel muss man halt 'PPP over Ethernet' aktivieren. Dazu dann ein pppd >= 2.4.0, bei den alten 2.4er pppds braucht man evtl. noch den pppoe-patch, bei neueren sollte das pppoe-plugin (siehe plugin-Zeile unten) dabei sein. Ich konnte damals den pppd aber recht einfach updaten.
Hat bei mir jahrelang ohne jegliche Mucken zuverlaessig funktioniert. Da reicht dann ein 'pppd eth0' (bzw. ein passendes Startscript). Den reconnect kann man mit 'persist' und 'holdoff N machen. Details auf Anfrage.
Aha, wie wollma des dann machen, hier in der ML oder per pm?
Das mit dem Startscript eher per PM, das ist mir doch etwas lang geraten und ausserdem recht spezifisch fuer mein System. Ein Geruest schreib ich unten mit dazu. Ich hatte[1] nur: ==== /etc/ppp/options ==== plugin /usr/lib/pppd/2.4.1/pppoe.so ### Pfad anpassen! connect /bin/true ipcp-accept-local ipcp-accept-remote usepeerdns noipdefault defaultroute nocrtscts local noauth mru 1492 mtu 1492 lcp-echo-interval 120 lcp-echo-failure 4 debug user "<BENUTZERKENNUNG>#0001@t-online.de" hide-password pap-timeout 45 linkname eth0 novj novjccomp kdebug 0 ==== Bei dir muesstest du wohl chap konfigurieren, siehe dazu man pppd. Mit 'debug' solltest du das auch allein hinbekommen. T-Online (und deren Reseller) verwendet halt PAP zur Authentifizierung. Das Startscript sah dann von den Funktionen im groben so aus (ohne den ueblichen Uberbau und ohne Fehlerbehandlung etc.): ==== /sbin/init.d/pppoe[2] ==== IFACE="eth0" PIDFILE=/var/run/pppd-${IFACE}.pid case "$1" in start|up) /sbin/route del default /sbin/ifconfig ${IFACE} 10.234.234.1 mtu 1492 up ## ^^^^^^^^^^^^dummy IP! startproc -f ${PIDFILE} /sbin/pppd ${IFACE} >/dev/null ;; stop|down) killproc -f ${PIDFILE} -HUP /sbin/pppd /sbin/ifconfig ${IFACE} down ;; esac ==== Das war's auch schon. Fuer das reconnect muss halt die options ergaenzt werden (persist und holdoff). Also kein smpppd, kein Yast oder sonstiger Kram. Somit kann auch schon weniger schiefgehen bzw. evtl. Fehler finden sich leichter. Das komplette Startscript ist sogar ueber ein Configfile in /etc/rc.config.d konfigurierbar, bzw. bei ner neueren SuSE dann eben in /etc/sysconfig/. -dnh [1] inzwischen haenge ich per ethernet hinter ne Fritzbox [2] wie gesagt: recht spezifisch fuer mein System, aber ich zeig auch nur das "allgemeine"... -- 147: Fortran Makrosprache für ein I/O-Verhinderungssystem (Arno Eigenwillig)
Griasde David, Am Mittwoch, 12. April 2006 01:48 schrieb David Haller:
Aber klar. Das war das mit dem Bilder-PDF mit Makefile und nem LaTeX-Template ;)
Ja genau! ;) Also hatte ich doch nen bleibenden Eindruck hinterlassen, fragt sich nun nur, ob positiv oder negativ ... ;)
Das mit dem Startscript eher per PM, das ist mir doch etwas lang geraten und ausserdem recht spezifisch fuer mein System.
O.K. Werd' das die Tage mal ausprobieren, wenn das mit den Tips von Andreas Koenecke nix werden sollte. Muss mich erst mal ein wenig reaktivieren, nach den letzten Tagen im Krankenhaus. Ich meld mich dann, versprochen (oder angedroht) je nach dem wie Du es sehen willst ;) Pfiade, BC
Griasde David! Am Mittwoch, 12. April 2006 01:48 schrieb David Haller:
Das hört sich doch sehr vielversprechend an!
Die Kernel-Module pppoe und pppox sind ja beim SuSE Kernel dabei, ...
Hab' mich dazu hinreissen lassen, den rp-pppoe zu verwenden. Mit Deinen Detailangaben und ein paar how2s in web war es denkbar einfach die Internetanbindung sicherer aufzubauen. gurieren, siehe dazu man pppd.
Mit 'debug' solltest du das auch allein hinbekommen. T-Online
Ganau, das war ein wichtiger Tip! ;)
Das Startscript sah dann von den Funktionen im groben so aus (ohne den ueblichen Uberbau und ohne Fehlerbehandlung etc.):
War beim rp-pppoe rpm mit dabei. Es musss "nur" das script "/etc/init.d/adsl start" verwendet werden, das wars. Also Danke nochmals für die Hilfe! Pfiade, Michael
Griasde, Am Montag, 10. April 2006 16:42 schrieb Thomas Gräber:
Und wenn das nicht hilft, nimmst du halt einfach rp-pppoe
Hab' ich nun auch gemacht, war "relativ" einfach zu installieren und funktioniert wunderbar.
Ist in meinen Augen eigentlich zuverlässiger.
Kann ich nur bestätigen, Bis Dato keinerlei Verbindungs-(wieder-)aufbauprobleme. Danke für den Tip! Pfiade, Michael
HI, Am Montag, 10. April 2006 00:42 schrieb Jan Ritzerfeld:
In meinen router-freien Tagen unter SL 9.2 hatte ich dort zusätzlich zu AUTO_RECONNECT='yes' noch folgendes eingetragen: AUTO_RECONNECT_DELAY='0' AUTO_RECONNECT_EXITS='0 15'
O.K. hab' ich mal eingetragen und neu gestartet, mal sehen, was dann morgen passiert. Ich werd's berichten. Ciao, BC
HI, Am Montag, 10. April 2006 18:43 schrieb Michael Nausch:
O.K. hab' ich mal eingetragen und neu gestartet, mal sehen, was dann morgen passiert. Ich werd's berichten.
Nur der Vollständigkeit halber, hat nix gebracht. Benutze aktuell den roaring-pinguin, das scheint zuverlässiger zu funktionieren. cu, Michael
participants (8)
-
Andreas Koenecke -
David Haller -
Heinrich Michael Schmitz -
Jan Ritzerfeld -
Martin Ereth -
Michael Nausch -
Thomas Gräber -
Timothy Kesten