[Fli4l_dev] CIRC_x_HUP_TIMEOUT='0' funktioniert nicht

[Flemming Beissel]

Am 19.05.2014 09:01, schrieb Christoph Schulz:
> Hallo!
> 
> Flemming Beissel schrieb:
> 
>> Wenn ich auf den r30653-FFL-506 wechsele ist alles ok. Kein Fehler,
>> keine Leitung offline. Wochenlang ohne Probleme.
> 
> Fakt ist: Es kann nur an drei Komponenten liegen, wenn eine Meldung wie
> 
> May 18 21:11:50 r6001 local2.info pppd[8292]: No response to 3 echo-requests
> 
> kommt:
> 
> (1) der PPP-Dämon pppd (der die Echo-Anforderungen schickt, aber keine 
> Antworten empfängt)
> (2) der Kern (der das Einkapseln in PPPoE-Pakete übernimmt)
> (3) alles außerhalb (Netzwerkkarte, Kabel, DSL-Modem, Verbindung zum DSL-AC 
> etc.)
> 
> Ich habe mal nachgeschaut: Im Quelltext des pppd (1) gab es keine relevanten 
> Änderungen seit r30653 (eine einzige Änderung bezieht sich nur auf Multilink 
> PPP, das du nicht einsetzt). Der Kern (2) kann eine mögliche Ursache sein, 
> deshalb wäre es gut zu wissen, mit welchem Kern es noch funktioniert hat. Zu 
> (3) kann ich nichts sagen; ich sehe zumindest keine vernünftige Erklärung 
> dafür, dass (3) bei r30653 keine Probleme macht und bei r30947 nicht.
> 
> (2) ist insofern interessant, als wenn der BRAS die PPPoE-Sitzung beendet 
> (warum auch immer), der Kern dies zwar mit bekommt und entsprechend die 
> Sitzung auf Client-Seite storniert, dem pppd aber nicht Bescheid gegeben 
> wird. Das ist ein bekanntes (Design-)Problem unter Linux, siehe [1]. Hier 
> hilft nur das Einsetzen des PPPoE-Userspace-Dämons (also Typ "daemon"), weil 
> dann alles offenbar wird (also auch, ob die Gegenstelle die Sitzung außer 
> der Reihe terminiert).
> 
> Natürlich könnte es sein, dass durch einen Bug außerhalb der genannten 
> Komponenten irgendetwas kaputtgeht (k.A., wie das gehen sollte, aber 
> theoretisch ist das möglich), aber das ist extrem unwahrscheinlich.
> 
> Frage: Der Fehler ist mit dem aktuellen Tarball wirklich reproduzierbar? Und 
> beim Wechsel zu r30653 tritt der Fehler sagen wir innerhalb der nächsten 48h 
> definitiv nicht auf? Ich möchte einfach die Möglichkeit mehrerer Zufälle 
> 
> Wir haben ansonsten nur noch eine Möglichkeit: Wir könnten eine binäre Suche 
> machen, d.h. wir suchen die Revision, die es kaputt gemacht hat. Dazu wäre 
> es am praktischsten, wenn du deine fli4l-Installationsverzeichnisse direkt 
> aus dem SVN-Repository bauen könntest. Wenn du das versuchen magst, sag 
> Bescheid, dann gibt's von mir eine entsprechende Einführung ;-)
> 
> [1] http://lists.roaringpenguin.com/pipermail/rp-pppoe/2009q2/000020.html
> 
> 
> Viele Grüße,
> 
Ich setze jetzt den r30653  wieder ein und werden ihn 2-3 Tage laufen
lassen.
Danach melde ich mich wieder.

Gruß
Flemming