Unifi Flash Probleme

CHRlS · 15. März 2016 um 13:50

Ich habe soeben mit einer Gluon Factory 2016.1 mehrmals vergeblich versucht einen Unifi AP LR auf Gluon umzuflashen, sind diese ggfs. ebenfalls von der geänderten Reihenfolge des Bootloaders betroffen? Das Flashen bricht einfach irgendwann ohne Meldung ab, der Router ist ab dem Zeitpunkt offensichtlich abgestürzt, LED aus, Ping geht nicht mehr durch.

Zu meiner Überraschung funktionierte TFTP Recovery jedoch in allen Fällen spontan und problemlos.

Hier das Log des Flashvorgangs:

BZ.v3.3.19# fwupdate.real -m fwupdate.bin -d
Found mtd block: /dev/mtd0(u-boot)
Found mtd block: /dev/mtd1(u-boot-env)
Found mtd block: /dev/mtd2(kernel)
Found mtd block: /dev/mtd3(rootfs)
Found mtd block: /dev/mtd4(cfg)
Found mtd block: /dev/mtd5(EEPROM)
Got U-Boot variable: mtdparts = mtdparts=mtdparts=ar7240-nor0:256k(u-boot),64k(u-boot-env),1024k(kernel),6528k(rootfs),256k(cfg),64k(EEPROM)
Adding U-Boot partition: u-boot 9F000000 00040000
Adding U-Boot partition: u-boot-env 9F040000 00010000
Adding U-Boot partition: kernel 9F050000 00100000
Adding U-Boot partition: rootfs 9F150000 00660000
Adding U-Boot partition: cfg 9F7B0000 00040000
Adding U-Boot partition: EEPROM 9F7F0000 00010000
Calculating flash size:
Adding block: /dev/mtd0("u-boot") - size: 00040000
Adding block: /dev/mtd1("u-boot-env") - size: 00010000
Adding block: /dev/mtd2("kernel") - size: 00100000
Adding block: /dev/mtd3("rootfs") - size: 00660000
Adding block: /dev/mtd4("cfg") - size: 00040000
Adding block: /dev/mtd5("EEPROM") - size: 00010000
Total flash size: 00800000
Flash start: 9F000000
Flash end: 9F800000
Header MAGIC 'OPEN'
Current: BZ.ar7240.v3.3.19.4015.160218.1458

