den mesh pro mit dem ap ac pro image?
das könnte man ja mal sagen, bzw. bei OpenWrt anleiern, damit es da eine „offizielle“ Unterstützung geben kann…
Das war uneindeutig formuliert: Bisher nur AC Mesh, keine Pros.
Hallo
ANMERKUNG/HINWEIS zur AC-Mesh:
Seit dem Update auf unsere neue Firmware 0.9.4 (GLUON 2017.1.7) bei Freifunk Lippe, haben einige der AC-Mesh leider ein Soft-Brick erlitten.
Wir haben reproduzierbar ermittelt, das es mit der vorinstallierten Stock Firmware zutun hat.
Alle Knoten die eine Firmware vor der Version 3.7.58 installiert hatten wurden beim Update gebrickt.
Die Versionen 3.7.58 und 3.8.3 hingegen funktionieren einwandfrei zum flashen der Freifunk Firmware.
Falls einer ähnliche Probleme hat, braucht nicht lange suchen.
Wir haben das hier noch einmal festgehalten.
5 „Gefällt mir“
Eure Analyse des Problems und die Anleitung zur Lösung sind fehlerhaft.
Bitte orientiert euch an der Flashanleitung (insbesondere bzgl. boot select partition), die im OpenWrt Wiki¹ dokumentiert wurde. Alternativ gibts auch noch unsere Anleitung, wir hatten damals das Problem erkannt und uns um eine Lösung bemüht.
7 „Gefällt mir“
Danke für den Tip mit dem „Bootselect schreiben“!
Wir werden es in unsere Anleitung mit aufnehmen.
Die Anleitung stammt zum Teil auch aus der UBNT Dokumentation.
Diese in vielen Anleitungen, immer so angepriesenen Version hatten wir vorher auch installiert
Wie in unserer Anleitung geschrieben ist die FW 3.7.40 definitiv die falsche FW. Ich habe das nicht nur so dort rein geschrieben, dass es (in Verbindung mit GLUON 2017.1.7) mit einer Stock Firmware älter als die 3.7.58 zum Soft-Brick führt.
Aber wer will, kann es ja gerne ausprobieren…
Kann man das bootselect-Schreiben auch noch unter Gluon per SSH nachholen? Ich habe da ein paar Geräte gefläscht und will vermeiden da hinfahren zu müssen, wenn das nächste Firmwareupdate kommt.
Der Logik nach sollte das möglich sein, oder?
Betroffene AC-Lite / Mesh kannst du mit einem neueren Gluon in der tat aus der Ferne fixen, der commit befindet sich im Master und wohl auch in einem der letzten 2017.x Releases. 
Bei Gluon 2016.x ist die partition read-only, weshalb man dort bei falsch gesetztem Bootselect leider vor Ort ran muss und den Weg über die Stock Firmware nehmen muss.
1 „Gefällt mir“
Vermutlich ist unsere Firmware zu alt 
root@HAW-Gluon-Nord:~# cat /proc/mtd | grep bs
mtd7: 00020000 00010000 "bs"
root@HAW-Gluon-Nord:~# dd if=/dev/zero bs=1 count=1 of=/dev/mtd7
dd: can't open '/dev/mtd7': Permission denied
Dann müssen wir die wohl doch vor Ort fläschen.
Die gleiche Meldung hatte ich auch.
Heißt also: wieder auf Ubiquiti Stockfirmware flashen, Kernel mit Freifunk Firmware ersetzen, bootselect schreiben und Knoten neu einrichten?
Oder so…
Stockfirmware flashen, bootselect schreiben, Freifunk Firmware…
Die 3.7.58 oder 3.8.3 sollte es tun.
Genau. Wenn noch ein Knoten davor hängt, sollte das per SSH und Portforwarding möglich sein.
Habe heute eine Halterung für die Unifi AC Mesh gebaut.
Material:
- Tischklemme (im Sperrmüll gefunden)
- Ubiquiti Wandhalterung für die Unifi AC Mesh
- 2 M4 Schrauben + Muttern
14 „Gefällt mir“
Bei meinen UniFi AC Mesh ist auch eine ältere Gluon-FW drauf.
Daher wollte ich irgendwie rausfinden, ob ich mir vor einem anstehenden Gluon-Firmware-Update evtl. die Prozedur des temporären Flahens einer alten Stock-FW ersparen kann.
Nach meinem Verständnis hängt es ja an dem ersten Byte der Partition /dev/mtd4 bzw. /dev/mtd7.
- erstes Byte == 0 → Alles ist gut
- erstes Byte != 0 → Ich brauche temporär eine alte Stock-FW.
Den Test (bei mir /dev/mtd7) habe ich mit Hilfe von head und xxd durchgeführt (xxd muß dafür mit opkg nachinstalliert werden):
root@Freifunk:~# head -c 1 /dev/mtd7 | xxd
0000000: 00
Wie es aussieht, dann bräuchte ich bei meinem Router wohl nicht den Weg über eine alte Stock-FW gehen. Sehe ich das richtig?
2 „Gefällt mir“
Sehr geile Idee! Deine Logik klingt vernünftig, dem würde ich mich anschließen, auch wenn ich kein Profi auf dem Gebiet bin.
Meine haben auch alle Null im ersten Sektor. Ist dir schon eine begegnet, wo das nicht so war?
In der oben aufgeführten „Anleitung“ zum flashen der UAP-AC-M ist ein Schönheitsfehler drin, welcher in meinen Versuchen bei 3 von 6 Geräten dazu geführt, dass ich diese debricken musste.
Deine Commands führen nach dem schreiben des kernel0 gleich einen reboot durch. Es wird dann ein Lottospiel, ob der UAP-AC-M dann in kernel1 bootet oder nicht. Besser wäre es, wenn man den reboot (-r) weglässt und manuell bootet, nach dem der bootselect geschrieben ist.
mtd write /tmp/firmware.bin kernel0
mtd write /tmp/firmware.bin kernel1
Darüber hinaus sollte man noch den bootselect neu schreiben:
cat /proc/mtd | grep bs
dd if=/dev/zero bs=1 count=1 of=/dev/mtdX
reboot
Eine gute und detailierte Beschreibung habe ich hier gefunden: Ubiquiti UniFi AC MESH - Funk & Router - Freifunk Lippe
4 „Gefällt mir“
Die verlinkte Anleitung von Freifunk Lippe wurde scheinbar von uns übernommen, leider ohne die Lizenz CC-BY-SA zu beachten.
2 „Gefällt mir“
Kann man das evtl zusammenfassen in? (Ohne von Hand was ändern zu müssen)
dd if=/dev/zero bs=1 count=1 of=/dev/mtd$(cat /proc/mtd|grep bs|cut -c4)
Habe gerade kein Gerät zum Ausprobieren hier.
Vielen Dank für den Hinweis, ich habe die Anleitung geändert. Es gab auf der Seite auch schon einen entsprechenden Kommentar.
Bruno
Leider versagt hier die „EDIT Funktion“ (Beitrag zu alt?) sonst würde ich dort „-r“ entfernen…
Daher habe ich den Beitrag an die Moderation gemeldet. Ist da auch in der queue, müssten sich halt nur mal drum kümmern @moderatoren