PicoStationM2 - v2016.1+1.0.0


#1

Hi,
ich habe auf einen PicoStationM2 die Freifunk Firmware v2016.1+1.0.0 für Domäne 6 installiert.
Das Gerät bootet auch, jedoch immer nur im Recovery Modus.
Jede Einstellung ist nach dem nächsten Reboot wieder weg.

Ich bekomme aktuell auch keine andere Firmware auf das Gerät, weder ssh, web oder per TFTP(Recovery Modus des Gerätes).

Nach ein bisschen suchen habe ich folgendes in der Log gefunden:

Anbei die wichtigsten Infos:
Filesystem 1K-blocks Used Available Use% Mounted on
rootfs 14268 124 14144 1% /
/dev/root 2560 2560 0 100% /rom
tmpfs 14268 332 13936 2% /tmp
tmpfs 14268 124 14144 1% /tmp/root
overlayfs:/tmp/root 14268 124 14144 1% /
tmpfs 512 0 512 0% /dev
/dev/mtdblock5 4032 4032 0 100% /rom/overlay

Auszug aus der Log Daten nach dem Boot:
Thu Feb 11 00:20:49 2016 daemon.err mount_root: no jffs2 marker found
Thu Feb 11 00:20:49 2016 kern.warn kernel: [ 28.130000] jffs2_scan_eraseblock(): End of filesystem marker found at 0x0
Thu Feb 11 00:20:49 2016 kern.warn kernel: [ 28.140000] jffs2_build_filesystem(): unlocking the mtd device… done.
Thu Feb 11 00:20:49 2016 kern.warn kernel: [ 28.150000] jffs2_build_filesystem(): erasing all blocks after the end marker…
Thu Feb 11 00:20:49 2016 kern.warn kernel: [ 28.190000] jffs2: Newly-erased block contained word 0x19852003 at offset 0x003e0000

Thu Feb 11 00:20:49 2016 kern.warn kernel: [ 28.240000] jffs2: Newly-erased block contained word 0x19852003 at offset 0x003b0000

