- Dev - Freifunk Nordwest

nach dem update ist vor dem update
by lrnzo 11 Sep '17

11 Sep '17

root@FF-IBB-STADT-Offloader04:~# cat /tmp/hoodselector_error Command failed: Request timed out /usr/bin/lua: /usr/sbin/hoodselector:709: attempt to index local 'e' (a nil value) stack traceback: /usr/sbin/hoodselector:709: in function 'g' /usr/sbin/hoodselector:860: in main chunk [C]: ?

3 5

fastd stündlicher session reset
by Jan-Tarek Butt 10 Sep '17

10 Sep '17

Hi, ich hab gerade eine Mail erhalten mit einem Log Auszug von einem Router: https://picload.org/view/dgrgraai/massentunnel.png.html Die Netmon node Client Massages sind bereits hier geklärt: https://git.ffnw.de/netmon-sc/node-client/issues/5 Allerdings die fastd Session Resets kann ich mir nicht erklären. Gab es Serverseitig in den letzten Wochen evtl. Änderung an fastd? Denn Routerseitig wurde fastd nicht angepackt? schöne grüße Tarek

1 0

LEDE und MR3020
by Bjoern Franke 05 Sep '17

05 Sep '17

Moin, ich bin seit geraumer Zeit aus der Firmwarentwicklung raus und nun wollte ich für einen MR3020(v1) mal ein LEDE-Image bauen. Normale Images für den Router gibt es ja, doch recht schnell auch Platzprobleme, sodass ich diverse Pakete direkt in das Image backen wollte. Merkwürdigerweise purzelt aber für den MR3020 am Ende kein Image raus, aber für viele andere AR71xx-Geräte. Gibt's für den MR3020 irgendwas zu beachten? Grüße bjo

2 3

Re: [Dev] [Nordwest] Firmware 20170629
by Jan-Tarek Butt 18 Aug '17

18 Aug '17

Hi, > ich habe ma einen neuen branch gemacht für das nächste update: > > https://git.ffnw.de/ffnw-firmware/siteconf/commit/88dd11323ba571dd30688724a… <https://git.ffnw.de/ffnw-firmware/siteconf/commit/88dd11323ba571dd30688724a…> > > dort habe ich den Ordner für den stable link mal angepasst. > > Alle Router schauen jetzt in das Verzeichnis > > autoupdate.ffnw/stable > > das könnten wir so lassen Ich lösche das noch mal. Wir sollten das erstmal besprechen befor wir da potentiell unnötie branchs und co aufmachen. > nach dem nächsten update mit gluon 2016.2.6 ändern wir den zukünftigen stable und testing Ordner auf: > > autoupdate.ffnw/stablelede2017 > autoupdate.ffnw/testinglede2017 > > der Branch wäre dann immer noch „stable“ bzw „testing“ > > das erste update mit Gluon 2017.x.x kommt dann in den Ordner „stablelede2017“ > > alle alten router die dann noch mal online kommen würden dann mit dem autoupdater erst unsere letzte Gluon 2016.2.6 Firmware laden und installieren und danach auf lede wechseln. > > Irgendwann können wir dann wieder aus stablelede2017 wieder stable machen > > Was haltet ihr von dem Vorschlag? Wir könnten es wahrscheinlich einfacher machen. Wir lassen autoupdate.ffnw/stable auf den 201707** (v2016.2.x) Ordner zeigen. ab der Version 201707** (v2016.2.x) zeigt die autoupdater url z.b. auf autoupdate<anhängsel>.ffnw/stable vg Tarek

3 5

watchdog für festgefahrenen hoodselector
by lrnzo 18 Aug '17

18 Aug '17

Hallo Leute, sobald der hoodselector einmal nicht terminiert hat, kann er nicht wieder ausgeführt werden, weil er seine eigene pid-file (/var/run/hoodselector.pid) nicht gelöscht hat. Folgender Einzeiler löscht diese Datei, falls sie älter als 300 sekunden = (5 minuten) ist. if [ $(($(date +%s) - $(date +%s -r "/var/run/hoodselector.pid"))) -gt 300 ];then rm /var/run/hoodselector.pid;fi könnte das vielleicht als watchdog/cronjob in die nächste firmware mit rein? wäre schon sehr praktisch. PS. ich teste das jetzt mal auf paar routern LG lrnzo

