Posts Tagged ‘Aktualisierung’

Dienstag, 9. Mai 2023

UniFi Firmware down- oder upgraden

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

Sonntag, 10. Juni 2018

Turris Omnia: Probleme mit pkgupdate debuggen

Mein Turris Omnia verwendet seit einiger Zeit das Kommandozeilentool pkgupdate, um sich zu aktualisieren (früher hatte diese Aufgabe offenbar ein Script namens updater.sh).

Gegen Ende dieser Woche wurde ich auf Grund eines nicht (mehr) existierenden Paketes regelmässig mit E-Mails eingedeckt, dass beim Update etwas fehlgeschlagen sein.

Beim Debuggen des Problems, welches ich in einem anderen Blog-Post beschreiben möchte, biss ich mir für einige Minute die Zähne an pkgupdater aus.

Gemäss Hilfe kann man mit dem Parameter -e die Verbosität des Tools einstellen:

$ pkgupdate --help
Usage: pkgupdate [OPTION]...
--help, -h			Prints this text.
--version, -V			Prints version of updater.
-R 			Use given path as a root directory. Consider also using --out-of-root option.
--batch				Run without user confirmation.
--state-log			Dump state to files in /etc/updater-state directory.
--ask-approval=	Require user's approval to proceed (abort if --approve with appropriate ID is not present, plan of action is put into the report-file if approval is needed)
--approve=			Approve actions with given ID (multiple allowed, from a corresponding report-file).
-s 		What level of messages to send to syslog.
-e 		What level of messages to send to stderr.
-S 		Under which name messages are send to syslog.
--task-log=		Append list of executed tasks into a log file.
--usign=			Path to usign tool used to verify packages signature. In default /usr/bin/usign.
--no-replan			Don't replan. Install everyting at once. Use this if updater you are running isn't from packages it installs.
--no-immediate-reboot		Don't reboot immediatelly. Just ignore immediate reboots. This is usable if you are not running on target machine.
--out-of-root			We are running updater out of root filesystem. This implies --no-replan and --no-immediate-reboot and is suggested to be used with -R option.

Doch was sind stderr Levels? Über eine Google-Suche stiess ich auch folgenden Kommentar zu einem völlig anderen Software-Produkt — sounds about right:

...
levels: {
  error: 3,
  warning: 4,
  notice: 5,
  info: 6,
  debug: 7,
},
...

Quelle: ‚debug‘ level is getting directed to stderr instead of stdout

debug war der Verbositäts-Level, welchen ich gesucht hatte. Versuchen wir es:

$ pkgupdate -e 7
DIE:Unknown log level 7
Aborted

Hmmm. Dann halt ausgeschrieben:

$ pkgupdate -e debug
DIE:Unknown log level debug
Aborted

Och Menno. Vielleicht dann alles in Grossbuchstaben?

$ pkgupdate -e DEBUG
DIE:Unknown log level DEBUG
Aborted

Himmelarsch! Zurück zu Google. Bei einem Gitlab-Checkin der Entwickler des Turris Omnia fand ich im Diff für das vorherige Script folgenden Hilfetext:

...
echo "-e (ERROR|WARNING|INFO|DBG|TRACE)	Message level printed on stderr. In default set to INFO."
...

Quelle: Store only single approved state

Somit lautet die korrekte Schreibweise:

# pkgupdate -e DBG

Und tatsächlich, damit klappte es.

Tags: , , , , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Mittwoch, 14. Dezember 2016

Das in Chrome eingebettete Flash-Plugin aktualisieren

Die Aktualisierung von Chrome kann man anstossen, indem man den Browser startet und danach die Adresse

chrome://help/

ansurft.

Um die Aktualisierung des in Chrome integrierten Flash-Plugins anzustossen, startet man den Browser und surft man die folgende Adresse an:

chrome://components/

Dort sucht man den Eintrag „Adobe Flash Player“ und klickt auf den Button „Check for updates“:

Tags: , , , , , ,
Labels: IT

2 Kommentare | neuen Kommentar verfassen