xDSL@home: pptp müllt log mit "buffering packet" z

[Lupin III.]

Nachdem meine xdsl@home-Verbindung unter Slackware endlich (etwas instabil) läuft, logged pptp massenweise Meldungen diesen Typs ins message-log (bis zu 50mal pro "expecting #####" wobei sich die Nummer bei "buffering" jedesmal um eins erhöht)

Code: Alles auswählen

pptp[27394]: anon log[decaps_gre:pptp_gre.c:388]: buffering packet 456737 (expecting 456736, lost or reordered)

Solche Blocks hab ich im Schnitt alle 3 Minuten, was dann insgesamt über 95% aller Message-Log Einträge ausmacht. Ich vermute mal, dass da einfach nur ein Paket verlorengegangen ist, also kein Grund das Log zuzumüllen.

Kann mir jemand sagen wie ich das Logging deaktivieren kann? Mit "man pptp" habe ich leider keine Option dazu gefunden.

Und weiss jemand, welche Auswirkungen auf die Verbindung das haben kann?

[erdie]

ja kenn ich (kannte ich)

code zeile im source auskommentieren, neu compilen und a ruh is

d.h. z.B. aus:

Code: Alles auswählen

#if 1 /* some logging of reordening is required, we might miss some "side effects" */
    log("buffering out-of-order packet %d (expecting %d)", seq, seq_recv+1);
#endif


mach:

Code: Alles auswählen

#if 1 /* some logging of reordening is required, we might miss some "side effects" */
    /* log("buffering out-of-order packet %d (expecting %d)", seq, seq_recv+1); */
#endif


[Lupin III.]

Beim Durchschauen der Quellen der neuen Version (pptp 1.4.0) bin ich darauf gestoßen, dass es eine Option dafür gibt, die nicht in der man-Page steht. --loglevel <level>. Inzwischen bekommt man das auch angezeigt, wenn man pptp ohne Parameter aufruft. War bei 1.3.1 noch nicht so.
In dem Fall werde ich wohl den Parameter vorziehen, als der Source mit der groben Haue zu Leibe zu rücken.

Noch zur zweiten Frage: wie oft sollte das höchstens passieren, dass diese Einträge (also packetloss) auftauchen?

[erdie]

Noch zur zweiten Frage: wie oft sollte das höchstens passieren, dass diese Einträge (also packetloss) auftauchen?

also die meldung ist bei mir meistens so um die 200 mal in 6 stunden gekommen:

Code: Alles auswählen

pptp[864]: anon log[decaps_gre:pptp_gre.c:397]: buffering out-of-order packet 4094368 (expecting 4094362)


[Lupin III.]

Ich weiss, zwar nicht wieviele Pakete gepuffert werden, aber bei mir sind es im Schnitt 5000 Zeilen am Tag gewesen. Dabei muss man allerdings beachten, dass pro expecting-Nummer um die 30 dieser Zeilen kommen können. Wenn das alle verlorenen Pakete (also etwas zwischen 100 und 200) wären, wärs ja gar nicht so schlecht für einen Tag.
Da aber bei einem 100-Pakete-ping zum inode-DNS bis zu 5 mal die Antwort fehlt, kann das wohl nicht stimmen. Blöd, dass man die Qualität der Verbindung nicht wirklich testen kann.

Naja, das Logging habe ich deaktiviert, die Leitung läuft bis auf unerklärliche Abbrüche (dank cron-job nicht so schlimm) ganz gut und solange es nicht schlimmer wird kann ich damit leben. Die ISDN-Complete Leitung war allerdings stabiler. Da wusste man wenigstens, dass sie genau alle 8 Stunden getrennt wird und sonst ist sie brav durchgelaufen.

[erdie]

ich glaub den packetloss ham derzeit alle user, lies dich nur mal um hier.

aber bis auf ein, zwei tage im monat is die verbindung sonst ziemlich stabil:

Code: Alles auswählen

