mal wieder ein ppp problem

H

homer0815

Well-Known Member
Hi Folks.
Seit letztem Samstag habe ich das Problem das ppp nicht reconnected. An sich noch nicht weiter tragisch - aber er lastet danach das System so aus, das allein der Login per SSH bis zu 3min dauert!? Ich habe keine conf's geändert, mein Server stand ein Monat im Keller und "servte".

Eine Anfrage bei der Telekom ergab nur das Übliche "wir haben nichts geändert - alles in Ordnung". Brauche Hilfe oder werde Wahnsinnig

Anbei meine ppp.conf (orig. natürlich eingerückt)
PHP: 
default:
 set device PPPoE:dc1
 set speed sync
 set mru 1492
 set mtu 1492
 set ctsrts off
 set log Error tun
 add default HISADDR
 disable ipv6cp
 disable lqr
 disable deflate
 disable pred1
 disable vjcomp
 disable acfcomp
 disable protocomp
 enable dns
 set authname ich@mein.isp
 set authkey mein_passwd

Edit: ppp wird gestartet mit
/usr/sbin/ppp -quiet -ddial -nat default
 
Zuletzt bearbeitet:
Hallo.

Das Problem hatte ich auch schon ein paar mal.

Da war wohl ne Stoerung in der Vermittlungsstelle von der Telekom.
Irgendwie checkt das entweder FBSD oder das Modem nicht, dass dem
so ist, und lastet das System aus - hatte auch den gleichen effekt, dass
man etwa 1-2 Minuten auf den Login-prompt warten musste, und dann
den pppd wieder von hand anschmeissen.

Ist eigentlich 4 Monate einwandfrei alles gelaufen, auf einmal hatte ich
das Phaenomaen fast schon 2 mal Woechentlich - Die hatten wohl derbe
Probleme in der Vertmittlungsstelle.

Naja seitdem ich auf nen All-in-One Router umgestiegen bin, hab ich das
Problem auch nicht mehr.

Lange rede, kurzer Sinn: War nur n (hoffentlich) temporaerer Ausfall der
Vermittlungsstelle.
Um deinem FBSD den automatischen reconnect wieder beizubringen, boote
ihn einfach neu (mir war nie ne andere moeglichkeit uebrig geblieben - da er,
wie gesagt, trotz -ddial nicht automatisch reconnected)



greetz: weed
 
Danke für die Antwort.
Es kann aber doch nicht wahr sein das ich alle 24h meinen Server!!! resetten soll nur weil die Telekom Mist baut. Immerhin bezahle ich für DSL dann kann ich ja wohl auch verlangen das das funktionert.

Wenn ppp den disconnect nicht sauber peilt gibt es dann wenigstens eine Alternative?
 
homer0815 schrieb:
Wenn ppp den disconnect nicht sauber peilt gibt es dann wenigstens eine Alternative?
Zum Vergrößern anklicken....

Kill & restart skript in /etc/periodic/daily reinkopieren. Fertig.

#!/bin/sh
pkill ppp
/etc/rc.d/ppp-user start
 
geh mal auf www.unixscout.org, Sektion Netzwerk, ganz unten, Artikel "Perl, restart den pppd, ppp -ddial, Oops RCR in Initial" ist ein Perl-Skript, das diesen Fehler loest.
Ist zwar OpenBSD muesste aber auch auf FreeBSD gehen, imho
 
Hallo.

Da hast du wohl was missverstanden.
Du sollst ihn ja nicht alle 24h "resetten", sondern nur einmal neu booten.
Dann funzt der ddial wieder (bis zum naechsten Ausfall der Vermittlungsstelle,
was hoffentlich nicht so schnell wieder passiert.)


greetz: weed
 
Hi homer,

in deiner ppp.conf fehlt der "set ifaddr ..." Eintrag.

siehe man ppp.conf

(snip)
In -auto mode, at least one ``system'' must be given on the com-
mand line (see below) and a ``set ifaddr'' must be done in the
system profile that specifies a peer IP address to use when con-
figuring the interface. Something like ``10.0.0.1/0'' is usually
appropriate. See the ``pmdemand'' system in
/usr/share/examples/ppp/ppp.conf.sample for an example.
(snip)

Du solltest auch den "default" Eintrag nich von der Komandozeile aufrufen, da der ja sowieso eingelesen wird.

(snip)
One or more configuration entries or systems (as specified in
/etc/ppp/ppp.conf) may also be specified on the command line. ppp will
read the ``default'' system from /etc/ppp/ppp.conf at startup, followed
by each of the systems specified on the command line.
(snip)
 
Zuletzt bearbeitet:
Danke, habe ich geändert - ändert allerdings nichts. Nach der Trennung immer noch Systemlast und kein reconnect.

Wie oben beschrieben ging bis letzen Samstag alles noch (auch mit meiner "fehlerhaften" ppp.conf). Habe auch schon 2 andere Modems und NICs genommen um Hardwarefehler auszuschließen.

Das -default kommt aus dem Aufruf von ppp über die rc.conf - habs gelöscht.

Es war kein Ausfall an der Vermittlungsstelle - seit letztem Samstag wird nach der Trennung nicht mehr eingewählt un das ganze System geht in die Knie. Dann hilft meistens nur ein reset (zumal hochfahrn schneller geht als sich mit ssh einzuloggen)
Dann ist für 24h Ruhe bis zum nächsten disconnect.

Die T-Com streitet aber ab irgendetwas geändert zu haben (wie schon einmal wo sie dann doch fehlerhafte Updates auf einen Juniper gespielt haben)
 
Zuletzt bearbeitet:
Hallo homer0815,

in meiner ppp.conf habe ich aufgrund ähnlicher Probleme folgende Einträge:
Code: 
set timeout 180
set reconnect 3 5

Viele Grüße

Jürgen
 
problem immer noch da

@all - Danke für die vielen Antworten - aber KEINE hat das Problem gelöst.
Sogar das Perlscript hat versagt. ping und host liefern bei der Auslastung keine Antworten weil ppp die ganze Leistung in Anspruch nimmt.

Was ich bemerkt habe ist, obwohl eindeutig disconnected ist, hat tun0 noch eine IP
und die default-route ich habe aber in meiner ppp.linkdown das die default-route geändert wird. ppp scheint einfach nicht mitzubekommen das die Verbindung nicht mehr besteht.

Gibts es nicht einfach eine Alternative zu pppd?
So wie der ntpd von OpenBSD - der ist ja auch besser ^^
 
Moin homer0815,

zwei Ideen habe ich noch:
(1) schreibe doch bitte dieses "set log Phase Chat LCP Warning Alert" in die ppp.conf und übermittle uns das ppp.log
(2) bei mir ist noch folgender Eintrag zusätzlich: "delete all"

Teste dies doch bitte.

Viele Grüße

Jürgen
 
meine funktionierende ppp.conf sieht so aus:

default:
#PPP over Ethernet
#nat enable yes
nat enable no
set device PPPoE:ed0
set speed sync
set mru 1492
set mtu 1492
set ctsrts off
enable echo
enable lqr
log phase tun
add default HISADDR
#enable dns
set login
set authname "XXXXXXXXX"
set authkey XXXXXXXXXX
disable ipv6cp
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben