Re: pppd Probleme bei Verbindungsabbruch

On Fri, Mar 05, 2004 at 10:17:09AM +0100, Andreas 'AnZy' Zymny wrote:
> Schoenen guten Morgen.
>
>
> Ein kleiner alter Pentium 1 Rechner (FreeBSD 5.0, bin bisher nicht
> dazu gekommen ein Update zu machen; wohl eher weil das kompilieren
> sooooo lange dauert) sorgt dafuer, dass mein kleines Rechenzentrum
> Pakete in die grosse weite Welt verschicken und auch empfaengen kann.
>
> Leiter Gottes haelt es der Anbieter der DSL Leitung fuer eine gute
> Idee, nach 24 Stunden eine Zwangstrennung vorzunehmen. Normaler Weise
> kein echtes Problem, sollte man meinen...
>
> Mein bind mag diese ploetzlichen Verbindungsabbrueche scheinbar gar
> nicht, und ist dann nicht mehr gewillt Anfragen ausserhalb des lokalen
> Netzwerkes zu beantworten. Anfragen aus internen Netzen beantwortet er
> zwar immer noch, fuer gewoehnlich kann ich immer noch Pakete in die
> grosse weite Welt versenden, was dann dafuer gesorgt hat, dass ich
> erst nach einigen Tagen gedacht habe "Hmmmm, seit zwei Tagen kein Spam
> mehr, da kann was nicht stimmen". Dank der Erfindung des crond hilft
> mir hier ein kleiner Hack. (fragt bitte nicht nach Einzelheiten :) )

Du darfst den bind nicht an die externe IP binden lassen und diese
auch nicht als PAcketabsender verwenden lassen.
Der macht nämlich eigene UDP Sockets pro IP was ihm dann nach einem
reconnect die Verbindung kappt.

> Viel mehr Sorgen bereitet mir der pppd, der das scheinbar etwas
> schlechter zu verkraften scheint.

pppd? - du meinst ppp(8) - jedenfalls wäre das so üblich und deine
Config da unten wäre auch nicht für den pppd(8) geeignet.

> Zunaechst mal die Config:
>
> ppp_enable="YES"
> ppp_mode="ddail"
> ppp_nat="YES"
> ppp_profile="default"
>
> default:
> set device PPPoE:fxp0
> set MTU max 1460
> set MRU max 1460
> set timeout 0
> set dial
> set crtscts off
> set speed sync
> disable lqr
> disable deflate
> disable pred1
> disable vjcomp
> disable acfcomp
> disable protocomp
> enable mssfixup
> enable tcpmssfixup
> set log Phase LCP IPCP CCP Warning Error Alert connect
> set ifaddr 10.0.0.1/0 10.0.0.2/0 0.0.0.0 0.0.0.0
> add default HISADDR
> set login
>
> Die letzten zwei Zeilen mit den Zugangsdaten spare ich Euch. Ja, die
> MTU/MRU ist korrekt, so will es mein Provider.
>
> Wird die Verbing vom rosa Riesen zwangsgetrennt, reagiert mein pppd
> auf drei unterschiedliche Arten:
>
> 1. Es interessiert ihn nicht, und die Verbindung wird einfach neu
> aufgebaut. Das ist die angenehmste Art.
>
> 2. Versuche mit einem ping ein Paket in die grosse weite Welt zu
> senden wird mit der Meldung "No buffer space availible" beantwortet.
> Scheinbar steht die Verbindung, da ifconfig fuer tun0 dann etwas in
> der Art wie folgendes ausspuckt:

Du hast keine Keep-Alive gesetzt.
Wenn die Gegenstelle die Verbindung abbaut ist alles OK.
Wenn allerdings die Verbindung zur Gegenstelle abreisst, weil z.B. der
Router der Gegenseite crashed, dann bekommt der ppp nicht mit dass die
Verbindung tot ist.
 enable lqr
 set lqrperiod 45
Und werfe das disable lqr raus.

> tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1460
> inet 10.0.0.1 --> 10.0.0.2 netmask 0xffffffff
> inet 213.146.112.245 --> 195.62.99.234 netmask 0xffffffff
> Opened by PID 32855
>
> Ich hatte das Problem schonmal vor einem knappen Jahr, und habe dann
> festgestellt, dass die MTU in diesem Fall haeufig verstellt war (hatte
> dann einen Wert von 1500). Mit einem beherzten
>
> # ifconfig tun0 mtu 1460

Kann ich nichts zu sagen - die war bei mir nie verdreht.