3 14

Router kommt nicht wieder online. debugging trotzdem möglich :)
by lrnzo 17 Aug '17

17 Aug '17

Hallo Leute, heute morgen wollte ein Kabelmeshrouter nach automatischem Reboot nicht wieder online kommen, aber ich konnte noch per link-local rauf und habe mal ein wenig herumprobiert. Noch ist er nicht wieder online, aber ich dachte mir, die Ausgaben könnten fürs Firmware-debugging interessant sein. Deshalb hier: ---------------------------8<--------------------------- root@FF-Bad-Iburg-Pfarrheim-Glane-01:~# hoodselector No VPN connection found Testing neighboring adhoc networks for batman advanced gw connection. The following wireless networks have been found: 73 2437 02:00:0a:12:58:00 mesh.ffnw After filtering we will test the following wireless networks: No neighboring freifunk batman advanced mesh found. Command failed: Request timed out Failed to parse json data: unexpected end of data currend configuration are not defined as hood VPN stopped. Command failed: Request timed out Command failed: Request timed out Command failed: Request timed out Wireless restarted. IBSS needed reconfiguration. Applied new settings and restarted. Command failed: Request timed out Command failed: Request timed out Command failed: Request timed out Wireless restarted. MESH needed reconfiguration. Applied new settings and restarted. Fastd needed reconfiguration. Stopped and applied new settings. VPN enable. VPN started. Interface br-client restarted. VPN needed reconfiguration. Applied new settings and restarted. Set hood "default" Set defaulthood. Command failed: Request timed out Failed to parse json data: unexpected end of data Command failed: Request timed out /usr/bin/lua: /usr/sbin/hoodselector:132: attempt to index local 'e' (a nil value) stack traceback: /usr/sbin/hoodselector:132: in function 'r' /usr/sbin/hoodselector:205: in function 'h' /usr/sbin/hoodselector:938: in main chunk [C]: ? --------------------------->8--------------------------- im logread steht nur alle paar Minuten: ---------------------------8<--------------------------- Thu Aug 3 16:42:24 2017 kern.emerg kernel: [23206.120000] unregister_netdevice: waiting for bat0 to become free. Usage count = 4 Thu Aug 3 16:42:24 2017 kern.emerg kernel: [23206.380000] unregister_netdevice: waiting for primary0 to become free. Usage count = 1 Thu Aug 3 16:42:24 2017 kern.emerg kernel: [23206.640000] unregister_netdevice: waiting for local-node to become free. Usage count = 1 --------------------------->8--------------------------- die systemzeit ist offensichtlich falsch, aber das liegt sicherlich an der Nichterreichbarkeit jeglicher ntp-server. Ich werde ihn bis 18 Uhr erstmal nicht rebooten, sondern warten, ob jemand eine Idee hat, welche Ausgaben außerdem aufschlussreich sein könnten. Die /tmp/hoodselector_error war übrigens leer LG Lorenz

2 3

Sign Request 20170629
by Johannes Rudolph 16 Aug '17

16 Aug '17

Hi, Ich habe heute eine neue Firmware gebaut. Basisdaten: * Firmware-Version: 20170629 * Gluon-Version: 2016.2.6 * Download: https://firmware.ffnw.de/20170629 Folgende Änderungen gab es: * siteconf Repo: * für x86 add kmod-usb-net-mcs7830 * drop libwlocate * drop lwtrace * packages Repo: * Hoods: * Osnabrueck -> Osnabrueck1 und Osnabrueck2 * Oldenburg -> Oldenburg1 und Oldenburg2 * Leer Emden Aurich -> Leer und Aurich * Butjadingen -> Butjadingen und Tossens * Hoodselector: * fix filter own Network * fix filter default Hood Die Änderungen an der Siteconf können im Siteconf-Repo mittels folgendem Befehl eingesehen werden: https://git.ffnw.de/ffnw-firmware/siteconf/compare/20170530...201706 Die Änderungen an unseren eigenen Paketen können im Packages-Repository mittels folgendem Befehl eingesehen werden: https://git.ffnw.de/ffnw-firmware/packages/compare/201705...201706 Ich bitte euch die Änderungen zu prüfen und die Firmware im Anschluss zu signieren. Die Dokumentation zum Signaturprozess findet ihr im Wiki unter: https://wiki.nordwest.freifunk.net/Entwicklung/Firmware_releaseprozess#Firm… Viele Grüße Johannes

