Würgaround für UAP-AC-PRO
Ich habe gerade ne Menge zu dem UniFi-AC sysupgrade Bug quergelesen und meine ein bisschen was verstanden zu haben. Vielleicht hilft es dem ein oder anderen: Die UniFi-AC Geräte setzen auf einen Flip-Flop-Flash. Daher kommen auch kernel0 und kernel1. Bei jeden Stock-Upgrade wird das Update in den inaktiven Flash geschrieben und beim Reboot der Flash gewechselt. Bei Fehlern wird der Flash einfach wieder zurück geflipt. Auf diese Weise wird immer eine funktionierende Firmware vorhanden. Die Auswahl wird über die bs-Partition getroffen. OpenWrt's sysupgrade macht (noch) keinen Gebrauch von dieser Methode, die ja auch stark geräteabhängig ist. Letztlich beschreibt das sysupgrade immer nur den kernel0 Part und liest von dort. Nun kann es den Fall geben (bspw): Neues Gerät wird mit neuer Firmware ohne mtd ausgeliefert [bs=0]. Es wird ein Downgrade auf eine Version mit mtd ausgeführt [Stock-(Up)grade -> bs=1]. Wir flashen auf kernel0 und kernel1 ein OpenWrt Image [bs=1]. Wir booten von kernel1. Alles läuft. Die Kernel-Module in beiden Partitionen sind kompatibel. sysupgrade! kernel0 wird beschrieben, kernel1 bleibt. Wir booten von kernel1. Kaputt. Kernel Module in kernel0 und kernel1 sind inkompatibel. Das Fallbeispiel basiert auf Vermutungen. Punkt ist, dass wohl alles gut ist, wenn unmittelbar vor dem flashen von OpenWrt [bs=0] ist. Es wird dann immer kernel0 beschrieben beim sysupgrade und auch von da gebootet. kernel1 gammelt einfach herum. Setzen kann man das mit folgendem Befehl:
dd if=/dev/zero bs=1 count=1 of=/dev/mtdN Wobei N die Partitionsnummer von bs ist. Die findet ihr mit folgendem Befehl: cat /proc/mtd Vielleicht mag unser Herr und Meister der Shellscripte, Dr. lrnzo :-P, mal schauen, ob man das in einen Einzeiler verwursteln kann, der sowohl in der Stock-Firmware, als auch bei uns ausführbar ist?
Wichtig ist allerdings beim ersten flashen trotzdem beide (kernel0 und kernel1) zu beschreiben, da der Bootloader(?) immer eine von Ubiquiti signierte Firmware bevorzugt startet. Dementsprechend müssen beide Flash-Speicher mit unsignierten Firmwares beschrieben werden. In OpenWrt wurde die bs-Parition beschreibbar gemacht [1], sodass man diesen Fix auch nachträglich anwenden kann. Ich weiß nicht, ob diese Änderung bei uns schon enthalten ist. Ansonsten hänge ich nochmal den Link zum OpenWrt Bugreport [2] und zum Bugreport in Gluon [3] an. [1] https://github.com/lede-project/source/commit/f17173f5a36999f070a2ccbde2953d... [2] https://bugs.openwrt.org/index.php?do=details&task_id=662 [3] https://github.com/freifunk-gluon/gluon/issues/1301 -- Viele Grüße, Simon
der erste Schuss ins blau sieht so aus: dd if=/dev/zero bs=1 count=1 of=/dev/$(grep kernel /proc/mtd | awk -F ':' '{print $1}') aber das ist noch nicht das, wo du hin willst, oder? in unserer Firmware (20171220) sieht es auf Ubiquiti UniFi so aus: root@ff-os-Varusschlacht-25:~# cat /proc/mtd dev: size erasesize name mtd0: 00040000 00010000 "u-boot" mtd1: 00010000 00010000 "u-boot-env" mtd2: 00760000 00010000 "firmware" mtd3: 00150000 00010000 "kernel" mtd4: 00610000 00010000 "rootfs" mtd5: 003d0000 00010000 "rootfs_data" mtd6: 00040000 00010000 "cfg" mtd7: 00010000 00010000 "EEPROM" und auf Ubiquiti UniFi-AC-LITE (ist aber imho in Wirklichkeit AC-Mesh) so: root@ff-os-Varusschlacht-02:~# cat /proc/mtd dev: size erasesize name mtd0: 00060000 00010000 "u-boot" mtd1: 00010000 00010000 "u-boot-env" mtd2: 00790000 00010000 "firmware" mtd3: 00150000 00010000 "kernel" mtd4: 00640000 00010000 "rootfs" mtd5: 003d0000 00010000 "rootfs_data" mtd6: 00790000 00010000 "ubnt-airos" mtd7: 00020000 00010000 "bs" mtd8: 00040000 00010000 "cfg" mtd9: 00010000 00010000 "EEPROM" Original Hardware/firmware habe ich nicht zur Hand LG Lorenz Am 10.04.2018 um 12:22 schrieb Simon Kurka via Dev:
Vielleicht mag unser Herr und Meister der Shellscripte, Dr. lrnzo :-P, mal schauen, ob man das in einen Einzeiler verwursteln kann, der sowohl in der Stock-Firmware, als auch bei uns ausführbar ist?
On 04/10/18 13:01, lrnzo via Dev wrote:
der erste Schuss ins blau sieht so aus:
dd if=/dev/zero bs=1 count=1 of=/dev/$(grep kernel /proc/mtd | awk -F ':' '{print $1}')
aber das ist noch nicht das, wo du hin willst, oder?
@sk ich hab das gerade mal überflogen wie du es schon angedeutet hast müsste es reichen nicht den Kernel sonder das bs zu überschreiben. Sprich beim factory falshen muss so oder so kernel(0|1) wegen der bevorzugten signatur geflascht werden. Um nun kernel ABI Probleme zu verhindert müsste es wohl reichen einmalig die BS Partition mit einem 0 byte zu beschreiben um somit immer das booten von kernel0 zu erzwingen. Das müsste mit folgenden command zu lösen sein, allerdings von der stock Firmware aus, in dem falle 3.7.40. dd if=/dev/zero bs=1 count=1 of=/dev/"$(grep bs /proc/mtd | awk -F ':' '{print $1}')" nicht Kernel. Über lede wirst du das aktuell vermutlich nicht hinbekommen da BS vermutlich read only ist. vg Tarek
Das mit readonly wurde in openwrt gepatcht, ist nur die Frage ob der commit schon mit drin ist. Jan-Tarek Butt via Dev <dev@lists.ffnw.de> schrieb am Di., 10. Apr. 2018, 15:42:
On 04/10/18 13:01, lrnzo via Dev wrote:
der erste Schuss ins blau sieht so aus:
dd if=/dev/zero bs=1 count=1 of=/dev/$(grep kernel /proc/mtd | awk -F ':' '{print $1}')
aber das ist noch nicht das, wo du hin willst, oder?
@sk ich hab das gerade mal überflogen wie du es schon angedeutet hast müsste es reichen nicht den Kernel sonder das bs zu überschreiben.
Sprich beim factory falshen muss so oder so kernel(0|1) wegen der bevorzugten signatur geflascht werden. Um nun kernel ABI Probleme zu verhindert müsste es wohl reichen einmalig die BS Partition mit einem 0 byte zu beschreiben um somit immer das booten von kernel0 zu erzwingen.
Das müsste mit folgenden command zu lösen sein, allerdings von der stock Firmware aus, in dem falle 3.7.40.
dd if=/dev/zero bs=1 count=1 of=/dev/"$(grep bs /proc/mtd | awk -F ':' '{print $1}')"
nicht Kernel. Über lede wirst du das aktuell vermutlich nicht hinbekommen da BS vermutlich read only ist.
vg Tarek
_______________________________________________ Dev mailing list -- dev@lists.ffnw.de To unsubscribe send an email to dev-leave@lists.ffnw.de
On 04/10/18 16:13, Jan-Tarek Butt via Dev wrote:
On 04/10/18 16:05, Simon Kurka wrote:
Das mit readonly wurde in openwrt gepatcht, ist nur die Frage ob der commit schon mit drin ist.
Ja, deswegen auch zweimal vermutlich im letzten Satz ;P. Ich schauen heute Abend mal. wenn es nicht vorher jemand tut.
Ich bin das gerade nochmal durch gegangen. Es ist garnicht möglich das Problem via Firmware zu lösen. Alle betroffenen Geräte können nur eine Fehlerbehebung bekommen indem Sie Recovert werden und entsprechend beim initial flashen die BS Partition präpariert wird. https://openwrt.org/toh/ubiquiti/unifiac#installing_openwrt D.h. alle jetzigen UAP PRO und LRs Betreiber sollten ihren autoupdater abschalten und bei zeit ihre Geräte recovern damit diese korrekt installiert werden. vg Tarek
https://openwrt.org/toh/ubiquiti/unifiac#installing_openwrt
D.h. alle jetzigen UAP PRO und LRs Betreiber sollten ihren autoupdater abschalten und bei zeit ihre Geräte recovern damit diese korrekt installiert werden.
Pardon ich meine die AP-AC Mesh/Lite/Pro... die o.g. sind ja wiederum andere Modelle ;P
Zustimmung! Wobei spätestens mit dem return zu OpenWrt dürfte die bs Partition beschreibbar sein und vermutlich ein entsprechender Patch openwrt oder gluon seitig eingepflegt werden. Wenn dieses hardware Feature nicht sogar Anwendung findet, denn an sich ist diese update Methode schon ziemlich genial. Ich würde sagen die Geräte können dann mit der kommenden Version such ruhig wieder in das autoupdate rein. Vielleicht wäre dazu ein Blogpost sinnvoll, um zu sensibilisieren. Jan-Tarek Butt via Dev <dev@lists.ffnw.de> schrieb am Mi., 11. Apr. 2018, 14:43:
https://openwrt.org/toh/ubiquiti/unifiac#installing_openwrt
D.h. alle jetzigen UAP PRO und LRs Betreiber sollten ihren autoupdater abschalten und bei zeit ihre Geräte recovern damit diese korrekt installiert werden.
Pardon ich meine die AP-AC Mesh/Lite/Pro... die o.g. sind ja wiederum andere Modelle ;P
_______________________________________________ Dev mailing list -- dev@lists.ffnw.de To unsubscribe send an email to dev-leave@lists.ffnw.de
participants (3)
-
Jan-Tarek Butt -
lrnzo -
Simon Kurka