Regio Aachen 2019.1-1 Release

Wir bereiten den Rollout der stable Firmware auf Gluon 2019.1 Basis vor.

Für die meisten Geräte geht dies direkt, für die TP-Link CPE und WBS, sowie für x86 Geräte wird es zwei Updates direkt hintereinander geben, das sieht dann so aus:


Die Änderungen sind hier dokumentiert:
https://wiki.freifunk.net/Freifunk_Aachen/Firmware#Beta
https://wiki.freifunk.net/Freifunk_Aachen/Firmware#Stable

Am auffälligsten dürfte sein, dass die Geräte nun einmal die Woche in der [Nacht von Mittwoch auf Donnerstag neubooten](http://Nacht von Mittwoch auf Donnerstag neubooten). Außerdem haben wir für die Geräte mit sehr wenig RAM die Verwendung von komprimierung mittels zRAM-Swap hinzugefügt.

Bis wir das Autoupdate in run zwei Wochen freischalten, benötigen wir noch Feedback. So könnt ihr uns helfen und das Autoupdate schon jetzt per Konsole installieren:

uci set autoupdater.stable.good_signatures='1'
autoupdater --branch stable --force

Bequem auf die Konsole geht es mit dem DNS Namen des Knoten

edit:

Damit x86 VMs das Autoupdate bis zur aktuellen Version schaffen, muss das Image vergrößert werden, mit KVM/qemu geht dies so:

qemu-img resize <image-name>.img 273M

273MB ist die mindest Größe, die nun erforderlich ist.

läuft

http://ffac-hechelscheid-01.dyndns.m120.de/cgi-bin/status

THXX

Der hat aber eine hohe load, weit mehr als alle anderen:
https://grafana.ffac.rocks/d/IzGArz3iz/info-by-firmware-version?orgId=1&var-firmware_release=2019.1-1-beta&var-firmware_release=2019.1-1-stable&var-firmware_release=2019.1-1~exp20191122

Kannst du dir das erklären? Kannst du mir die logread und dmesg zukommen lassen? Wird sie nach dem Kommando wifi besser?

Da geht jetzt auch:
http://ffac-Hechelscheid-01.nodes.ffac.rocks

habe heute noch mal geschaut …

Auffällig ist das es lange dauert ehe der fastd eine Verbindung hat (meist > 5 Minuten)
dann gibt es ein paar Fehlermeldungen

Sat Nov 30 21:04:52 2019 daemon.info fastd[2370]: received handshake response from <mesh_vpn_backbone_peer_aachen06>[5.145.135.136:30806] using fastd v18
Sat Nov 30 21:04:53 2019 daemon.info fastd[2370]: 5.145.135.136:30806 authorized as <mesh_vpn_backbone_peer_aachen06>
Sat Nov 30 21:04:53 2019 daemon.notice fastd[2370]: connection with <mesh_vpn_backbone_peer_aachen06> established.
Sat Nov 30 21:04:53 2019 daemon.info fastd[2370]: new session with <mesh_vpn_backbone_peer_aachen06> established using method `salsa2012+umac'.
Sat Nov 30 21:04:55 2019 daemon.err gluon-radv-filterd[1431]: Unable to find router ac:c0:1d:08:ff:01 in transtable_{global,local}
Sat Nov 30 21:04:55 2019 daemon.err gluon-radv-filterd[1431]: Switching to ac:c0:1d:08:ff:01 (TQ=0)
Sat Nov 30 21:04:56 2019 daemon.info dnsmasq[764]: reading /tmp/resolv.conf.auto
Sat Nov 30 21:04:56 2019 daemon.info dnsmasq[764]: using local addresses only for domain lan
Sat Nov 30 21:04:56 2019 daemon.info dnsmasq[764]: using nameserver 2a03:2260:114::2#53
Sat Nov 30 21:04:56 2019 daemon.info dnsmasq[764]: using nameserver 2a03:2260:114::4#53
Sat Nov 30 21:04:57 2019 user.notice firewall: Reloading firewall due to ifupdate of client (br-client)
Sat Nov 30 21:04:57 2019 daemon.warn fastd[2370]: sendmsg: Operation not permitted
Sat Nov 30 21:04:57 2019 daemon.warn fastd[2370]: sendmsg: Operation not permitted
Sat Nov 30 21:06:01 2019 user.notice gluon-ssid-changer: SSID is FF_Offline_ffac-Hec...cheid-01, change to Freifunk

und dann ist alles gut.

Der fastd hat die hohe Last verursacht.
Habe nun mal die Verschlüsselung ab geschaltet (‚null‘) und nun sieht es besser aus.
Hinter dem schwachen „TP-Link TL-WR841N/ND v9“ hängen noch ein paar andere Router im Mesh.
Das schaffte der auch schon vorher nicht gut wenn die Verschlüsselung an war.

Stimmt, schaut nun deutlich besser aus, da die meisten anderen 841er kein vpn machen müssen erscheint das auch plausibel.

Es sind nun die 4 benötigten Signaturen zusammen (1* buildserver, 3* persönlich):


Damit werden nun über die kommenden 14 Tage die gut 1.800 Knoten mit aktivem stable Autoupdate die neue Firmware beziehen.