[Fli4l_dev] Informationen zu den wöchentlichen 4.0-Archiven vom 13.2.2015 (r37079)

[Matthias Prager]

Hallo zusammen,

ein Update von der OpenVPN Front:
Ich habe heute die 3.10.2-r40320-testing Version es fli4l 3.10er Zweigs
in der Praxis meines Vaters aufgespielt. Erfreulicherweise kann ich
berichten, dass mit dieser Version OpenVPN dort nun wieder tadellos
läuft (zumindest was erste Tests angeht). Das Problem scheint sich also
entweder durch OpenVPN-, Kernel- oder Skriptupdates erledigt zu haben.
Da kein Bugreport zu dem Thema offen ist, wollte ich doch zumindest die
ML dies wissen lassen.

Ich werde dieses System von Zeit zu Zeit im 3.10er Zweig updaten und
etwaige Bugs reporten, damit dieser Zweig mehr Testabdeckung erhält.
Systeminfos: Intel DC2500CC (Dual-Core Atom, 64bit, 2x Intel-LAN).
Genutzte Features: openvpn+bridging, dns, qos, chrony, rrdtool, dsl
(telekom ipv4), dyndns, ssh und usb.

Viele Grüße
Matthias Prager


Am 13.02.2015 um 12:43 schrieb Matthias Prager:
> Hallo Christoph,
> 
> 4.0.0-r37079-testing läuft hier mit Kernel 3.18.6 ohne Probleme.
> 
> In der Praxis meines Vaters habe ich vor ein paar Tagen die
> 3.10.1-r36954-testing (Kernel 3.14.31) einspielen lassen (habe meinem
> Vater den präparierten fli4l-Ordner mit gegeben). Dort lief vorher
> 3.9.0-r31300-FFL-506 mit Kernel 3.10.44. Das Update an sich klappte
> auch, Internet lief. Aber die OpenVPN Einwahl (läuft im tap-Modus)
> funktionierte nicht mehr. Im OpenVPN-log auf Clientseite sah man keine
> Auffälligkeiten, nur wird das Verbindungsicon nicht grün, sondern bleibt
> gelb. (er kommt bis 'UDPv4 link remote: [AF_INET]...', OpenVPN Client
> Version ist 2.3.6)
> 
> Mein Vater hat daraufhin schnell wieder die alte Version
> (3.9.0-r31300-FFL-506) eingespielt, damit lief es dann wieder.
> 
> Soll ich dafür einen Bugreport aufmachen? Ich kann leider nur indirekt
> und recht uninteraktiv Debugging-Infos liefern.
> 
> Viele Grüße
> Matthias
>