September 2016 - Dev - Freifunk Nordwest

Hackaton 2016 - Organisation
by Johannes Rudolph 11 Sep '16

11 Sep '16

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

1 0

[patch master v3] fix patching error by empty build_patches dir
by Jan-Tarek Butt 10 Sep '16

10 Sep '16

--- buildscript | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/buildscript b/buildscript index 04942e6..1474966 100755 --- a/buildscript +++ b/buildscript @@ -122,9 +122,11 @@ get_source() { } patch_target() { - for patch in "$PWD"/build_patches/openwrt/*.patch; do - patch --no-backup-if-mismatch -p0 -d "$target" -i "$patch" - done + if [ $(find $PWD/build_patches/openwrt/*.patch 2> /dev/null | wc -l) -ge 1 ]; then + for patch in "$PWD"/build_patches/openwrt/*.patch; do + patch --no-backup-if-mismatch -p0 -d "$target" -i "$patch" + done + fi } prepare() { -- 2.9.3

2 5

[patch master v2] fix patching error by emty build_patches dir
by Jan-Tarek Butt 10 Sep '16

10 Sep '16

--- buildscript | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/buildscript b/buildscript index 04942e6..43997bf 100755 --- a/buildscript +++ b/buildscript @@ -122,9 +122,11 @@ get_source() { } patch_target() { - for patch in "$PWD"/build_patches/openwrt/*.patch; do - patch --no-backup-if-mismatch -p0 -d "$target" -i "$patch" - done + if (( `ls $PWD/build_patches/openwrt/*.patch 2> /dev/null | wc -l` )); then + for patch in "$PWD"/build_patches/openwrt/*.patch; do + patch --no-backup-if-mismatch -p0 -d "$target" -i "$patch" + done + fi } prepare() { -- 2.9.3

2 1

firmwares
by Jan-Tarek Butt 10 Sep '16

10 Sep '16

Hi, ich hab gerade noch mal ne testing firmware gebaut. http://firmware.ffnw.de/testing/ zudem wird nun auch der symlink in nightly erstellen, damit die router auch wirklich updaten können ;P http://firmware.ffnw.de/nightly Der symlink für die aktuelle stable existierte auch nicht. Hab das mal gefix. http://firmware.ffnw.de/stable/ vg Tarek

1 0

[Fwd: [WLANware] [ANNOUNCE] Gluon v2016.1.6]
by Bjoern Franke 07 Sep '16

07 Sep '16

1 0

gitlab-CI
by Jan-Tarek Butt 07 Sep '16

07 Sep '16

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

1 0

Status v1.2
by Jan-Tarek Butt 04 Sep '16

04 Sep '16

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

2 1

issue #61 Hoodselector generates high loads
by Jan-Tarek Butt 02 Sep '16

02 Sep '16

Hi, kann jemand zu dem issue sagen wo genau das problem ist? bzw. wann der hoodselector eine hohe load erzeugt ? vg Tarek

1 0

VPN managemend
by Jan-Tarek Butt 01 Sep '16

01 Sep '16

Hi zusammen, Mir ist gerade eine Idee gekommen die ich hier mal vorstellen und diskutieren wollte. Es kommt ja hin und wieder mal vor das Router Betreiber mehrere VPN Router am selben DSL Anschluss betreiben. Mir ist nicht ersichtlich in wie fern das sinnvoll sein könnte. Im Gegenteil die ohne hin in den meisten fällen knappe Bandbreite an einem DSL Anschluss wird somit durch 2 VPN Verbindungen belastet. Zusätzlich werden auch die peer slots serverseitig blockiert. Nun zu der Idee. Die Router tauschen sich local über deren interfaces miteinander aus (lan,wan,wifi). Als Protokoll könnte man respondd nutzen. Sobald zwei router die local mit einander meshen und auch einen VPN über die identische leitung haben, schaltet einer der beiden den fastd ab. Das Ergebnis wären keine redundanten fastd Verbindungen mehr über identische DSL Anschlüsse. Bewerkstelligen könnte man das indem man prüft ob die Router eine identischen fastd config haben. Da habe ich gerade was in respondd fertig gemacht das md5 hashes von aktuell gesetzen hoods bereitstellt. Die Prüfung ob es sich um den selben Anschluss handelt könnte über die Ermittlung der externe IP geschehen. Da müsste v4 v6 berücksichtigt werden. was halten ihr davon? Hab ich evtl. was essenzielles übersehen warum das eine blöde Idee sein könnte? Wehr hat Lust und zeit das zu implementieren? :) schönen Gruß Tarek

6 8