New ver: BZ.ar7240.v6.0.0-OpenWrt-r47335
FW Part: "kernel"(1), MAGIC: 'PART', Base: 0x9F050000, DLen: 0x00100000, PLen: 0x00100000
FW Part: "rootfs"(2), MAGIC: 'PART', Base: 0x9F150000, DLen: 0x00260004, PLen: 0x005A0000
Adding adjusted FW partition:
name:   'kernel'
flash_base:     0x9F050000
mem_base:       0x80002000
size:           0x00100000
entry_point:    0x80002000
data_len:       0x00100000
desc_cksum:     0x00000000
file_cksum:     0x00000000
===========================
Adding adjusted FW partition:
name:   'rootfs'
flash_base:     0x9F150000
mem_base:       0xBDBDBDBD
size:           0x005A0000
entry_point:    0xBDBDBDBD
data_len:       0x00260004
desc_cksum:     0x00000000
file_cksum:     0x00000000
===========================
Signature MAGIC 'END.'
Working(1) with block: /dev/mtd0
Skipping: artificial: 0, unallocated: 0,writeable: 1024(WRITEABLE: 400, flags: C00), fw.flash_base: 9F050000 < blk->base: 9F000000 + blk->size: 40000
Copying FIS partition: 0 =>
name:   'u-boot'
flash_base:     0x9F000000
mem_base:       0xBDBDBDBD
size:           0x00040000
entry_point:    0xBDBDBDBD
data_len:       0x00040000
desc_cksum:     0xBDBDBDBD
file_cksum:     0xBDBDBDBD
===========================
Working(1) with block: /dev/mtd1
Skipping: artificial: 0, unallocated: 0,writeable: 1024(WRITEABLE: 400, flags: C00), fw.flash_base: 9F050000 < blk->base: 9F040000 + blk->size: 10000
Copying FIS partition: 1 =>
name:   'u-boot-env'
flash_base:     0x9F040000
mem_base:       0xBDBDBDBD
size:           0x00010000
entry_point:    0xBDBDBDBD
data_len:       0x00010000
desc_cksum:     0xBDBDBDBD
file_cksum:     0xBDBDBDBD
===========================
Working(1) with block: /dev/mtd2
Working(2) with block: /dev/mtd2
End check: 9F050000 + 00100000 <= 9F150000
Creating FIS partition: 2 =>
name:   'kernel'
flash_base:     0x9F050000
mem_base:       0x80002000
size:           0x00100000
entry_point:    0x80002000
data_len:       0x00100000
desc_cksum:     0x00000000
file_cksum:     0x00000000
===========================
Working(1) with block: /dev/mtd2
Skipping: artificial: 0, unallocated: 0,writeable: 1024(WRITEABLE: 400, flags: C00), fw.flash_base: 9F150000 < blk->base: 9F050000 + blk->size: 100000
Working(1) with block: /dev/mtd3
Working(2) with block: /dev/mtd3
End check: 9F150000 + 005A0000 <= 9F7B0000
Creating FIS partition: 3 =>
name:   'rootfs'
flash_base:     0x9F150000
mem_base:       0xBDBDBDBD
size:           0x005A0000
entry_point:    0xBDBDBDBD
data_len:       0x00260004
desc_cksum:     0x00000000
file_cksum:     0x00000000
===========================
Working(3) with block: /dev/mtd4
Copying FIS partition: 4 <=
name:   'cfg'
flash_base:     0x9F7B0000
mem_base:       0xBDBDBDBD
size:           0x00040000
entry_point:    0xBDBDBDBD
data_len:       0x00040000
desc_cksum:     0xBDBDBDBD
file_cksum:     0xBDBDBDBD
===========================
Working(3) with block: /dev/mtd5
Copying FIS partition: 5 <=
name:   'EEPROM'
flash_base:     0x9F7F0000
mem_base:       0xBDBDBDBD
size:           0x00010000
entry_point:    0xBDBDBDBD
data_len:       0x00010000
desc_cksum:     0xBDBDBDBD
file_cksum:     0xBDBDBDBD
===========================
New FIS entries count 6
Working(1) with block: /dev/mtd0
Skipping: artificial: 0, unallocated: 0,writeable: 1024(WRITEABLE: 400, flags: C00), fw.flash_base: 9F050000 < blk->base: 9F000000 + blk->size: 40000
Copying FIS partition: 0 =>
name:   'u-boot'
flash_base:     0x9F000000
mem_base:       0xBDBDBDBD
size:           0x00040000
entry_point:    0xBDBDBDBD
data_len:       0x00040000
desc_cksum:     0xBDBDBDBD
file_cksum:     0xBDBDBDBD
===========================
Working(1) with block: /dev/mtd1
Skipping: artificial: 0, unallocated: 0,writeable: 1024(WRITEABLE: 400, flags: C00), fw.flash_base: 9F050000 < blk->base: 9F040000 + blk->size: 10000
Copying FIS partition: 1 =>
name:   'u-boot-env'
flash_base:     0x9F040000
mem_base:       0xBDBDBDBD
size:           0x00010000
entry_point:    0xBDBDBDBD
data_len:       0x00010000
desc_cksum:     0xBDBDBDBD
file_cksum:     0xBDBDBDBD
===========================
Working(1) with block: /dev/mtd2
Working(2) with block: /dev/mtd2
Unlocking /dev/mtd2(kernel) ...
Unlocking device failed: ioctl(MEMUNLOCK): Operation not supported
Writing 'kernel         ' to /dev/mtd2(kernel         ) ...
Writing: 0x00100000 bytes with offset 0x00000000
[%0  ]
Block on '/dev/mtd2' at 00000000(len: 00010000) has changes.              [%6  ]
Block on '/dev/mtd2' at 00010000(len: 00010000) has changes.              [%12 ]
Block on '/dev/mtd2' at 00020000(len: 00010000) has changes.              [%18 ]
Block on '/dev/mtd2' at 00030000(len: 00010000) has changes.              [%25 ]
Block on '/dev/mtd2' at 00040000(len: 00010000) has changes.              [%31 ]
Block on '/dev/mtd2' at 00050000(len: 00010000) has changes.              [%37 ]
Block on '/dev/mtd2' at 00060000(len: 00010000) has changes.              [%43 ]
Block on '/dev/mtd2' at 00070000(len: 00010000) has changes.              [%50 ]
Block on '/dev/mtd2' at 00080000(len: 00010000) has changes.              [%56 ]
Block on '/dev/mtd2' at 00090000(len: 00010000) has changes.              [%62 ]
Block on '/dev/mtd2' at 000A0000(len: 00010000) has changes.              [%68 ]
Block on '/dev/mtd2' at 000B0000(len: 00010000) has changes.              [%75 ]
Block on '/dev/mtd2' at 000C0000(len: 00010000) has changes.              [%81 ]
Block on '/dev/mtd2' at 000D0000(len: 00010000) has changes.              [%87 ]
Block on '/dev/mtd2' at 000E0000(len: 00010000) has changes.              [%93 ]
Block on '/dev/mtd2' at 000F0000(len: 00010000) has changes.              [%100]