Thu Feb 11 00:20:50 2016 kern.warn kernel: [ 29.210000] jffs2: Newly-erased block contained word 0xdeadc0de at offset 0x00000000
Thu Feb 11 00:20:50 2016 kern.warn kernel: [ 29.240000] done.
Thu Feb 11 00:20:50 2016 kern.notice kernel: [ 29.240000] jffs2: notice: (1074) jffs2_build_xattr_subsystem: complete building xattr subsystem, 0 of xdatum (0 unchecked, 0 orphan) and 0 of xref (0 dead, 0 orphan) found.
Thu Feb 11 00:20:50 2016 user.emerg syslog: cp: can’t create directory ‘/rom/overlay/upper’: No space left on device
Thu Feb 11 00:20:50 2016 user.emerg syslog: cp: can’t create directory ‘/rom/overlay/work’: No space left on device
Thu Feb 11 00:20:50 2016 daemon.err mount_root: failed - cp -a /tmp/root/* /rom/overlay: No such file or directory
Thu Feb 11 00:20:51 2016 daemon.info procd: - init complete -

Hat jemand eine Idee wie ich das Gerät in Funktion setzten kann, also auch nach einem Reboot :wink:


#2

Hast du eventuell eine Pico mit Originalfirmware 5.6 erwischt? Dann drücke ich dir die Daumen, dass die noch zu retten ist.

Probier mal per tftp die neue V1.0.2, die müsste das können: http://firmware.freifunk-muensterland.org/domaene01/versions/v1.0.2/


#3

Befehl: tftp -i 192.168.1.20 put “gluon-ffmsd01-v2016.1.1+1.0.2-ubiquiti-picostation-m.bin” flash_update
Rückmeldung: Fehler auf Server : ???d

Was mich wundert ist das das System bootet, nur es scheint als wenn da ein Schreibschutz drauf ist. kann man den nicht entfernen nach dem Boot?


#4

Ja, das war irgendwie das Problem. Dachte, dass Gluon 2016.1.1 genau das behebt.


#5

Ich habe folgende Seite gefunden:

http://www.fusionnetwork.us/index.php/articles/general-tutorials/how-to-recover-a-bricked-ubiquiti-nanostation2-or-picostation2/

Hat das schon jemand getestet?
Oder Besser zum Hersteller einschicken, solange das Gerät ungeöffnet ist?


#6

Kann die kein tftp?

Edit: https://wiki.openwrt.org/toh/ubiquiti/bullet

Per tftp sollte es gehen.


#7

So,

es hat etwas gedauert aber nun bin ich soweit durch.
Ich versuche die schritte kurz aufzuführen.
Ich hoffe das ich nix vergesse.

Per TFTP konnte ich nur das Image XM2BZ.v3.2.13.2929.151117.1557.bin updaten.
Bei allen anderen wurden nicht akzeptiert.
Danach war auf dem AP unifi drauf.
von hieraus habe ich zuerst versucht:
fwupdate.real -m gluon-ffmsd06-v2016.1.1+1.0.2-ubiquiti-picostation
mit dem Ergebnis:
Current: BZ.ar7240.v3.2.13.2929.151117.1557
New ver: XM.ar7240.v6.0.0-OpenWrt-r47335
Invalid version 'XM.ar7240.v6.0.0-OpenWrt-r47335’
BZ.v3.2.13#

Danach habe ich versuchte ich die Orginal u installieren: xmv5511280021507231344bin
ohne Erfolg
In einer anderen Anleitung fand ich folgende Befehle:
sync
echo 3 > /proc/sys/vm/drop_caches
syswrapper.sh upgrade2

zum Schluss funktionierte folgendes:
die OpenWRT Firmware openwrt-ar71xx-generic-ubnt-unifi-squashfs-factory ablegen /tmp/fwupdate.bin
und dann:
fwupdate.real -m fwupdate.bin -d
Ausführen.
Zeigte er unter anderem an:

Current: BZ.ar7240.v3.2.13.2929.151117.1557
New ver: BZ.ar7240.v6.0.0-OpenWrt-r42625
FW Part: “kernel”(1), MAGIC: ‘PART’, Base: 0x9F050000, DLen: 0x00100000, PLen: 0x00100000
FW Part: “rootfs”(2), MAGIC: ‘PART’, Base: 0x9F150000, DLen: 0x00230004, PLen: 0x005A0000
Adding adjusted FW partition:
name: ‘kernel’

New FIS entries count 6
FIS Change: added partition terminator instead of 0x75.
New partition count: 0, changes: 1
Writing U-Boot environment to /dev/mtd1
Done

Ab da war alles gut:
Es bootete das OpenWRT und ich konnte mit dem:
gluon-ffmsd06-v2016.1.1+1.0.2-ubiquiti-picostation-m-sysupgrade.bin
Umsetzten zur Freifunk Firmware.

Währe wahrscheinlich auch einfacher gegangen aber nun den, das Ergebnis zählt.

Danke für den Tip, dadurch bin ich auf die Idee mit den Umweg über die offizielle OpenWRT Firmware gekommen.


TFTP Modus für Picostation
#8

Hier ein Auschnitt einer Mail die ich gerade bekam:

“die Pico läuft wieder. Mein Kollege hat noch ein paar Tests gemacht und konnte das Verhalten rekonstruieren: Mit einer AirOS 5.5.2 funktioniert alles einwandfrei, mit der 5.6.3 tritt das von mir geschilderte Verhalten auf, dass die Settings nicht gespeichert werden können – sprich die aktuelle Firmware ist definitiv NICHT mit dem 5.6er AirOS komaptibel!!!”


#9

Also das heißt, wenn man die Pico mit der neuen Hardwarerevision erst downgraded und dann Gluon aufspielt, geht es. Wenn man von AirOS 5.6.3 zu Gluon wechselt nicht?

Ich querverlinke das mal zum Gluon-Issue.


#10

@MPW Korrekt.


#11

Wie hoch ist der Standardwert für wireless.radio0.txpower in der aktuellen Firmware?

Ich hatte das Problem das mit den Standard Einstellung das WLan fiel zu stark ausgestrahlt hat.
Clients konnten sich nicht verbinden und schon höre ich “Freifunk” funktioniert nicht.
(Abgesehen von möglichen rechtlichen Problemen.)
Nachdem ich den Wert auf 8 Festgesetzt hatte war es besser aber noch nicht Optimal.
Ich habe jetzt eine Antenne von einem TL-WR1043N/ND auf der PicoStation und den wireless.radio0.txpower auf 6 festgesetzt. Soweit ich das Testen konnte passen nun Sende und Empfangsrichtung.

Kennt jemand den genauen Gewinn der TL-WR1043N/ND Antennen ?
Weiß jemand ob ich aktuell so noch unter den 20DB bin?

Sollte man in der Standardeinstellung nicht besser einen niedrigen Wert einstellen?
Sowie über die Web Config Werte bis 20DB?
Schließlich hätte das den Vorteil das man sich mit der Config beschäftigen muss um ihn höher einzustellen.


#12

Das ist ein bekanntes Problem mit den Picostations. Laut Hersteller haben sie eine 2 dBi-Antenne, aber die Geräte haben noch so einen proprietären Verstärker, von dem niemand so genau weiß, wie stark der ist.

Ich habe meine auf acht laufen, dann zeigt er mir zumindest 20 dBm an. Dass viele Handys nicht mit 20 dBm (=100 mW) senden, ist bekannt. Also wird es immer einen Bereich geben, wo sie das Netz sehen, aber nicht zurücksenden können. Es spricht aber nichts dagegen, sie noch weiter runterzudrehen.

Grüße
Matthias