FIY
-------- Forwarded Message --------
Subject: [gluon] [ANNOUNCE] Gluon v2016.2
Date: Wed, 21 Sep 2016 20:45:56 +0200
From: Matthias Schiffer <mschiffer(a)universe-factory.net>
To: gluon(a)luebeck.freifunk.net
CC: Freifunk Firmware Entwicklung <firmware-devel(a)freifunk.net>, WLANware <wlanware(a)freifunk.net>
Hey,
Gluon v2016.2 is out! The changelog is a bit smaller than usual for a major
release, but I still think the wait was worth it - we have:
* Tons of new hardware support (we finally removed the BROKEN flag from the
ath10k devices!)
* Bugfixes (improved WLAN stability!)
* Various new features
As always, here are the full release notes:
http://gluon.readthedocs.io/en/v2016.2/releases/v2016.2.html
A big thanks to all our contributors [1]!
-- NeoRaider
[1] https://github.com/freifunk-gluon/gluon/graphs/contributors
Hi,
War das Wochenende über mit fkr, ulf und Malte in Kiel auf den Kilux.
Ich hab gesehen das die Freifunk kieler u.a. über hide.me traffic abkippen:
https://hide.me/en/
evtl. wäre das bei uns als zusätzlicher exit auch noch interessant.
Bzw. ich hatte überlegt mal ein wenig in die Richtung zu experimentieren
das man weg von supernodes geht und z.b. einzelne Router direkt an vpn
exits hängt.
Befor ich da allerdings ein bisschen in die Richtung experimentieren will,
warte ich noch auf das ddhcp, was aktuell in c implementiert wurde und
noch ein wenig zeit zur reife braucht. ddhcp ist ein dezentraler dhcp
der auf den freifunk Routern laufen würde, so das auch v4 Problemlos in
offline Netzen zur Verfügung stehen könnte.
vg
Tarek
Hallo zusammen,
Ulf und Ich haben gerade zusammengesessen und die erste Planung für unseren Hackaton 2016 gemacht.
Das Rahmenprogramm haben wir schon mal in Text gegossen.
https://pad.freifunk.net/p/ffnw-hackaton-2016
Unsere Liste mit den Arbeitspunkten ist hier, bei Bedarf gerne ergänzen
https://git.nordwest.freifunk.net/ffnw/Hackaton2016/issues
Wir beiden haben uns geeinigt, das ich Hauptansprechpartner für das Wochenende bin. Bei fragen einfach bei mir melden!
Es wäre super wenn sicher jeder einträgt der an diesem Wochenende in irgendeiner Weise mitmachen und teilnehmen möchte, damit wir die nötigen Einkäufe kalkulieren können.
In diesem Sinne auf ein glorreiches und Produktives Wochenende
Ulf & Johannes
Hi,
Das gitlab CI ist nun für die nighly builds fertig eingerichtet.
Nun werden u.a. alle images automatisch hier abgelegt:
http://runner02.ffnw.de/nightly/master/
Der CI code ist nun so hingehend abstrahiert das dieser weniger von bestimmten Daten abhängt ist.
vg
Tarek
Hi,
ich hab heute eine sehr rudimentäre mesh on lan / wan management implementiert.
Das ist z.Z. nicht wirklich anders lösbar, da die network conf in gluon dringend
mal von Grund auf neu strukturiert werden muss. Dazu besteht ein eigener milestone
im upstream. Das ist so komplex das ich mich die letzten 3 Tage nur mit den networkconf
foo und möglichen lösungen beschäftig habe..
Aktuell ist es so das via respondd md5hashes der aktuell gesetzten hoods erstellt werden.
Zudem stehen in der section hoodselector auch noch infos wie boolean "vpnrouter",
current_bssid und hoodname.
Für das mesh on lan / wan management wird z.Z. nur die hashes verglichen. ist ein hash ungleich zum
eigenen wird das mesh on lan wan abgeschaltet...
Es fehlt in gluon leider noch ein flag das mesh on lan oder wan zwingen aus sein soll so das es aktuell
immer an ist, bzw. nur aus bei einer Kollision.
Ist eine Kollision fest gestellt worden so wird mesh on lan/wan abgeschalten beim nächsten aufruf den
hoodselectors wird diesen aber wieder eingeschaltet da keine kolision mehr ermittelt werden kann (flip flop)
beim nächsten Aufruf dann wieder aus usw...
Es gibt zwei Möglichkeiten die ich mir überlegt habe.
Die erste wäre die grundlegende überarbeitung der gesamten network conf von gluon was bestimmt einige Wochen
mit mehren Leuten Arbeit ist. Zudem wir da leute bräuchten die sich verdammt gut mit network foo
auskennen müssen.
Neoraider hatt die issues dazu nict umsonst in ein eigenen milestone gepackt :D
https://github.com/freifunk-gluon/gluon/issues?q=is%3Aopen+is%3Aissue+miles…
Die zweite Möglichkeit wäre VXLAN das ist relativ neu und es existiert noch so gut wie garkeine doku dazu
Dazu könnte man ein LEDE-Paket bauen, das VXLAN-Support in netifd einbaut, z.b. als Script in /lib/netifd/proto
die zweite Variante hätte wahrscheinlich eh zu folge das die network conf umfangreicher angepackt werden muss.
Aktuell arbeite ich gerade an der abstraktion der geoposition der router. Dazu wird der config mode wohl so
angepasst, das es ein flag share location geben wird und ein dropdown menü wo man folgendes auswählen kann:
autolocation
staticlocation
auto & staticlocation
(no location)
Beim letzten Punkt bin ich mir noch nicht sicher evtl. würde ich da einen Text hinsetzen das diese Option
signifikante Nachteile auf die lokale Netzqualität haben kann.
cheers
Tarek