TNG-Revival

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 :wink: So ein Gluon-Build verschlingt mittlerweise 110 GB …

So, nachdem es nun auch ein tng.manifest gibt, klappt’s auch mit dem Updating; die Statusseite ist etwas informativer:

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 …)

1 „Gefällt mir“

Hallo,

mit Spannung habe ich diesen Thread gesehen. Bei der Suche bin ich dann auch irgendwann auf das hier: xiaomi mi router 4a gigabit edition gluon 2021.x backport - HedgeDoc gestoßen. Bei [OpenWrt Wiki] Xiaomi Mi Router 4A Gigabit Edition ist auch ein Video verlinkt. Dort sieht es mittlerweile ganz entspannt aus um openWRT auf dem Ding zum Laufen zu bringen.

@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)?

Gruß,
Mike

Sei quasi live dabei:

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 ...

Dann auf http://setup.4830.org

… kommt nix? Via LAN-Verbindung man gucken:

root@luggage:~# ip addr add 203.0.113.22/24 dev enxa0cec85b461e
root@luggage:~# ping 203.0.113.1
PING 203.0.113.1 (203.0.113.1) 56(84) bytes of data.
64 bytes from 203.0.113.1: icmp_seq=1 ttl=64 time=0.823 ms
64 bytes from 203.0.113.1: icmp_seq=2 ttl=64 time=0.518 ms
^C
--- 203.0.113.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.518/0.670/0.823/0.154 ms
root@luggage:~# ssh 203.0.113.1
The authenticity of host '203.0.113.1 (203.0.113.1)' can't be established.
RSA key fingerprint is SHA256:K9tyMYLePnehseG5enrZWW51Gd2f0t8cvTPaFHq/iko.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '203.0.113.1' (RSA) to the list of known hosts.


BusyBox v1.30.1 () built-in shell (ash)

      _/_/_/_/                      _/      _/_/                      _/
     _/        _/  _/_/    _/_/          _/      _/    _/  _/_/_/    _/  _/
    _/_/_/    _/_/      _/_/_/_/  _/  _/_/_/_/  _/    _/  _/    _/  _/_/
   _/        _/        _/        _/    _/      _/    _/  _/    _/  _/  _/
  _/        _/          _/_/_/  _/    _/        _/_/_/  _/    _/  _/    _/

   Freifunk-Firmware für den Kreis Gütersloh, Bielefeld, die Müritz-Region
                     und die Feldberger Seenlandschaft

  Info/Kontakt: https://freifunk-kreisgt.de   | https://mueritz.freifunk.net
                https://freifunk-bielefeld.de | https://freifunk-feldberg.de

  Tools:
  - autoupdater -f    (Firmware-Update erzwingen)
  - batctl gwl        (Informationen zu batman-adv-Gateways anzeigen)
  - batctl o | wc -l  (Anzahl 'orginators' (Knoten) im Netz anzeigen)
  - batctl tg | wc -l (Anzahl aller Geräte im Netz anzeigen)


  OS: 19.07-SNAPSHOT, r11430+26-ecbbb3    FW: 1.4.0~11                        
  HW: Xiaomi Mi Router 4A Gigabit Edition                                 
root@unconfigured-node-8cdef9ae1686:~# ip route show
default via 10.255.128.11 dev br-setup proto static src 10.255.132.244 
10.255.128.0/20 dev br-setup proto kernel scope link src 10.255.132.244 
203.0.113.0/24 dev eth0.1 proto kernel scope link src 203.0.113.1 
root@unconfigured-node-8cdef9ae1686:~# traceroute setup.4830.org
traceroute to setup.4830.org (193.26.120.20), 30 hops max, 38 byte packets
 1  10.255.128.11 (10.255.128.11)  15.092 ms  22.900 ms  22.685 ms
 2  *  *  *
 3  guetersloh.freifunk.net (193.26.120.20)  18.337 ms  14.921 ms  17.342 ms
root@unconfigured-node-8cdef9ae1686:~# 

Tja, Bug in tng: /bin/wget: not found — das Binary ist nach /usr/bin umgezogen …

Ansonsten: eigentlich noch einfacher als bei TP-Link oder gar Netgear :wink:

1 „Gefällt mir“

Was macht die Geschwindigkeit?

100/40 scheint machbar (T-VDSL). Ich hab’s noch nicht am Kabelanschluß (1000/50) sauber hinbekommen (lokales Setup-Problem).

Moin,

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?

Gibt es für das Teil nur tng?

Gruß

Danke für den Hinweis. Bei mir war 3.0.24 drauf.

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.

Natürlich auch in tng und bis runter auf die tiny-Geräte:

(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~109mtr 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.

Das dürfte dann https://map03.4830.org/map/#!v:m;n:3ccd5771f867 sein? @mike, ist der absichtlich seit ca. 21:15 offline oder gibt’s ein Problem mit der 1.4.0~16 (gluon-v2021.1.2-ffgt-7-g49598801)?

1 „Gefällt mir“

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?

1 „Gefällt mir“

Ja, das ist der Knoten.

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.

FTR:

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 :wink:


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?

Good point …

1.0.x: v2018.1.4 based, fastd
1.1.2: v2018.2.x based, fastd
1.1.5: v2018.2.x based, L2TP (tunneldigger)
1.1.6: v2018.2.x based, VXLAN via Wireguard
1.2.0: v2019.1.x based, L2TP (tunneldigger) (>= 1.2.0~38 includes gluon-migra
te-ffbi)
1.4.0: v2021.1.x based, L2TP (tunneldigger)

Aktuelle Versionen (wenn vorhanden, sind die Release Notes zur Version verlinkt): stable = 1.2.0~109, testing = 1.2.0~109, experimental = 1.2.0~109, rawhide = 1.2.0~117.

Firmwareversionen

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.