May 2016 - Dev - Freifunk Nordwest

Lösung des Hood vs. Kabelmesh Problems
by Simon Kurka 19 Jul '16

19 Jul '16

Hallöle, mir kam gerade ein Gedanke, der uns evtl. relativ einfach beim Problem des Kabelmeshes in der Hoodauswahl hilft. Ich habe es noch nicht zu Ende gedacht!! Stichwort VLAN. Wie wäre es, wenn wir jeder Hood eine VLAN ID zuweisen, die im Kabelmesh verwendet wird? Es wäre auf jeden Fall sichergestellt, dass Router in unterschiedlichen Hoods diese nicht per Kabelmesh verbinden. Was wir nicht unmittelbar dadurch erreichen, ist, dass ein Kabelmesh sich in der Hoodauswahl als Einheit verhält. Auf VLAN 0 könnte man Meta-Daten austauschen, entweder um a) das einheitliche Verhalten des Kabelmeshes sicherzustellen b) ein Layer 3 Routing durch das Kabelmesh zu fahren, z. B. indem die betreffenden Nodes am OSPF Verkehr teilnehmen, o. Ä. Die VLAN-Trennung könnte uns schon jetzt Sicherheit vor Verbinden zweier Hoods bringen, ohne das Kabelmesh gänzlich abzuschalten. Ansonsten, wie gesagt, nur ein kurzer Gedankenblitz, den ich sehr reizvoll finde :) -- Viele Grüße, Simon

7 10

Sign Request 1.0
by Johannes Rudolph 18 Jun '16

18 Jun '16

Ich habe heute eine neue Firmware gebaut. Basisdaten: * Firmware-Version: 1.0 * Gluon-Version: v2016.1.x * Commit ID: f6b390ca332de38f01cb8c645d383ddfca31f82b * Download: http://firmware.ffnw.de/1.0 Folgende upstream Änderungen gab es: ar71xx-generic OpenMesh MR600 (v1, v2) MR900 (v1, v2) OM2P (v1, v2) OM2P-HS (v1, v2) OM2P-LC OM5P OM5P-AN Ubiquiti Rocket M XW TP-LINK TL-WR841N/ND v11 Bugfixes build: fix race condition caused by using certain make targets (like clean, images or package/*) with parallel build options without doing a full build before build: fix package dependency issue causing “recursive dependency” warning This dependency issue could lead to broken configurations and reportedly caused failed builds in some cases when additional (site-specific) packages were used. build: Gluon will now build correctly with GCC 6 as host compiler Fix configuration of batman-adv when VLANs are used on top of IBSS interfaces (regression due to netifd update in Gluon 2016.1.4) Add back missing ath10k firmware (regression due to mac80211 update in Gluon 2016.1.4) Gluon can now be used on all supported Ubiquiti AirMAX devices without downgrading to AirOS 5.5.x before Gluon 2016.1.1 added support for most Ubiquiti AirMAX devices with AirOS 5.6.x without downgrading AirOS, but left some devices (at least some PicoStations and Bullets) with unwritable flash. This issue has been resolved (#687). Add upgrade script to automatically remove whitespace from configured geolocation The new respondd implementation included in Gluon 2016.1 is stricter about the number format than the old one and doesn’t accept trailing whitespace (so one or both coordinates are missing from the output). The Config Mode has been fixed to strip whitespace from numeric fields in new configurations since Gluon 2016.1.1. This still left old configurations, which are now fixed by this script. Folgende Comunnity speziffischen Änderungen gab es: * Add hood lk-os to hoodfile * Add hood ol to hoodfile * Add hood lk-fri to hoodfile * Add hood lk-st to hoodfile * bugfix hoodselector restart bridge interface * bugfix hoodselector wrong characters inside UCI Section-Namen Die Änderungen an der Siteconf können im Siteconf-Repo mittels folgendem Befehl eingesehen werden: git diff v1.0 v0.9 Die Änderungen an unseren eigenen Paketen können im Packages-Repository mittels folgendem Befehl eingesehen werden: git diff v1.0 v0.9 Viele Grüße Johannes

4 5

hoodselector: falsch positives Ergebnis bei function directVPN() ?
by lrnzo 02 Jun '16

02 Jun '16

Hallo, wenn ich das richtig verstehe, guck die funktion ja in originator-table und gibt true zurück, wenn sie irgendwo den string mesh-vpn findet. Aber wird auch der Wert last-seen berücksichtigt? beispiel: Knoten hat vpn verbindung, der letzte originator-frame ist keine 5 sekunden alt. directVPN() -> TRUE. alles io. jetzt verliert der knoten aus $gründen seine vpn verbindung, aber in der orignator-table werden immer noch massenweise zeilen gefunden, die den string mesh_vpn enthalten, aber natürlich nur zombies sind. directVPN() -> TRUE, obwohl vpn in Wahrheit tot ist. Oder ist das alles viel einfacher? lg lrnzo

2 1

gitlab-CI
by Jan-Tarek Butt 31 May '16

31 May '16

