[Fli4l_dev] Informationen zum Weekly-Tarball vom 25.7.2014 (r31787)

[Christoph Schulz]

Hallo,

[ihr hättet mich ruhig darauf aufmerksam machen können, dass ich in den 
letzten Übersichten konsistent das falsche Jahr 2013 verwendet habe... ;-)]

im Vergleich zum Tarball vom 18.7.*2014* (r31698) gibt es die folgenden 
Änderungen:

---------------
Fertiggestellt:
---------------
FFL-863: Integration igmpproxy ins Paket proxy
* einige Dokumentationsverbesserungen und -übersetzungen

FFL-900: Update auf Kernel 3.14.13
* Bitte KERNEL_VERSION entsprechend anpassen!

FFL-901: Update auf Kernel 3.15.6
* Bitte KERNEL_VERSION entsprechend anpassen!

----------
In Arbeit:
----------
FFL-902: WLAN N keine 40MHz Kanäle
* Im WLAN-Betrieb nach dem 802.11n-Standard können nun 40 MHz-Kanäle genutzt 
werden.

------------------------------------------------------------
Im FFL-506-Zweig gibt es die folgenden Änderungen (gekürzt):
------------------------------------------------------------
FFL-875: dyndns Updates
* r31699,31768: Korrektur bei der Nutzung von Zertifikaten für https
* r31732: NOIP-Provider funktioniert wieder

FFL-624: OpenVPN ermöglichen die <connection/> Möglichkeiten vollständig zu 
nutzen
* r31787: Informationen über Zielhost und -netzwerk werden nun gespeichert

FFL-506:
* r31719,31733: der pppd kann jetzt Callbacks aushandeln (Client) und auch 
zurückrufen (Server), sowohl via RFC 1570 Typ 0-4 als auch mit CBCP (Typ 6); 
das Circuit-System ist aber noch nicht dafür vorbereitet, das kommt 
demnächst
* r31725: Bei Multilink-PPP wird bei CIRC_x_DEBUG='yes' nicht mehr für alle 
Slave-Links das Versenden und Empfangen von LCP-Paketen dauerhaft 
protokolliert.
* r31730: Implementierung von Leser/Schreiber-Sperren
* r31731: potentiellen Deadlock im Circuit-System durch neue 
Leser/Schreiber-Sperren (siehe r31730) eliminiert
* r31751-31765,31776-31784,31786: diverse interne Verbesserungen des 
Circuit-Systems ohne sichtbare Auswirkungen (hoffentlich ;-), als 
vorbereitende Maßnahmen für "net"-Circuits und eine vereinheitlichte 
Verwaltung der Routing-Tabellen
* r31785: Wenn bei Multilink-PPP der Zielserver keine Bündelung kann, muss 
der zweite und weitere konfigurierte Links wieder abgebaut werden. Dies hat 
irgendwann aufgehört zu funktionieren und wurde mit diesem Commit wieder 
korrigiert.

------------------

Die "FFL-<Nummer>"-Angaben sind Tickets. Sie können unter
http://bugs.fli4l.de/ eingesehen werden.

------------------
Bekannte Probleme:
------------------
* Im FFL-506-Zweig kann es auf der Seite eines PPP-Servers bei gebündelten 
Verbindungen (Multilink-PPP) dazu kommen, dass einem Link ein falsches 
Bündel zugeordnet wird. Das hat keine schlimmen Auswirkungen, außer dass man 
die Verbindung nicht beenden kann, indem man den Circuit für das eigentlich 
richtige Bündel beendet.


Viele Grüße und viel Spaß beim Testen,
-- 
Christoph Schulz
[fli4l-Team]