End check: 9F050000 + 00100000 <= 9F150000
Creating FIS partition: 2 =>
name:   'kernel'
flash_base:     0x9F050000
mem_base:       0x80002000
size:           0x00100000
entry_point:    0x80002000
data_len:       0x00100000
desc_cksum:     0x00000000
file_cksum:     0x00000000
===========================
Working(1) with block: /dev/mtd2
Skipping: artificial: 0, unallocated: 0,writeable: 1024(WRITEABLE: 400, flags: C00), fw.flash_base: 9F150000 < blk->base: 9F050000 + blk->size: 100000
Working(1) with block: /dev/mtd3
Working(2) with block: /dev/mtd3
Unlocking /dev/mtd3(rootfs) ...
Unlocking device failed: ioctl(MEMUNLOCK): Operation not supported
Writing 'rootfs         ' to /dev/mtd3(rootfs         ) ...
Writing: 0x00260004 bytes with offset 0x00000000
[%0  ]
Block on '/dev/mtd3' at 00000000(len: 00010000) has changes.              [%2  ]
Block on '/dev/mtd3' at 00010000(len: 00010000) has changes.              [%5  ]
Block on '/dev/mtd3' at 00020000(len: 00010000) has changes.              [%7  ]
Block on '/dev/mtd3' at 00030000(len: 00010000) has changes.              [%10 ]
Block on '/dev/mtd3' at 00040000(len: 00010000) has changes.              [%13 ]
Block on '/dev/mtd3' at 00050000(len: 00010000) has changes.              [%15 ]
Block on '/dev/mtd3' at 00060000(len: 00010000) has changes.              [%18 ]
Block on '/dev/mtd3' at 00070000(len: 00010000) has changes.              [%21 ]
Block on '/dev/mtd3' at 00080000(len: 00010000) has changes.              [%23 ]
Block on '/dev/mtd3' at 00090000(len: 00010000) has changes.              [%26 ]
Block on '/dev/mtd3' at 000A0000(len: 00010000) has changes.              [%28 ]
Block on '/dev/mtd3' at 000B0000(len: 00010000) has changes.              [%31 ]
Block on '/dev/mtd3' at 000C0000(len: 00010000) has changes.              [%34 ]
Block on '/dev/mtd3' at 000D0000(len: 00010000) has changes.              [%36 ]

CyrusFox · 15. März 2016 um 13:57

Hi

https://github.com/freifunk-gluon/gluon/issues/663

Müsste das issue sein, ist mit 2016.1.2 gefixt. 2016.1 kann solche Geräte bricken.

CHRlS · 15. März 2016 um 14:00

Ist aber Unifi statt AirOS, deshalb die Verunsicherung bei mir!?

CyrusFox · 15. März 2016 um 14:01

Ich denke das Problem ist nicht Unifi bzw AirOS sondern das Image was gebaut wird, das scheint auf die falschen Flash-Bereich schreiben zu wollen, dazu stand auch was im Issue.

CHRlS · 15. März 2016 um 14:07

Wir, bzw. vielmehr @chrisno backt die 2016.1.2, dann probiere ich es damit noch mal…

steneu · 15. März 2016 um 16:32

Habe gerade einen Schwung unifi bekommen, die eh noch geflasht werden müssen und das eben mal getestet:

Mit Gloun 2016.1 habe ich genau das von dir beschriebene Verhalten. Mit TFTP ist dann aber alles gut