Dec  5 01:14:45 cel-400 pppd[21718]: Connect time 298.2 minutes.
Dec  8 03:41:49 cel-400 pppd[24012]: Connect time 4466.3 minutes.
Dec 10 05:55:41 cel-400 pppd[22968]: Connect time 3009.3 minutes.
Dec 10 06:15:33 cel-400 pppd[11721]: Connect time 18.2 minutes.
Dec 10 06:53:08 cel-400 pppd[11938]: Connect time 35.6 minutes.
Dec 16 05:03:18 cel-400 pppd[12273]: Connect time 8527.3 minutes.
Dec 17 03:41:42 cel-400 pppd[6842]: Connect time 1357.8 minutes.
Dec 17 03:55:54 cel-400 pppd[16444]: Connect time 3.1 minutes.
Dec 17 04:38:31 cel-400 pppd[16571]: Connect time 39.7 minutes.
Dec 17 06:12:34 cel-400 pppd[17029]: Connect time 89.1 minutes.
Dec 18 05:12:21 cel-400 pppd[17759]: Connect time 1375.8 minutes.
Dec 18 05:27:27 cel-400 pppd[27519]: Connect time 3.1 minutes.
Dec 18 05:59:52 cel-400 pppd[27745]: Connect time 25.6 minutes.
Dec 23 09:58:11 cel-400 pppd[28133]: Connect time 7431.5 minutes.
Jan  1 11:53:19 cel-400 pppd[14257]: Connect time 13073.7 minutes.


apropos crontab - müllt der dir nicht auch die logs voll, jedesmal wenn er ausgeführt wird?

[Lupin III.]

Mit solchen Verbindungszeiten wäre ich zufrieden. Ich hatte in den letzten drei Wochen (solange läuft xDSL unter Linux) nur einmal etwas mehr als 2000 und 4x über 1000 Minuten, im Schnitt ca. 600. Was eigenartig ist: die 4 Zeiten zwischen 1000 und 2000 sind 1440.9, 1440.8, 1440.9 und 1484.9 was jeweils ziemlich genau 24 Stunden entspricht, und alle wurden um 17 Uhr herum getrennt. Überhaupt sind die Hälfte meiner Verbindungen zwischen 15 und 18 Uhr abgebrochen. Ich werde mal weiter beobachten, ob das Zufall ist oder sich fortsetzt.

Zu crond: Ja, er müllt, aber bei mir in eine eigene Datei. Dazu in /etc/syslog.conf folgende Zeile eintragen:

Code: Alles auswählen

cron.*         -/var/log/cron

Wenn man zusätzlich crond mit folgender Zeile startet, werden alle Job-Ausgaben auch in diese Datei geschrieben (man bekommt auch keine Email mehr, wenn mal was nicht hinhaut).

Code: Alles auswählen

/usr/sbin/crond -l8 >>/var/log/cron 2>&1

Wenn man -l hinaufsetzt, wird sogar noch weniger geloggt, Standard ist glaube ich sowieso 8, aber ich geb's trotzdem an.

[erdie]

interessant

na ich habs jetzt halt mit einem endlos script gelöst, geht auch gut:

Code: Alles auswählen

while true

    do
        sleep 120

        if (ps aux |grep pptp|grep -v grep > /dev/null) &&
           (ps aux |grep pppd|grep -v grep > /dev/null)

        then
            sleep 1
        else
            killall -9 pptp
            sleep 5
            /usr/local/bin/xdsl
        fi

    done


[Lupin III.]

Das würde bei mir leider nicht funktionieren (zumindest das mit dem 'ps ax', die Endlosschleife schon), da pptp und pppd komischerweise weiterlaufen auch wenn keine Daten mehr über die Leitung gehen (was ich in einem anderen Beitrag geschrieben habe). Deswegen pinge ich aus einem Perl-Skript jede Minute ein paar Adressen und wenn keine davon antwortet wird neu verbunden.
Aber eigentlich hast du recht, ich könnte das Skript auf Endlosschleife umbauen, dann würde ich mir auch ersparen zu prüfen, ob der Aufruf von vor einer Minute noch läuft. Ich werde mal schauen, ob's sonst vielleicht noch irgendwelche Vorteile bringt.