[Fli4l_dev] CIRC_x_HUP_TIMEOUT='0' funktioniert nicht

[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,
-- 
Christoph Schulz
[fli4l-Team]