Da es noch 'ne Handvoll Knoten auf dem tng-Branch gibt, werden diese nun mit der Firmware 1.4.0, basierend auf Gluon v2021.1 – der aktuellen Gluon-Version –, beglückt.
Wenn er denn mal durchbaut …
[…]
make[6]: Leaving directory '/home/ffgt/build/gluon-ffgt-v2021.1/openwrt/build_dir/toolchain-powerpc_8540_gcc-7.5.0_musl/gcc-7.5.0-final'
make[5]: *** [Makefile:895: all] Error 2
make[5]: Leaving directory '/home/ffgt/build/gluon-ffgt-v2021.1/openwrt/build_dir/toolchain-powerpc_8540_gcc-7.5.0_musl/gcc-7.5.0-final'
make[4]: *** [Makefile:88: /home/ffgt/build/gluon-ffgt-v2021.1/openwrt/build_dir/toolchain-powerpc_8540_gcc-7.5.0_musl/gcc-7.5.0-final/.built] Error 2
time: toolchain/gcc/final/compile#770.47#48.93#91.75
make[3]: *** [toolchain/Makefile:100: toolchain/gcc/final/compile] Error 1
make[2]: *** [toolchain/Makefile:96: /home/ffgt/build/gluon-ffgt-v2021.1/openwrt/staging_dir/toolchain-powerpc_8540_gcc-7.5.0_musl/stamp/.toolchain_compile] Error 2
make[1]: *** [/home/ffgt/build/gluon-ffgt-v2021.1/openwrt/include/toplevel.mk:227: world] Error 2
make: *** [Makefile:180: all] Error 2
make failed for target mpc85xx-generic with code 0, aborting build.
An error occured. Please fix. Good luck and bye-bye ;-)
real 80m11,820s
user 572m26,708s
sys 56m40,396s
EDIT: Oops, Platte voll So ein Gluon-Build verschlingt mittlerweise 110 GB …
Mit der Basis Gluon v2021.1.2 kommen auch ein paar neue Features nach tng (WPA3/OWE wurde schon in v2020.2 hinzugefügt):
WPA3 support for Private WLAN
The private WLAN now supports WPA3-SAE key exchange as well as management frame protection (802.11w). For this to work, the firmware needs to be built with the wireless-encryption-wpa3 feature.
OWE on Client Network
Gluon now allows to configure a VAP for the client network which supports opportunistic encryption on the client network for devices which support the OWE security type (also known as Enhanced Open).
This encrypted VAP can be the only available access point or be configured in addition to an unencrypted VAP. In the latter case, the transition mode can be enabled, which enables compatible devices to automatically connect to the encrypted VAP while legacy devices continue to use the unencrypted connection.
There are issues with some devices running Android 9 when connecting to a transition mode enabled network. See the site documentation for more information.
SAE Encrypted Mesh Links
Mesh links can now be operated in an encrypted mode using SAE authentication. For this to work, a common shared secret has to be distributed to all participating nodes using the site.conf.
Außerdem unterstützt unsere tng-Firmware den »Mi Router 4A Gigabit Edition«, der ggf. ein passaber Nachfolger für die 841er werden könnte, mit einem Herstellerpreis zwischen 20 und 30 Euro:
Ich hatte vor einigen Monaten bei 25 EUR zweimal zugeschlagen, d. h. erste Hnds-On-Erfahrungen werde ich wohl bald beisteuern können. Das Umflashen ist wohl eine Strafe, aber mit Geduld machbar …
Wer tng auf seinen Geräten mal ausprobieren will: autoupdater --branch tng flasht auf die aktuelle tng-Release um, ohne den Releasekanal zu ändern. (Lies: wenn einen neuerere Firware verfügbar wird, aktualisiert sich der Knoten, er zieht aber nicht jedes Interims-tng-Release …)
@wusel Du hast geschrieben, dass Du Dir zwei von den Teilen gegönnt hast. Wie ist aktuell Deine Erfahrung? Ist das immer noch eine Strafe oder läuft es tatsächlich so ab, wie im Video (verlinkt bei openWRT)?
wusel@luggage:~/Mi4AGigabit/OpenWRTInvasion$ python3 remote_command_execution_vulnerability.py
Router IP address [press enter for using the default 'miwifi.com']: 192.1192.168.31.1
Enter router admin password: 12E456!8
There two options to provide the files needed for invasion:
1. Use a local TCP file server runing on random port to provide files in local directory `script_tools`.
2. Download needed files from remote github repository. (choose this option only if github is accessable inside router device.)
Which option do you prefer? (default: 1)
****************
router_ip_address: 192.168.31.1
stok: 4c3cdfc326f4a37de830a5c3ab70b030
file provider: local file server
****************
start uploading config file...
start exec command...
local file server is runing on 0.0.0.0:60175. root='script_tools'
local file server is getting 'busybox-mipsel' for 192.168.31.1.
local file server is getting 'dropbearStaticMipsel.tar.bz2' for 192.168.31.1.
done! Now you can connect to the router using several options: (user: root, password: root)
* telnet 192.168.31.1
* ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 -c 3des-cbc -o UserKnownHostsFile=/dev/null root@192.168.31.1
* ftp: using a program like cyberduck
Dann:
wusel@luggage:~$ ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 -c 3des-cbc -o UserKnownHostsFile=/dev/null root@192.168.31.1
The authenticity of host '192.168.31.1 (192.168.31.1)' can't be established.
RSA key fingerprint is SHA256:YlsXWcn1+TT+ejC87zuY7TICoD/kUoaF9MWSCBhuiK0.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.31.1' (RSA) to the list of known hosts.
root@192.168.31.1's password:
[…]
root@XiaoQiang:~# cd /tmp
root@XiaoQiang:/tmp# wget http://firmware.4830.org/tng/sysupgrade/gluon-4830-1.4
.0~11-xiaomi-mi-router-4a-gigabit-edition-sysupgrade.bin
Connecting to firmware.4830.org (193.26.120.20:80)
gluon-4830-1.4.0~11- 100% |*******************************| 7168k 0:00:00 ETA
Unlocking OS1 ...
Erasing OS1 ...
Writing from gluon-4830-1.4.0~11-xiaomi-mi-router-4a-gigabit-edition-sysupgrade.bin to OS1 ... [w]
Rebooting ...
ich hatte mir auch einen von diesen MI Router geshopt. Kam gestern.
@wusel bei Dir sah es ganz „geschmeidig“ aus. Meiner wollte nicht so recht. Erst ein downgrade auf 3.0.24 verschaffte einen Zugriff und später dann auch die Installation.
Welche Version hattest du im Auslieferungszustand?
Naja, tng ist ja entstanden aus dem Wechsel von fastd auf l2tp, IIRC, um ein separates Setup parallel testen zu können. Nun ist Gluon v2021.1 (»neues« tng) deutlich näher an v2019.1 (rawhide bis stable) als gedacht/der Versionssprung vermuten lies, und Gluon v2021.1 ist, AFAICS, nun wirklich die letzte Version, bei der wir tiny-Geräte (»4/32« (4 MB Flash, 32 MB RAM) wie z. B. die 841er) noch unterstützten können.
Soll heißen: ich denke, ich werde die aktuelle Version 1.2.0~108 von rawhide nun nach experimental und dann testing schieben, und nach einer Karenzzeit dann nach stable. Neu an 1.2.0~108 ist die Integration des »WAN-Speedtests« in die Statusseite:
Unter »Line« findet sich die per UPnP ermittelte Info einer vorgeschalteten Fritzbox zur Leitungskapazität. Wenn das Default-GW von br-wan keine FB ist, oder man im Gastnetz steckt, oder die UPnP-Abfrage blockiert wird, fehlt diese Angabe natürlich.
Um eine weitere Abschätzung zu ermöglichen, wird ca. 15 Minuten nach Boot eine 100-MB-Datei von spd-tst.4830.org gezogen und aus der Dauer ein Download-Durchsatz ermittelt und ausgewiesen.
(Funfact: ich stelle gerade fest, daß 33332-Schalueckstr-107-11d9 anders als verkabelt und somit erwartet, gar keinen WAN-Zugang hat; tststs.)
Nachdem dann 1.2.0~108 (bzw. 1.2.0~109 — mtr dabei in non-tiny-Images) ›rum‹ ist, würde ich 1.4.0 nach rawhide schieben und parallel in tng & rawhide ausrollen.
Dann müßtet Ihr auch wieder aktiv mittesten, ob 1.4.0 inkl. Setup-Modus usw. tut.
8/8 tng-Nodes sind auf 1.4.0~16.
9/10 rawhide-Nodes sind auf 1.2.0~109; 33334-Kerschensteinerweg-ap1 ist offline — @gtpix, IIRC ist das Deiner, magst Du denn für’s Update reaktivieren oder soll’ ich ihn generell ignorieren?
11/10 experimental-Nodes sind auf 1.2.0~109 (oder neuer; 1 Node hatte ich manuell auf 1.4 gezogen und nun zwecks Updates nach tng gepackt).
48/50 testing-Nodes sind auf 1.2.0~109. 33334-Hessenheide ist 11 Tage offline und noch auf 1.2.0~56; 33449-freifunk-ec086b6c6276 ist seit 3 Tagen offline und auf 1.2.0~104.
Kurz: ich sehe keine »ill effects« durch 1.2.0~109 und würde sie Sonntag zur stable machen wollen — Gegenstimmen?
Bei der Installation hatte ich noch Version …14 und da viel mir auf, dass kein WLAN ist.
Mit Version …16 funkt er wieder. Nach kleinere Experimenten wegen privatem WLAN hatte ich das Gerät vom Stromnetz genommen.
Beim Upgrade von 14 auf 16 habe ich gesehen, dass er zwar meine SSH Schlüssel behalten hatte, aber der Knotenname war weg bzw. unnamed. Auch die Ergebnisse von ip a haben sich von 19 auf 21 erhöht.
Hu? Ja, die Defaults bei v2021/1.4.0 im Configmode sind anders als zuvor (Mesh-VPN-Default: aus), aber WLAN sollte normal an sein? Will check.
Hmm. MAC, und damit DHCP-IP, sollte sich über Upgrades nicht ändern — da ich festgetackerte IPs vergebe, würde ich auch sagen, das geschieht beim 4A nicht. Aber guck’ ich nochmal drauf.
ffgt@colosses:~/jenkins_data/build$ ./promote-to.sh 1.2.0~109 stable
Promoting firmware 1.2.0~109 to branch stable ...
Done.
ffgt@colosses:~/jenkins_data/build$ date
Mo 16. Mai 02:58:58 CEST 2022
Damit liegt die Gluon v2018.2-basierte Firmware wohl in ihren letzten Zügen
…
Soll mit der TNG Variante noch weiter getestet werden mit mehr APs?
Oder soll die 1.4 in die Testing gehen, so dass wir evtl. eine auf 2022 basiertes Gluon bei TNG testen können?
Ich denke, 1.4.0 kann nach experimental, kurz darauf testing, und wir alle sollten mal genau gucken, ob alles funktioniert, von einer Erstinstallation an, aber auch Übernahme speziellerer Konfigurationen.
So ein Gluon-Build verschlingt mittlerweise 110 GB …