> konnte ich das Problem loesen. Ich hatte damals mit einem Befehl (der
> mir mitlerweile entfallen ist) nachgeschaut wie der Buffer wirklich
> aussieht, und der war niemals wirklich voll. Ich konnte mir die
> Fehlermeldung nie erklaeren.
>
> Manchmal hilft der Trick nicht, die MTU ist auch nicht verstellt, und
> es hilft nur noch den pppd abzuschiessen und neu zu starten. Das ist
> die komplizierteste Art.
>
> 3. Der pppd stellt automatisch keine neue Verbindung her, obwohl das
> in der Config ausdruecklich gewuenscht wird. Das ist die aergerlichste
> Art.
>
>
> Erstaunlicher Weise scheint in meinem Rechner ein kleiner Pumuckl zu
> sitzen, der mit Wuerfeln entscheidet wie mein Rechner tagtaeglich
> reagiert, und jeden Morgen beginnt das gleiche Ritual: Wetten
> abschliessen, was fuer ein Problem denn heute anliegt.
>
>
> Da sich der pppd (oder welcher Dienst auch immer dafuer verantwortlich
> ist) immer wieder anders verhaelt, ist das debugging extrem schwierig.
> Das hier ist z.B. das Logfile von heute morgen (gegen 9:15 habe ich
> den pppd abgeschossen und neu starten muessen, und: Nein, ich habe
> die Logfile Eintraege zwischen 2:55:47 und 9:14:26 nicht
> unterschlagen):
>
> Mar 5 00:00:00 odo newsyslog[27156]: logfile turned over
> Mar 5 00:18:05 odo ppp[17295]: LCP: deflink: RecvEchoRequest(43) state = Opened
> Mar 5 00:18:05 odo ppp[17295]: LCP: deflink: SendEchoReply(43) state = Opened
> Mar 5 00:40:37 odo ppp[17295]: LCP: deflink: RecvEchoRequest(44) state = Opened
> Mar 5 00:40:37 odo ppp[17295]: LCP: deflink: SendEchoReply(44) state = Opened
> Mar 5 01:03:09 odo ppp[17295]: LCP: deflink: RecvEchoRequest(45) state = Opened
> Mar 5 01:03:09 odo ppp[17295]: LCP: deflink: SendEchoReply(45) state = Opened
> Mar 5 01:25:40 odo ppp[17295]: LCP: deflink: RecvEchoRequest(46) state = Opened
> Mar 5 01:25:40 odo ppp[17295]: LCP: deflink: SendEchoReply(46) state = Opened
> Mar 5 01:48:12 odo ppp[17295]: LCP: deflink: RecvEchoRequest(47) state = Opened
> Mar 5 01:48:12 odo ppp[17295]: LCP: deflink: SendEchoReply(47) state = Opened
> Mar 5 02:10:44 odo ppp[17295]: LCP: deflink: RecvEchoRequest(48) state = Opened
> Mar 5 02:10:44 odo ppp[17295]: LCP: deflink: SendEchoReply(48) state = Opened
> Mar 5 02:33:15 odo ppp[17295]: LCP: deflink: RecvEchoRequest(49) state = Opened
> Mar 5 02:33:15 odo ppp[17295]: LCP: deflink: SendEchoReply(49) state = Opened
> Mar 5 02:55:47 odo ppp[17295]: LCP: deflink: RecvEchoRequest(50) state = Opened
> Mar 5 02:55:47 odo ppp[17295]: LCP: deflink: SendEchoReply(50) state = Opened

Jaja - die Gegenseite macht LQR - die weiss wann die Verbindung tot ist.
Du jedoch nicht...
Schalte LQR ein und dein Router hätte bereits hier einen Verbindungs-
abbruch erkannt.

> Mar 5 09:14:26 odo ppp[17295]: Phase: Signal 15, terminate.
> Mar 5 09:14:26 odo ppp[17295]: IPCP: deflink: LayerDown: 213.146.112.245
> Mar 5 09:14:26 odo ppp[17295]: IPCP: Using trigger address 0.0.0.0
> Mar 5 09:14:26 odo ppp[17295]: IPCP: deflink: SendTerminateReq(3) state = Opened
> Mar 5 09:14:26 odo ppp[17295]: IPCP: deflink: State change Opened --> Closing
> Mar 5 09:14:29 odo ppp[17295]: IPCP: deflink: SendTerminateReq(3) state = Closing
> Mar 5 09:14:38 odo last message repeated 3 times

Wenn du eine Flatrate hast, dann starte den ppp am besten mit ddial.
Ansonsten sind deine redial Timer ungünstig, da der in dem Fall kein
Erfolg hatte und dann irgendwann aufgibt - dummerweise bleibt dann
der Buffer voll und du kannst keine neuen Triggerpackete mehr schicken.

> Zunaechst muss ich einmal zugeben, dass ich das Logfile des pppd nicht
> lesen kann. Ich bezweifle, dass die Zwangstrennung um 9:14 erfolgte,
> das muss zwei bis drei Stunden frueher passiert sein.
>
>
> Erstaunlicher Weise hatte ich das Problem im Sommer letzten Jahres als
> geloest betrachtet: Seit dem hatte ich diese Probleme nur noch alle
> zwei/drei Monate. Seit drei Wochen haeufen sich diese aber wieder.

Wäre die Lösung nicht niemals gewesen?

> Hat irgendjemand eine Idee, wie ich dem Problem auf die Spur kommen
> und auch beseitigen kann?
>
>
> Ist vielleicht nicht mein pppd schuld, sondern der Rosa Riese oder
> mein Provider? Wie kann ich Beweise sichern, aus denen die sich nicht
> mit "Das Problem ist nicht auf unserer Seite" herauswinden koennen?

Lässt sich so einfach nicht klären.
Der obige Fall ist ein Kommukationsabbruch zum Router der Gegenseite.
Das mag ein Leitungsausfall, aber auch ein Routerausfall sein.
Selbst wenn dein DSL Modem noch ein Sync hat sagt das nur was über die
Leitung bis zur Vermittlungssstelle aus.

-- 
B.Walter                   BWCT                http://www.bwct.de
ticso(at)bwct.de                                  info(at)bwct.de
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message