7 25

Fwd: [ff-firmware-devel] [ANNOUNCE] Gluon v2016.2.7 and v2017.1.2
by Jan-Tarek Butt 16 Aug '17

16 Aug '17

FYI -------- Forwarded Message -------- Subject: [ff-firmware-devel] [ANNOUNCE] Gluon v2016.2.7 and v2017.1.2 Date: Mon, 14 Aug 2017 02:25:29 +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> We have just released two new maintenance releases of Gluon: the (hopefully) last release of the v2016.2.x series, and a new v2017.1.x update. The extensive changes to the sysupgrade procedure introduced in v2016.2.6 introduced a regression that could cause nodes to hang during upgrades, requiring manual power cycling. This issue has been fixed; instead, a reboot is triggered when the upgrade can't proceed. v2017.1.2 fixes the same issue for the v2017.1.x branch, together with a few minor feature additions and other bugfixes. For a more detailed list of changes please refer to the full release notes: http://gluon.readthedocs.io/en/v2016.2.x/releases/v2016.2.7.html http://gluon.readthedocs.io/en/v2017.1.x/releases/v2017.1.2.html -- NeoRaider -- firmware-devel mailing list firmware-devel(a)freifunk.net http://lists.freifunk.net/mailman/listinfo/firmware-devel-freifunk.net

1 0

fastd.mesh_vpn.method
by lrnzo 27 Jul '17

27 Jul '17

Hallo Leute, mittlerweile ist ja in der firmware fastd.mesh_vpn.method='null' 'salsa2012+umac' gesetzt und alle supernodes können die Methoden method "salsa2012+umac"; method "null+salsa2012+umac"; method "null"; soweitsogut. Aber effektiv bauen alle uplinks ihren fastd-tunnel immer über die (langsamere) Methode salsa2012+umac auf. Es sei denn man schmeißt diese Methode routerseitig zB per uci raus. Letzteres habe ich jetzt updatefest auf vielen routern getan: uci del_list fastd.mesh_vpn.method='salsa2012+umac';uci del_list fastd.mesh_vpn.method='null';uci add_list fastd.mesh_vpn.method='null';uci commit fastd; echo '/etc/config/fastd' >> /etc/sysupgrade.conf;/etc/init.d/fastd restart aber was sollen Leute machen, die "nur" den configmodus nutzen? Habe mich gefragt, ob man nicht in den wizzard bei der vpn-config ein Menü tun könnte so nach der Motto "schnelles oder extra-verschlüsseltes vpn". Also solange wir noch kein l2tp haben. LG Lorenz

3 2

Vorschlag für nightly autoupdater branche
by Jan-Tarek Butt 06 Jul '17

06 Jul '17

Hi zusammen, Clemens hatte vor einiger Zeit mal den nigthly autoupdater branche im siteconf repo angelegt. Ich habe gestern testweise mal den nigthly CI in das packages repo eingebaut. Langfristig würde ich mir wünschen den nigthly CI in dem packages repo zu lassen. Das ermöglicht bsp. das Änderungen die in den Master gemerged wurde automatisch Auf die Router installiert werden die auf dem nigthly branch zeigen. Somit können Entwickler relativ einfach neue Änderungen von anderen Entwicklern testen und auf bestehenden Änderungen entwickeln. Ein nigthly branche im siteconf repo ist nicht wirklich hilfreich. Da dieses relativ selten, meist zur Zeit eines releases geädert wird. vg Tarek

2 2