Mit Gluon 2016.1.2 klappt das flashen eines neuen unifi über die Konsole problemlos.

CyrusFox hat da wohl recht. Wir hatten sicherheitshalber wegen der Ubiquiti Probleme deshalb unsere Firmware am Samstag auf 2016.1.2 umgestellt.

CHRlS · 16. März 2016 um 23:22

Wenn @chrisno mir gerade für Herne tatsächlich eine 2016.1.2 untergejubelt hat, dann ist das Problem bei mir nach wie vor vorhanden, denn der Flashvorgang ging beim /dev/mtd3 wieder schief:

Working(1) with block: /dev/mtd3
Working(2) with block: /dev/mtd3
Unlocking /dev/mtd3(rootfs) ...
Unlocking device failed: ioctl(MEMUNLOCK): Operation not supported
Writing 'rootfs         ' to /dev/mtd3(rootfs         ) ...
Writing: 0x00260004 bytes with offset 0x00000000
[%0  ]
Block on '/dev/mtd3' at 00000000(len: 00010000) has changes.              [%2  ]
Block on '/dev/mtd3' at 00010000(len: 00010000) has changes.              [%5  ]
Block on '/dev/mtd3' at 00020000(len: 00010000) has changes.              [%7  ]
Block on '/dev/mtd3' at 00030000(len: 00010000) has changes.              [%10 ]
Block on '/dev/mtd3' at 00040000(len: 00010000) has changes.              [%13 ]
Block on '/dev/mtd3' at 00050000(len: 00010000) has changes.              [%15 ]
Block on '/dev/mtd3' at 00060000(len: 00010000) has changes.              [%18 ]
Block on '/dev/mtd3' at 00070000(len: 00010000) has changes.

CHRlS · 17. März 2016 um 07:59

Was für einen Unifi Router hattest Du genau mit der 2016.1.2 Factory geflasht?

Geflasht hast Du ganz regulär im SSH mittels „fwupdate.real -m -d“?

@CyrusFox hattest Du über 2016.1.2 hinaus noch weitere Fixes manuell mit einkompiliert?

CyrusFox · 17. März 2016 um 08:51

Also ich hab nichts dazu gepackt. Wir haben 2016.1.2 vom Tag/Release gebaut.

steneu · 17. März 2016 um 10:05

Hab die jetzt gerade nicht hier. Ich schau heute Abend mal nach. Hab auch noch Fabrikneue hier und kann noch weitere Flashen.

Korrekt. Genau so hab ich den auch geflasht.

So hab ich auch gebaut mit Tag /Release auf 2016.1.2

CHRlS · 17. März 2016 um 10:07

Hmmm…

Ich probiere später mal, alte Firmware zu flashen und wenn das geht ein sysupgrade zu machen. Was anderes fällt mir spontan sonst nicht mehr ein.

steneu · 17. März 2016 um 10:21

Wenn du magst, kannst du ja mal mit meiner testen:
http://firmware.freifunk-radevormwald.de/stable/factory/gluon-ffrade-0.7.2-rdv-20160312-ubiquiti-unifi.bin

Müsstest dann aber auch zwei mal flashen Aber dann wäre der Fehler zumindest weiter eingegrenzt.

Ich hatte jedenfalls einen der „billigen“ unifi: http://map.freifunk-radevormwald.de/#!v:m;n:44d9e7d37496
Keinen ap-pro und keinen outdoor und keinen LR. Ganz genau dann, wenn ich die Packung hab.

CHRlS · 17. März 2016 um 10:25

Hab gerade schon eine alte 0.7.2 versucht zu flashen, geht ebenfalls nicht.

Da keine weitere Ausgabe erfolgt und ich kein Equipment hier habe, um mich anders als per SSH drauf zu verbinden, stehe ich jetzt natürlich auf dem Schlauch. Mittlerweile vermute ich das es nicht an der Firmware, sondern an der Hardware liegt. Ist aber auch ein ganz normaler UAP-LR.

CHRlS · 22. März 2016 um 11:25

Wir checken mal die Images.

Hab mit Deiner „Düsseldorf 2016.1.2 Beta“ problemlos ne Picostation, nen alten Unifi AP LR und neue Unifi AP aus dem Stand flashen können, ohne jegliche Auffälligkeit.