Im next-Branch ist der 4A-Gigabit von Xiaomi bereits drin, es wäre jedoch sehr interessant, einen Backport ins Gluon-Releas (2021.1.x) zu haben.
Warum?
Es ist ein Gerät ähnlich des UBNT-ER-X, also 880MHZ Dualcore, was eine respektablen Netzwerkdurchsatz erwarten lässt (Nicht zu verschweigen „nur“ 128MB RAM/16MB Flash)
(Abgesehen davon sind die ER-X gerade nirgends lieferbar für unter 100€/Stück, aber anderes Thema)
Was macht den Xiamo 4A-gigabit interessant? Der Preis von derzeit 20-29€. (Der Herstellershop verschickt mit UPS für 5€ Frachtkosten aus den Niederlanden zu folgendem Preis)
Ich habe schon meine Versuche gemacht, scheitere irgendwie dran, vermutlich übersehe ich etwas.
Ein paar paar dts/dtsi-Dateien habe ich kopiert und die Targets, networking-config und die LEDs nachgetragen, aber es bleibt bei
?? target/linux/ramips/dts/mt7621_xiaomi_mi-router-4a-3g-v2.dtsi
?? target/linux/ramips/dts/mt7621_xiaomi_mi-router-4a-gigabit.dts
* unable to set 'CONFIG_TARGET_DEVICE_PACKAGES_ramips_mt7621_DEVICE_xiaomi_mi-router-4a-gigabit="-kmod-ipt-offload -odhcpd-ipv6only [..]"'
* unable to enable device 'xiaomi_mi-router-4a-gigabit'
Tipps willkommen. („Benutz’ doch den ‚next-branch‘“ ist hier keine Option.)
Deine Beschreibung ist hinreichend unspezifisch - Hast du einen Link zu deinem Branch oder alternativ ein Patchfile mit deinen Änderungen?
Davon abgesehen ist das Gerät in Gluon Master enthalten, nicht ausschließlich im next-branch. Ein backport von 21.02 nach 19.07 erfordert die Anpassung der Netzwerkkonfiguration von DSA auf swconfig.
Sollte ich irgendwo den Eindruck erweckt haben, der 4a-gigabit sei im master nicht enthalten, dann bitte ich das zu entschudligen.
Hilft mir der Hinweis „ist auch im Master enthalten“ irgendwie weiter? Das basiert doch wie next auf openwrt-21.02.
Da hatte ich dann den Hinweis in der neuen mt7621.mk fehlinterpretiert
Config cannot be migrated from swconfig to DSA
dahingehend als dass es eine GEräteklasse ist, die in swconfig verbleibt und nicht zu DSA migriert wird.
master tracked ein OpenWrt release und ist damit ähnlich stabil wie die Release-branches. next ist Gluon master, welches unregelmäßig gegen OpenWrt master rebased wird.
Der Hinweis (und die compat-version) bedeutet, dass es keinen Upgradepfad von 19.07 nach 21.02 und darüber hinaus gibt. Die Geräte müssen also neu installiert / provisioniert werden, um weiter verwendet werden zu können.
Einen Link zu deinen changes würde immer noch helfen. Oder suchst du jemanden, der sich für dich um den Backport kümmert?
Korrekt. Meine Wissenslücken bei den OpenWRT-Targets sind so groß, dass es vermutlich nicht zielführend ist, mich hier durchzuteachen. In der Zeit wird jemand, der es versteht dreimal selbst hinbekommen, meiner Vermutung nach.
Falls also jemand 2 Geräte geschenkt haben möchte „frei Haus“ für den Backport, bitte PM.
Ich bin weder OpenWRT noch Gluon Maintainer und kann den Wunsch durchaus verstehen. Jedoch erscheint es mir strategisch schlecht zu sein ein Gerät zu Backporten welches nach aktuellem Stand keinen Migrationspfad auf die aktuelle (veröffentlichte!) OpenWRT Version hat.
Ich denke da dürfte es sinnvoller sein Gluon 2021.2 (halt auf Basis von OpenWRT 21.02) voranzubringen oder halt schon Mal Firmware auf Basis von Gluon Master zu bauen. Dann halt nicht als stable, sondern als nightly, testing oder sowas.
Ich möchte hier jedoch keine Diskussion über Community-Pakete führen, weil das dann ausufert zu Gluon-Upstream-PRs, Codequalität, Projektstrategie etc. (Um es abzukürzen: ich nutze auch Pakete aus anderen Communities. Und natürlich könnte ich die auch alle forken und auf OpenWRT21 bringen und dann dort PRs stellen. Falls sich dazu jemand berufen fühlen sollte, bitte melden! Alternativ können wir jetzt eine Runde über die Problematik von lokalen Community-Paketen eröffnen. Bringt aber auch keinen Backport für den 4A-gigabit ins Gluon-release.)
Wir können uns gerne darüber unterhalten, ob die Aufzählung „next-Branch“ unvollständig ist und ich alle anderen Branches hätte aufzählen sollen, die ebenfalls nicht zur Debatte stehen.
Ich hatte gehoft, dass die Aussage/Intention meines Posts hinreichend klar geworden ist. Aber gern können wir uns jetzt über Formalien des Ausgangsposts unterhalten.
Mein Anliegen wäre nach wie vor, den Xiaomi 4A-GigabitEdition im aktuellen Gluon-Release nutzen zu können und dafür einen Patch/Fork o.ä. zu haben.
Second that (alleine aufgrund des Preises erstmal), aber Gluon 2020.1 bis 2021.1 basieren auf OpenWrt 19.07 AFAICS — Gluon Master/Next augenscheinlich auf OpenWrt 21.02. Damit klingt das schon in ›normalen‹ Zeiten nach einem gewissen Backporting-Aufwand (dunno, wie ähnlich der 4A existierenden Geräten ist?), und derzeit spaltet sich ja OpenWrt intern in diverse neue Zweige … Warum also nicht einfach abwarten bis Gluon 2021.2/2022.1, lies: woher die Dringlichkeit?
Der 4A (die nicht-GB-Version hat nur 100TX) ist in Gluon 2021.1.1 bereits drin.
Der hier angesprochene 4A-gigabit ist (mehr oder minder) das gleiche Gerät, nur mit dem SoC aus dem ERX (und anderer Menge Speicher).
Wie gross der Aufwand ist vermag ich nicht abzuschätzen, wenn das Schwestermodell des Herstellers bereits drin ist und Geräte mit gleichem SoC und WiFi auch. Ich spekuliere jedoch auf viel Cut&Paste plus Regressiontesting.
Ein kleines Issue (für die Checkliste): Wie/wo ändere ich den MAC-Offset, damit die Router-Mac auf dem Label (hier: 31:81 aufgedruckt) in Gluon zur Primären MAC wird? Derzeit ist die Mac 9c:9d:7e:c1:31:81 nur auf eth0.2,
Einige Tests später, für mesh-tests mit allen Bändern, Client-Durchsatz crossband/sameband, sysupgrade, sysupgrade -n, autoupdater inkl. signaturcheck:
Das Ding läuft meiner Meinung nach. Nur der Flashprozess ist halt ziemlich umständlich. Machbar aber halt „mehrstufig“.
Wäre echt toll wenn sich da Leute fänden, da den richtigen RSA-Key finden können, damit der durchaus gut funktionierende Pushbutton-TFTP-Rescue auch „Fremdfirmware“ nimmt.
Patches und Devicechecklist habe ich mal hier als MD verlinkt
Firmware gibt es derzeit in
konkret also
Umflash-Ablauf in Stichworten (mit der Firmware 3.0.24, mit älteren oder „non-global/cn“ Versionen geht’s aber auch)
Rechner benötigt mit
Webbrowser
python3/pip
einem ethernet, das sinnvollerweise eine statische ip aus 192.168.31.0/24 und eine aus in 192.168.1.0/24 hat, + Patchkabel
ein freies Patchkabel „mit Internet“, also DHCP + NATv4 als WAN
Stromsteckdose oder 12V, mind 1A auf DC-barrel 5.5/2.5mm, (Stecker mit Longneck sonst Wackelgefahr, nicht gut beim Flashen!)
kontrollieren, dass der Router meint, er habe Internet (Line zur Weltkugel oben rechts „grün“
aus der Browser-URL den hex-hash hinter „stok=“ herauskopieren
nun das Rootshell-Script starten
python3 remote_command_execution_vulnerability.py
.
Router IP nur bestätigen
den STOK-Wert eingeben (aus der Zwischenablage)
der nun folgende Scriptablauf sollte rund 2-15s brauchen.
Wenn das Script sofort fertig ist, dann stimmte das stok-Token nicht (Tippfehler, oder weil SourceIP vom Browser und vom Script nicht identisch waren)
Wenn das Script ewig lang braucht, dann hat entweder der Router kein Internet (busybox wird ‚live‘ aus dem Netz ins Routerram geschoben) oder dem python fehlt irgendwas.
(Wenn jemand das Script auf ‚alles lokal‘ oder gar nach GO portieren möchte: wäre toll!)
Nun (wie vom script vorgeschlagen) mit der Routershell verbinden (ssh oder telnet, user root, passwort root)
Optional: den Bootloader entsperren. Hat aber bei einem meiner Geräte hier den Effekt, dass das Bootmenu beim Kaltstart manchmal „falsch abbiegt“ (evtl. wegen nicht bestückter Pullup-Widerstände und Line-Noise) und der Router dan bis zum nächsten Powercycle „dead in the water“ ist.
nvram set uart_en=1
nvram set boot_wait=on
nvram set boot_delay=5
nvram commit
Für den ersten Flash-Vorgang ein Openwrt-initramfs-image (NICHT: Das Freifunk-Image) holen (Router hängt ja noch mit WAN im Internet) und schreiben
Mit Firmware „Version: 3.0.9 Stabil“ (nicht china version) und der obigen Anleitung wird der Router nach dem …initramfs-kernel.bin --output firmware.bin && mtd -e OS1 -r write firmware.bin OS1
Was für ein Gerät hast Du denn genau? Foto vom Typenschild evtl? Nur um sicherzugehen, dass es wirklich ein Mi4AG ist und nicht einer seiner sehr ähnlichen Geschwister.
o.k, das ist das richtige modell.
Das TFTP-Rescue mit dem TinyPXE funktioniert hier sogar, um von Openwrt/Gluon wieder zur StockFW zurückzukommen. Weil der Bootloader nicht ersetzt wird. (Der liegt ja vor der OS1 partition)
daher: Keine Ahnung, was da schief gelaufen ist. Ich habe hier bislang 4 Geräte von Mi4AG umgeflashed, die waren aus 3 verschiedenen Bestellungen, einmal Aliexpress, einmal der Herstellershop in den Niederlanden und einmal ein Elektronikversender in Tschechien.
Wie geschrieben, das Internationale Image ging wie das Chinesische nicht.
CN brach gleich ab und bei ein internationalen nen sprang der Router in den „Security Mode“ (lila blinkend LED).
