Demnach war n leer, und n war das Ergebnis von exec gluon-neighbour-info -d ::1 -p 1001 -t 1 -c 1 -r nodeinfo
… Wie hast Du das geschafft?
Tja, und bis 1.0.0~116 (und 1.1.1~6) einschließlich fehlte das auch in dieser
Nun ist’s aber drin:
OS: 17.01-SNAPSHOT, r3981+104-184fe1 FW: 1.0.0~117
HW: TP-Link TL-WR841N/ND v8
root@33332-FWTest-a0f3c1058b90:~# iw help 2>&1 | grep connect
dev <devname> connect [-w] <SSID> [<freq in MHz>] [<bssid>] [key 0:abcde d:1:6162636465]
With -w, wait for the connect to finish or fail.
dev <devname> disconnect
Disconnect from the current network.
Set connection quality monitor RSSI threshold.
Ebenfalls drin ist nun auch das entspechende Package — das fehlte leider auch, da nicht commited
root@33332-FWTest-a0f3c1058b90:~# echo /etc/config/autoupdater*
/etc/config/autoupdater /etc/config/autoupdater-wifi-fallback
Ich brauch’ Urlaub!
Guten Morgen Kai. Nicht bewusst dass ich etwas außerhalb der normalen Nutzung gemacht hätte
Und ja, danke noch einmal für die viele Arbeit in der Freizeit in den letzten Wochen! Jetzt bin ich am Montag leider doch nicht dabei (München und so), gebe dir aber das nächste mal ein Bier aus.
Das ist nicht ganz korrekt, “master” (pre-Gluon v2018.2/FW 1.1.0, und Gluon v2018.2/FW 1.1.1) hatten das “iw connect”-Feature nicht mehr rausgepatched; aber das autoupdater-wifi-fallback-Package fehlte dennoch:
OS: 18.06-SNAPSHOT, r7204+7-8be3af9 FW: 1.1.0~14
HW: AVM FRITZ!Box 4040
root@33332-FB4040-Test-S107-c3a7:~# iw help 2>&1 | grep connect
dev <devname> connect [-w] <SSID> [<freq in MHz>] [<bssid>] [key 0:abcde d:1:6162636465] [mfp:req/opt/no]
With -w, wait for the connect to finish or fail.
dev <devname> disconnect
Disconnect from the current network.
root@33332-FB4040-Test-S107-c3a7:~# echo /etc/config/autoupdater*
/etc/config/autoupdater
Nice (not): Es war noch ein Bug im tecff-autoupdater-wifi-fallback-Paket, es wurde [gluon.]util.readfile() verwendet, diese Funktion gibt’s aber weder in Gluon v2017.x noch v2018.x. Somit wurde der Cron-Job für den WiFi-Fallback-Autoupdater nicht installiert, wodurch diese Funktionalität weiterhin nicht verfügbar war. Fixed ab 1.0.0~120 (baut gerade)/1.1.1~10 (baut gerade).
Zu früh gefreut:
root@33330-mail-de-AVM4020-test:~# /lib/gluon/upgrade/510-autoupdater-wifi-fallb
ack
/usr/bin/lua: /lib/gluon/upgrade/510-autoupdater-wifi-fallback:4: module ‘nixio.fs’ not found:
no field package.preload[‘nixio.fs’]
…
==> 1.1.1~10 ist auch noch broken
Success! FW 1.0.0~123 hat sich offline (ohne Kontakt zum Mesh) auf 1.0.0~124 aktualisiert (und dazu als Client ins Netz eingeklinkt):
Dauerte länger als geplant, aber es klappte, yeah!
Aktuell läuft nun der Test mit 1.1.1~14 (http://map.4830.org/ffgt/#!v:m;n:444e6d0fba4f), die 4020 sollte sich auf die ohne Codeänderungen gebaute, faktisch also zu 1.1.1~14 identische, Version 1.1.1~15 aktualisieren, während sie selbst offline ist (mesh-only-Knoten mit manuell veränderter /etc/config/wireless
, sodaß kein Meshing möglich ist und ein Update nur als Client funktioniert).
Release, ick hör’ Dir trapsen!
Wenn ich soll, würde ich es auch testen. Muss dann nur meinen 841v9 Knoten händisch auf 1.0.0~123 aktualisieren.
@wusel wie schaffe ich das Firmware Update direkt auf die ältere Version?
Moin,
cd /tmp; wget http://firmware.4830.org/.../gluon...1.0.0~123… ; sysupgrade -v gluon-…
Aus’m Kopf, aber sollte klappen. IIRC prüft nur der autoupater die Versionssummern, sysupgrade macht up- oder downgrade.
Ciao,
-kai
Wie lang brauch er, bis er sich als Client ins Netz einwählt?
OS: 17.01-SNAPSHOT, r3981+104-184fe1 FW: 1.0.0~123
HW: TP-Link TL-WR841N/ND v9
root@50767-TEST-TEST:~#
123er Firmware ist instaliert. Auf meinen Hauptknoten ist das Mesh deaktiviert und es läuft nur noch das Client WLAN.
3 Stunden:
local offset = 2 * 3600
local unreachable_since = os.time()
if not uci:get('autoupdater-wifi-fallback', 'settings', 'unreachable_since') then
uci:set(configname, 'settings', 'unreachable_since', unreachable_since)
else
uci:set(configname, 'settings', 'last_run', unreachable_since)
unreachable_since = uci:get(configname, 'settings', 'unreachable_since')
end
uci:save(configname)
if force or tonumber(unreachable_since) + offset < os.time() then
io.popen(‘logger -s -t autoupdater-wifi-fallback -p local0.info “going to fallback mode”’)
Mission erfolgreich abgeschlossen
OS: 17.01-SNAPSHOT, r3981+104-184fe1 FW: 1.0.0~124
HW: TP-Link TL-WR841N/ND v9
root@50767-TEST-TEST:~#
Siehe Peak gegen 0:30
Danke für die Rückmeldung: 1.0.0~124 ist als “testing”-Firmware aktiviert.
ffgt@colosses:~/jenkins_data/build$ ./protomote-to.sh 1.0.0~124 testing
Promoting firmware 1.0.0~124 to branch testing ...
Done.
Cool, die 1er Firmware rollt aus.
Was mir nur aufgefallen ist einige Knoten werden falschen Sites zu geordnet. Unter anderem auch
33397-Lu-Hollenbeck-1
er ist Gütersloh(Stadt) zugeordnet. Müsste aber eigentlich Gütersloh(Kreis) zu geordnet sein, Richtig?
Soll ich da etwas nach schauen auf dem Knoten?
Nein, das Cleanup kommt nach dem Rollout der 1.0; da ist das Package ffda-domain-director (entwickelt von den Kollegen aus Darmstadt) drin, welches periodisch unseren setup.4830.org-Server mit der MAC-Adresse und den hinterlegten Koordinaten kontaktiert und die Regions-, faktisch Firmware-, Zuordnung zurückerwartet. Die Serverseite ist noch nicht scharf geschaltet, das kommt dieser Tage mit ausgewählten Knoten (per MAC-Whitelist von “experimental”- und “testing”-Knoten).
Details siehe Blogpost
Mein deaktiverter autoupdate Knoten ist nun auch auf die 125 gebracht.
Das private Wifi hat den Flashvorgang überstanden, die “gelbe Port” Thematik nicht. Aber das war bekannt. Dient also nur zur Info.
Danke und Gruß
René
Und weiteres Feedback. Ich habe ja die Lan Ports anstelle des FF Netzes im Router anliegen. Daran ist mein Wechselrichter angeschlossen. Seit dem Update von Gestern Abend hat er die Verbindung aufrecht gehalten.
Mit der Version davor hat er alle paar Stunden (teilweise Minuten) die Verbindung verloren und neu aufgebaut (laut seinem Protokoll).
Es ist also “much better” geworden
Danke.
Puh. Danke für die Rückmeldung, und so schön es sein mag, wenn es bei Dir nun besser tut: Verbesserungen auf LAN-Seite wurden bislang eher nicht kommuniziert
Kommando zurück, die Reconnects sind wieder da. Ich hoffe einfach mal auf die 4040. Wird schon werden.