[Fli4l_dev] CIRC_x_HUP_TIMEOUT='0' funktioniert nicht

[Christoph Schulz]

Hallo!

Christoph Schulz schrieb:

> Hmmm... da ist noch nichts angekommen. Komisch. Na ja, ich warte einfach
> noch etwas.

So, nun ist alles da. Ein erster Blick in die Protokolle verrät, dass die 
Korrelation mit dem Tarball-Update ein Zufall zu sein scheint: Dein DSL-BRAS 
(Broadband Remote Access Server), der die PPPoE-Sitzung "auf der anderen 
Seite" terminiert, meldet sich nach einiger Zeit einfach nicht, und der PPP-
Client auf dem fli4l baut die Verbindung dann ordentlich ab:

May 18 21:11:50 r6001 local2.info pppd[8292]: No response to 3 echo-requests
May 18 21:11:50 r6001 local2.notice pppd[8292]: Serial link appears to be 
disconnected.
May 18 21:11:50 r6001 local2.info pppd[8292]: Connect time 310.7 minutes.

Danach versucht sich dein fli4l wieder zu verbinden, was teilweise etwas 
länger dauert, weil dein DSL-BRAS nicht auf initiierende PPPoE-Pakete 
reagiert:

May 18 21:12:40 r6001 local2.warn pppd[20057]: Timeout waiting for PADS 
packets
May 18 21:12:40 r6001 local2.err pppd[20057]: Unable to complete PPPoE 
Discovery
[...]
May 18 21:13:21 r6001 local2.warn pppd[22909]: Timeout waiting for PADS 
packets
May 18 21:13:21 r6001 local2.err pppd[22909]: Unable to complete PPPoE 
Discovery
[...]

Ich tippe auf eine (hoffentlich nur temporär) instabile DSL-Verbindung. Ich 
hatte hier lokal auch so einen Fall, was über mehrere Wochen ging und erst 
dann nachhaltig behoben wurde, als man mich von einer Baugruppe auf eine 
andere (und somit auch auf ein anderes Leitungsbündel) geschaltet hat, denn 
vorher seien die Trennungsbedingungen auf einmal (?!) verletzt gewesen, 
sprich meine Leitung war zu nah an einer anderen, und die haben sich 
gestört. (Vectoring ist hier nicht, ich hatte wahnsinnig schnelle 
448kbit/96kbit...)

Ich gehe mal davon aus, dass du dein LAN und die Verbindung zum DSL-Modem 
nicht über denselben Switch / dieselbe Netzwerkkarte im fli4l gehen lässt, 
sondern separate Netzwerkanschlüsse nutzt. Im anderen Falle könnte es 
theoretisch zu Problemen kommen, wenn das DSL-Modem irgendwelche Nicht-
PPPoE-Pakete sieht, mit denen es ohnehin nichts anfangen kann.

Schließlich kannst du noch vom Typ "kernel" auf "daemon" wechseln 
(CIRC_1_PPP_ETHERNET_TYPE='daemon'), dann gibt es mehr Debug-Ausgaben bei 
der PPPoE-Aushandlung. Auch ist mir ein Fall bekannt, da scheint PPPoE via 
Userspace-Prozess stabiler zu funktionieren als über den Kernel-Treiber 
(Grund unbekannt; wir sind dran, es herauszufinden).


Viele Grüße,
-- 
Christoph Schulz
[fli4l-Team]