Posts Tagged ‘Firmware’

Montag, 3. Juli 2023

ConBee II USB-Stick wird nach Debian-Update nicht mehr erkannt

Link zu diesem Artikel

Nach einer Stunde debugging, USB-Stick ausstöpseln, einstöpseln und dutzende Male Firmware flashen entdecke ich endlich After a sudo apt update && sudo apt full-upgrade and a reboot deconz no longer connects to the conbee 2:

Das heute Vormittag eingespielte Debian-Update löscht /dev/serial/by-id/*. Dies verhindert offenbar, dass deCONZ Phoscon den USB-Stick findet. Das Problem erkennt man auch daran, dass folgender Befehl nichts findet:

# GCFFlasher_internal -l
GCFFlasher V3_17 (c) dresden elektronik ingenieurtechnik gmbh
Path             | Vendor | Product | Serial     | Type
-----------------+--------+---------+------------+-------

Auf einem Raspberry Pi mit existierendem /dev/serial/by-id/* schaut das hingegen noch so aus:

# GCFFlasher_internal -l
GCFFlasher V3_17 (c) dresden elektronik ingenieurtechnik gmbh
Path             | Vendor | Product | Serial     | Type
-----------------+--------+---------+------------+-------
/dev/ttyAMA0     | 0x0000 | 0x0000  |            | RaspBee 
/dev/ttyACM0     | 0x1CF1 | 0x0030  | DE1234567  | ConBee II

Die Lösung: In deconz.service einfach noch das USB-Device mitgeben: ExecStart=/usr/bin/deCONZ ... --dev=/dev/ttyACM0. ttyACM0 ersetzt man mit dem tatsächlichen Device (findet man mittels dmesg gleich nachdem man es eingestöpselt hat).

Danach den Service stoppen, neu starten — und dann sollte die ZigBee-Welt wieder in Ordnung sein (der Ausfall des USB-Sticks während zwölf Stunden machte es nötig, dass ich bei vielen Sensoren kurz den Knopf manuell drücken musste, um sicherzustellen, dass die Verbindung und Datenanlieferung noch funktioniert …)

Wichtig: dmesg muss den USB-Stick erkennen …

...
[55209365.334638] usb 2-3: new full-speed USB device number 15 using xhci_hcd
[55209365.488837] usb 2-3: New USB device found, idVendor=1cf1, idProduct=0030, bcdDevice= 1.00
[55209365.493029] usb 2-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[55209365.497062] usb 2-3: Product: ConBee II
[55209365.501528] usb 2-3: Manufacturer: dresden elektronik ingenieurtechnik GmbH
[55209365.505835] usb 2-3: SerialNumber: DE1234567
[55209365.512617] cdc_acm 2-3:1.0: ttyACM3: USB ACM device
...

… und mit lsusb muss er auch aufgeführt sein — sonst könnte ein anderes Problem vorliegen:

...
Bus 002 Device 013: ID 1cf1:0030 Dresden Elektronik ZigBee gateway [ConBee II]
...

In der Zwischenzeit hatte ich alles ausprobiert, insbesondere dutzende Male das Firmware geflashed. Hierzu habe ich die ZIP-Datei des neuesten (Beta) Release 4.0.4 von gcfflasher heruntergeladen und auf zwei Linux-PCs sowie macOS entpackt.

Um den Flasher zu kompilieren, installiert man unter Debian zuerst die benötigten Pakete (unter macOS geht’s gleich weiter zur Kompilation):

# apt-get install pkg-config build-essential libgpiod-dev

Danach kompiliert man das Binary:

./build_posix.sh

Anschliessend lädt man die neueste Firmware vom offiziellen Server in das Flasher-Verzeichnis herunter, und gibt dann unter Linux ein:

# ./GCFFlasher -d /dev/ttyACM3 -t 60 -f ./deCONZ_ConBeeII_0x26780700.bin.GCF

Unter macOS lautete der Befehl:

# ./GCFFlasher -d /dev/cu.usbmodemDE1234567 -t 60 -f ~/tmp/deCONZ_ConBeeII_0x26780700.bin.GCF

Auch hier wieder beachten, das effektive Device (unter Linux war es bei mir auf einem Laptop /dev/ttyACM0, auf dem anderen /dev/ttyACM3; unter macOS war es /dev/cu.usbmodemDE24421441) mitzugeben. Dass der Flasher richtig funktioniert, seht ihr, wenn folgende Ausgabe erscheint:

read file success: ./deCONZ_ConBeeII_0x26780700.bin.GCF (163244 bytes)
flash firmware
command reset done
query bootloader id V1
bootloader detected (60)
 100 %ding ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
done, wait validation...
firmware successful written

Manchmal auch

read file success: ./deCONZ_ConBeeII_0x26780700.bin.GCF (163244 bytes)
flash firmware
command reset done
query bootloader id V1
bootloader detected (60)
bootloader syned: unlock! READY
 100 %ding ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
done, wait validation...
firmware successful written

Den Diskussionsforen entnehme ich zudem, dass es vorkommen kann, dass das System den USB-Stick „vergisst“. In dem Fall startet man den Firmware-Update-Befehl bevor man den USB-Stick überhaupt eingestöpselt hat. Während sich die Meldungen à la retry connect bootloader /dev/cu.usbmodemDE1234567 auf dem Bildschirm stapeln, stöpselt man den USB-Stick ein, und dann sollte das Firmware-Update umgehend beginnen.

Links

Tags: , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Dienstag, 9. Mai 2023

UniFi Firmware down- oder upgraden

Link zu diesem Artikel

Vor einigen Tagen habe ich meine zwei Ubiquiti UniFi FlexHD Access Points hier in der Attika-Wohnung auf die Firmwareversion 6.2.49 vom 14. Dezember 2022 aktualisiert.

Seitdem hatte ich zunehmend Probleme mit der WLAN-Performance (bspw. bei Google Meets). Zudem stellten sich auch allgemeine Verbindungsprobleme ein, welche primär meine Smart-Geräte betrafen: Xiaomi Yeelights, aber auch Shellys.

Bei Pings von meinem MacBook an die IP eines Servers sowie das interne Interface meines neuen Routers gab es immer wieder, ca. alle fünf bis zehn Pings, massive Ausschläge — statt 10 Millisekunden brauchte ein Ping dann 150 Millisekunden. Google Meets beschwerte sich entsprechend über eine schlechte Verbindungsqualität — etwas, was ich seit dem Bezug der Eigentumswohnung noch nie erlebt hatte.

Gegen Ende der Leidensperiode wuchs in mir die Vermutung, dass das Problem von den kürzlich aktualisierten Access Points herrühren musste. Ich fasste deshalb ein Downgrade ins Auge, und wurde rasch mit einer Anleitung fündig: How To Downgrade Or Update Unifi UAP Firmware.

Ich klickte mich zur UniFi-Web-Seite mit den Firmwares für die FlexHDs durch — und sah, dass es längst eine neuere Firmware gab: 6.5.28 vom 19. Februar 2023. Wieso hatte der Controller mir dieses Update nicht angeboten?

Im Releaselog dann die Lösung des Rätsels:

This release is currently stable/official for the following models, it’s still an RC for all other models:

  • AC-Lite/LR/Pro/M/M-PRO/IW
  • AC-HD/SHD/XG/BaseStationXG
  • IW-HD
  • U6-Pro/Mesh/IW/Extender/Enterprise/Enterprise-IW

Ok, statt downzugraden entschied ich mich, kurzerhand auf den Release Candidate upzugraden — vorwärts flicken, wie man in der Branche so schön sagt.

Nach einer Klickorgie hatte ich die URL zur Firmware: BZ.mt7621_6.5.28+14491.230127.2313.bin

Diese URL pflegte ich im lokalen UniFi Controller im Dialogfeld zur manuellen Firmware-Aktualisierung ein. Danach begann das Upgrade, und bange/lange Warten. Dann, nach ca. 178 respektive 259 Sekunden die Erlösung:

...
Request timeout for icmp_seq 259
64 bytes from 10.1.2.3: icmp_seq=187 ttl=64 time=73481.004 ms

...
Request timeout for icmp_seq 178
64 bytes from 10.1.3.4: icmp_seq=104 ttl=64 time=75304.876 ms

Die Firmware läuft nun seit mehr als 24 Stunden (fast) fehlerfrei. Einzig folgendes Gerät scheint am Vormittag Mittag ein Problem gehabt zu haben:

ICMP failed Service homepod-bedroom.home.emeidi.local 

	Date:        Tue, 09 May 2023 10:55:48
	Action:      alert
	Host:        HOST
	Description: ping test failed

Your faithful employee,
Monit
ICMP succeeded Service homepod-bedroom.home.emeidi.local 

	Date:        Tue, 09 May 2023 12:18:56
	Action:      alert
	Host:        HOST
	Description: ping test succeeded [response time 8.096 ms]

Your faithful employee,
Monit

Ob das wirklich auf die WLAN-Verbindung zurückgeführt werden kann, kann ich nicht eruieren.

PS: Etwas später kam mir der Gedanke, dass vielleicht auch einfach ein Reboot der Access Points ohne Firmware-Upgrade das Problem gelöst hätte … ich werde es nie erfahren.

Tags: , , , , , , , , , , , , ,
Labels: Uncategorized

Keine Kommentare | neuen Kommentar verfassen

Donnerstag, 2. Februar 2023

UAP-AC-PRO weigert sich, die Firmware zu aktualisieren

Link zu diesem Artikel

Komisches Problem am ersten des Monats: Wie üblich aktualisiere ich die Firmware meiner UniFi-Komponenten, welche ich an drei Standorten installiert habe. Einzig der UAP-AC-PRO weigert sich standhaft, das verfügbare Update einzuspielen: Im UniFi-Controller drücke ich auf Update, der Status wechselt zu Updating… — nur um ca. 30 Sekunden später auf Update zurückzufallen. Gefühlte zehn Mal klicke ich den Link, doch es tut sich nichts. Endlosschlaufe, Ground Hog Day!

Nun gut. Ich sage dem Access Point in derselben Oberfläche, dass er sich neu starten sollen. Nachdem die Pings auch zwei Minuten nach dem Neustart ins Leere laufen, beginne ich mir, sorgen zu machen. Schlussendlich sind es fünf Minuten, und das Gerät ist immer noch nicht hochgekommen. Irgendwas ist hier faul!

Ich überlege mir schon, den Bekannten am anderen Standort anzurufen und zu bitten, das Netzwerkkabel vom PoE-Switch zum Access Point kurz auszuziehen. Doch das kann ich ja auch machen — virtuell, aus der Ferne. Ich gehe in die Port Management-Oberfläche des Switches, und klicke auf Power Cycle PoE. Der Port wird grau, und dann wieder grün, und das Stromsymbol (der Blitz) erscheint wieder.

Nach ein paar dutzend Sekunden werden die Pings endlich beantwortet, und der Access Point ist in der Oberfläche nicht mehr ausgegraut. Ein letztes Mal klicke ich auf Update — und tatsächlich: Nach dem Neustart lässt sich das Firmware-Update problemlos durchführen. Das letzte UniFi-Gerät in meinem Fuhrpark wurde nun doch noch aktualisiert.

Tags: , , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Dienstag, 26. April 2022

Firmware des MagSafe Battery Packs aktualisieren

Link zu diesem Artikel

Apple hat kürzlich ein Firmware-Upgrade 2.7.0 für sein MagSafe Battery Pack veröffentlicht, welches die Ladegeschwindigkeit von 5 Watt auf 7.5W erhöht.

MacRumors hat darüber berichtet und ein How To veröffentlicht.

Die Firmware aktualisiert man am Besten, indem man das Battery Pack mit einem Lightning-auf-USB-C-Kabel an einen Mac oder ein iPad anschliesst. Ausser anschliessen kann man nichts tun; das Update wird vom Betriebssystem anschliessend selbständig eingespielt.

Beim Battery Pack meiner Frau (Firmware-Version: 2.5.0b) klappte das Upgrade innert 1-2 Minuten nachdem ich es an mein MacBook Air M1 angeschlossen hatte.

Mein Battery Pack (Firmware-Version: 2.0.2c) hing mit demselben Kabel für ca. 15 Minuten an meinem Mac mini M1 (macOS Monterey 12.3.1), ohne dass sich etwas tat. Danach schloss ich es an das MacBook Air (macOS Big Sur 11.6.5) an, doch auch hier tat sich nach 10 Minuten nichts.

Ohne grosse Hoffnung schloss ich das Battery Pack schlussendlich noch an ein Lightning-auf-USB-A-Kabel an, welches am Thinkvision-Monitor meines Arbeitgebers angeschlossen ist. Der Monitor ist mit Thunderbolt/USB-C an einem älteren MacBook Pro (macOS Big Sur 11.6.5) angehängt.

Und siehe da: Nachdem ich einige Emails beantwortet hatte und das Battery Pack vergessen hatte, öffnete ich nach ungefähr 5-10 Minuten Apfel-Menu > About this Mac > System Report > USB, wählte das MagSafe Battery Pack in der Liste aus, und siehe da:

MagSafe Battery Pack:

  Product ID:	0x1399
  Vendor ID:	0x05ac (Apple Inc.)
  Version:	27.0b
  Serial Number:	DL2FJGDE0NLJ
  Speed:	Up to 12 Mb/s
  Manufacturer:	Apple Inc.
  Location ID:	0x01100000 / 1
  Current Available (mA):	500
  Current Required (mA):	500
  Extra Operating Current (mA):	1900
  Sleep current (mA):	2400

Wieso der Version ein Punkt fehlt, ist mir schleierhaft. Als Originalversion stand in diesem Dialogfeld 20.2c, beim Battery Pack meiner Frau 25.0b.

Tipp: Wer den System Report geöffnet hat, kann mittels Apfel-R den Baum neu anzeigen lassen. Sollte die Firmware in der Zwischenzeit aktualisiert worden sein, spiegelt sich dass im Feld Version entsprechend wieder.

Sonstige Links: Diskussion bei Apfeltalk, Meldung bei Heise sowie Allgemeiner Support-Artikel von Apple.

Tags: , , , , , , , , , ,
Labels: Apple

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 30. Juni 2019

Irgendwas ist am UniFi Firmware 4.0.42.10433 nicht ganz koscher

Link zu diesem Artikel

Bis vor wenigen Wochen hatte ich nie irgendwelche Probleme mit Firmware-Upgrades für UniFi-Produkte. Das hat sich mit Version 4.0.42.10433 geändert: Ich verzeichne mindestens zwei Probleme mit diesem Upgrade.

DHCP funktioniert mit gewissen Geräten nicht mehr

Bei mir macht dieses Update auf einem UniFi AP-AC-Mesh wie auch auf einem UniFi AP-AC-LR im Zusammenspiel mit DHCP-Anfragen Probleme. Das Resultat: Die Geräte sind zwar im Controller sichtbar, können aber keine IP beziehen.

In der Controller-App für iOS sieht man bei solchen Geräten die Warnung:

„DHCP Timeout. Please check that your DHCP server is accessible and properly configured“

Die meisten Geräte wie Laptops, Smartphones und Tablets können mit DHCP IPs beziehen; Probleme haben derzeit nur zwei Geräte(typen) gemacht: Ein Canon Selphy sowie ein Industrieboard für einen Wechselrichter. Meine derzeitige Vermutung: Auf diesen Dingern läuft eine ältere Linux-Version und ein älterer DHCP-Client, der irgendwie nicht (mehr) mit Antworten des DHCP-Servers über UniFi-Komponenten klarkommt, oder UniFi blockiert Antworten auf DHCP-Requests dieser Clients aus irgendeinem Grund.

Das zeigt sich daran, dass in den DHCP-Server-Logs unzählige folgende Meldungen auftauchen:

...
Jun 30 18:16:31 DHCPSERVER dhcpd[19637]: DHCPOFFER on 10.1.2.225 to 00:00:00:00:00:00 (SELPHY_DHCP_INSTANCE_0) via eth0
Jun 30 18:17:36 DHCPSERVER dhcpd[19637]: DHCPDISCOVER from 00:00:00:00:00:00 (SELPHY_DHCP_INSTANCE_0) via eth0
Jun 30 18:17:37 DHCPSERVER dhcpd[19637]: DHCPOFFER on 10.1.2.225 to 00:00:00:00:00:00 (SELPHY_DHCP_INSTANCE_0) via eth0
Jun 30 18:18:42 DHCPSERVER dhcpd[19637]: DHCPDISCOVER from 00:00:00:00:00:00 (SELPHY_DHCP_INSTANCE_0) via eth0
Jun 30 18:18:43 DHCPSERVER dhcpd[19637]: DHCPOFFER on 10.1.2.225 to 00:00:00:00:00:00 (SELPHY_DHCP_INSTANCE_0) via eth0
Jun 30 18:19:48 DHCPSERVER dhcpd[19637]: DHCPDISCOVER from 00:00:00:00:00:00 (SELPHY_DHCP_INSTANCE_0) via eth0
Jun 30 18:19:49 DHCPSERVER dhcpd[19637]: DHCPOFFER on 10.1.2.225 to 00:00:00:00:00:00 (SELPHY_DHCP_INSTANCE_0) via eth0
Jun 30 18:20:54 DHCPSERVER dhcpd[19637]: DHCPDISCOVER from 00:00:00:00:00:00 (SELPHY_DHCP_INSTANCE_0) via eth0
Jun 30 18:20:55 DHCPSERVER dhcpd[19637]: DHCPOFFER on 10.1.2.225 to 00:00:00:00:00:00 (SELPHY_DHCP_INSTANCE_0) via eth0
Jun 30 18:22:00 DHCPSERVER dhcpd[19637]: DHCPDISCOVER from 00:00:00:00:00:00 (SELPHY_DHCP_INSTANCE_0) via eth0
Jun 30 18:22:01 DHCPSERVER dhcpd[19637]: DHCPOFFER on 10.1.2.225 to 00:00:00:00:00:00 (SELPHY_DHCP_INSTANCE_0) via eth0
Jun 30 18:23:06 DHCPSERVER dhcpd[19637]: DHCPDISCOVER from 00:00:00:00:00:00 (SELPHY_DHCP_INSTANCE_0) via eth0
Jun 30 18:23:07 DHCPSERVER dhcpd[19637]: DHCPOFFER on 10.1.2.225 to 00:00:00:00:00:00 (SELPHY_DHCP_INSTANCE_0) via eth0
Jun 30 18:24:12 DHCPSERVER dhcpd[19637]: DHCPDISCOVER from 00:00:00:00:00:00 (SELPHY_DHCP_INSTANCE_0) via eth0
Jun 30 18:24:13 DHCPSERVER dhcpd[19637]: DHCPOFFER on 10.1.2.225 to 00:00:00:00:00:00 (SELPHY_DHCP_INSTANCE_0) via eth0
Jun 30 18:25:18 DHCPSERVER dhcpd[19637]: DHCPDISCOVER from 00:00:00:00:00:00 (SELPHY_DHCP_INSTANCE_0) via eth0
Jun 30 18:25:19 DHCPSERVER dhcpd[19637]: DHCPOFFER on 10.1.2.225 to 00:00:00:00:00:00 (SELPHY_DHCP_INSTANCE_0) via eth0
Jun 30 18:26:24 DHCPSERVER dhcpd[19637]: DHCPDISCOVER from 00:00:00:00:00:00 (SELPHY_DHCP_INSTANCE_0) via eth0
...

Syslog geflutet

Der UniFi AP-AC-Mesh an einem Standort brachte meinen ELK-Cluster für das Sammeln von Syslog-Meldungen aus allen Sites fast zum Glühen, nachdem die neue Firmware installiert war und der Access Point neu gebootet hatte.

Das Gerät sendete folgende Meldung 29 Mal pro Sekunde an den Syslog-Server:

<4> Jun 10 16:00:00 unifi.site.domain.local U7MSH,788a20263e00,v4.0.42.10433 kernel: [103146.842183] [wifi1] FWLOG: [105639111] VDEV_MGR_DEBID_DEFINITION_START ( 0x3, 0x40, 0x1, 0x6 )

Sobald ich wieder die alte Firmware (4.0.21.9965) installiert hatte, hörte die Log-Flut auf.

In Kibana ist die Flutwelle gut ersichtlich …

… welche sich auch in der CPU-Auslastung wiederspiegelt:

Auch Smokeping zeigt, dass das Gerät mit dem neuen Firmware eine deutlich höhere Latenz bei ICMP Ping Requests aufweist:

Ein anderer Benutzer hatte dieses Phänomen bereits im März 2019 beobachtet und dies in einem Beitrag im offiziellen Support-Forum kundgetan: WAL_DBGID_SECURITY_ALLOW_DATA and VDEV_MGR_DEBID_DEFINITION_START — leider ohne Lösung.

Um das Problem ohne Downgrade des Firmwares zu beheben, habe ich meine rsyslog-Konfiguration, welche die Meldungen lokal in Empfang nimmt und an ELK weiterleitet, folgendermassen angepasst:

/etc/rsyslog.conf

...
# EMERGENCY 2019-06-10
if $msg contains 'VDEV_MGR_DEBID_DEFINITION_START' then {
    /dev/null
    stop
}

# Send all logs to ELK server
*.* @10.1.2.3:514
...

Tags: , , , , , ,
Labels: IT

1 Kommentar | neuen Kommentar verfassen