Hi, das Gitlab ist nun auf dem aktuellen stabile release (8.8.2). Zudem ist in der git VM das git auf 2.8.3 from source aktualisiert. Ein sehr nützliches feature was hinzugekommen ist, ist das man nun die build logs im RAW output kriegen kann[0]. Das ist für Fehler Analysen sehr hilfreich. Hinzu kommt das nun die Architekturen von gluon aus dem soruce generiert werden. Somit werden die Targets dynamisch gebaut. Kommen also neue Architekturen hinzu selektiert der CI bot diese automatisch. Zuvor hatte der bot nur auf einen thread compiliert. Nun baut der CI bot ebenfalls dynamisch auf allen logischen cores[1]. nach folgender Formel: (grep -c processor /proc/cpuinfo)*2 Also Anzahl der logic cores mal zwei. Zweit Prozesse pro logik core. Referrenz[2]. Aktuell ist es noch nicht möglich mit dem make parameter V=s zu compilieren. Der generierte log output wird mehre GB groß und überbeansprucht das gitlab somit. Dazu gibt es schon ein issue in gitlab [3]. vg Tarek [0] https://git.nordwest.freifunk.net/ffnw-firmware/siteconf/builds/289/raw [1] https://git.nordwest.freifunk.net/ffnw-firmware/siteconf/builds/289 [2] https://github.com/FreifunkFranken/firmware/blob/master/buildscript#L219 [3] https://gitlab.com/gitlab-org/gitlab-ci/issues/421

1 1

Vorschlag zum 1.0 Release
by Stefan 30 May '16

30 May '16

Hi, ich habe mich gerade kurz mit Clemens über das 1.0 Release unterhalten. Ich hätte hier folgenden Vorschlag: - Ich habe nun den Ganzen Puppet Code ins Gitlab rübergezogen und fixe hier noch Kleinigkeiten - Wir testen alle die Version 1.0 heute oder morgen und signen diese schon entsprechend - Am Mittwoch würden wir ein Blogpost veröffentlichen, damit die Nutzer von dem Großen Update mitbekommen - Donnerstag im Laufe des Tages würden wir dann den Symlink umschwenken, sodass die Version verteilt wird Einwände oder weitere Vorschläge? :) Viele Grüße Stefan

1 0

Umzug der Puppet Repos und Master
by Stefan 30 May '16

30 May '16

Hey zusammen, ich mache mich ab jetzt daran die Puppet Repos ins Gitlab (sofern dies funktioniert) umzuziehen und über unseren Puppetmaster zu deployen. Dann haben wir später im Puppet Board eine Gute Übersicht, welche Systeme wie deployed wurden. VG Stefan

2 2

build ENV
by Jan-Tarek Butt 29 May '16

29 May '16

Hi, ich habe mal ein paar build ENVs auf runner02 gelöscht die in home dirs lagen und älter als 1 1/2 Monate waren. Bitte auchtet darauf wenn im home die gebaut wird sollte das build ENV hinterher aufgeräumt werden. Ansonsten verbraucht es ca. 70GB. Hintergrund ist das mir gerade aufgefallen ist das dem CI bot die platte voll gelaufen ist. vg Tarek

1 0

Gitlab: Reply via Mail
by Bjoern Franke 28 May '16

28 May '16

Moin, man kann auf die Mail-Notifications für Issues und Mergerequests unseres Gitlabs nun auch per Mail antworten. \o/ grüße bjo -- xmpp bjo(a)schafweide.org

2 1

hoodselector: br-client restart
by Johannes Rudolph 28 May '16

28 May '16

Moin wir haben festgestellt, dass das Interface br-client neu gestartet werden muss, damit der router schnellstmöglich seine alte IPv6 Adresse vergisst. Ich habe da mal einen Merge Request gemacht @Tarek kannst du dir das mal anschauen und dann hoffentlich ;) Mergen Gruß Johannes

4 7

Re: [Dev] hoodselector: br-client restart
by Stefan 27 May '16

27 May '16

Moin, in dem Hoodfile von Tarek steht wohl lk-fri01.sn.ffnw.de drin. Daher keine Verbindung. Hab diese mal angelegt - sollte nun klappen! Am 27.05.2016 um 10:49 schrieb lrnzo: > aus dem hoodfile: > > "name": "lk-fri", > "bssid": "02:00:0A:12:88:00", > "defaulthood": false, > "servers": [ > { > "host": "lk-fri-01.sn.ffnw.de", > "port": "10001", > "publickey": > "613ffbc8a5a2b1a8602866c0bd44afddecee79c49cde52ee4dd5df73c88d0437" > } > ], > "boxes": [ > [ > [ > 53.36, > 7.85 > ], > [ > 53.72, > 8.18 > ] > ] > ] > }, > > > Am 27.05.2016 um 10:47 schrieb Stefan: >> Hoi, >> >> Am 27.05.2016 um 10:46 schrieb lrnzo via Dev: >>> hat das was damit zu tun, dass er in lk-fri das entsprechende gateway >>> nicht erreiht? >> >> welche Peers sind für FRI / WHV angegeben? >> Daran wird es liegen ;) >> >> Stefan >>

2 1