Posts Tagged ‘UniFi’

Dienstag, 5. August 2025

Gelöst: Das Mysterium der nicht adoptierbaren UniFi Switches

Link zu diesem Artikel

TL;DR

Das ist der verfluchte Übeltäter: UniFis DHCP Guarding

Wie üblich in der IT eine eigentlich gut gemeinte Sicherheitsfunktion, die mich unzählige Stunden an Debugging gekostet hat:

Aus irgendeinem Grund war diese Funktion auf dem UniFi Controller, welcher früher bei einer Bekannten in Gebrauch war, aktiviert. Und nicht nur aktiviert, auch die eingetragene IP des DHCP-Servers stimmte nicht; anstelle des Servers war das Gateway eingetragen, welches hier keine DHCP-Funktionen (mehr?) ausübt.

Problembeschreibung

Seit dem Bezug der Wochenaufenthalter-Wohnung in Zürich hatte ich ein nerviges Problem:

Mir gelang es seinerzeit nicht, zwei gebrauchte, aktuell nicht mehr im Einsatz befindliche UniFi-Switches vom Typ US-8 und US-8-60W mit einem auf einem Debian Server laufenden UniFi Controller zu koppeln. Sie tauchten im nicht-adoptierten Zustand im Netzwerk auf, erhielten vom auf dem Linux-Server laufenden DHCP eine IP zugewiesen (static leases basierend auf deren MAC-Adresse) und erschienen im UniFi Controller als adoptierbare Geräte. Ich konnte die Switches anpingen. Doch sobald ich den Switch adoptierte, dauerte es ein paar Minuten, dann hiess es „Adoption failed“, der Switch zeigte im UniFi Controller die IP 192.168.1.20 und konnte nicht mehr angepingt werden. Da ich ursprünglich den Access Point auch noch hinter dem Switch betrieb, verlor dieser dann lustigerweise auch die Verbindung zum Netzwerk (rückblickend ein Indiz auf das zu Grunde liegende Problem, aber dazu später mehr).

In dieser Situation, in welche ich mich sicherlich ein gutes dutzend Mal hineinmanövrierte, half dann jeweils nur der physische Reset des Switches: Mit einer Büroklammer drückte ich auf den Reset-Knopf, hielt den 10 Sekunden gedrückt, und nach dem loslassen starte der Switch den Factory Reset.

Im UniFi Controller gab ich beim Switch dann den Befehl, diesen zu vergessen („Forget“), und schlussendlich tauchte der Switch irgendwann wieder in jungfräulicher Form in der Liste auf.

Erneuter Versuch

Gestern verschob ich aus Lärmgründen das kleine 1-Disk Synology NAS vom Router in die andere Ecke der Wohnung, weshalb ich es intelligent fand, in der Ecke auch einen der beiden Switches zu installieren — zumal ich in der Ecke auch den UniFi U6-LR platziert habe, der bis dahin von einem PoE-Injektor beim Router gespeist wurde.

Einschub: Der US-8-60W (!) liefert auf seinen PoE-Ports nicht ausreichend Strom, um einen U6-LR mit Strom zu versorgen. Dies führt dazu, dass der Access Point regelmässig abstürzt und im UniFi Controller eine entsprechende Warnmeldung aufpoppt. Somit verwende ich bis zur Ankunft des USW-Lite-8-POE weiterhin den PoE Injector. Hässlich, aber als temporärer Workaround machbar.

Selbstverständlich endete ich innert weniger Minuten wieder in der oben beschriebenen Situation.

Das Debugging begann erneut — dieses Mal wollte ich das Problem ein für allemal nachhaltig lösen.

Wirklich Factory Reset?

Waren die Geräte wirklich auf die Werkseinstellungen zurückgesetzt? Wie ich nach einer Weile herausfand, ist das ganz einfach zu überprüfen: Die Switches sind im nicht-adoptierten Zustand per SSH zu erreichen. Wenn in Werksteinstellungen, kann man sich mit folgenden Daten einloggen:

  • Benutzernamen: ubnt
  • Kennwort: ubnt

Das funktionierte in der Tat mit beiden Switches. Um ganz sicherzugehen kann man — ist man erst einmal eingeloggt — noch folgenden Befehl ausführen:

# set-default
Clearing CFG ... [%100] done!
syswrapper: restart triggered by restore-default

Dies hat denselben Effekt wie man den Switch physisch mit der Büroklammer zurücksetzt.

Ist der Controller erreichbar?

Ist man auf dem Switch eingeloggt, kann dem Switch sagen, wo sich der UniFi Controller befindet:

# set-inform "http://1.2.3.4:8080/inform"
Adoption request sent to 'http://1.2.3.4:8080/inform'.  Use UniFi Network to complete the adopt process.

Die URL kann man auch in einem Browser öffnen, und es sollte einem keine Fehlermeldung entgegenstarren.

Das war hier der Fall, ich sah ein leeres, weisses Browser-Fenster, was signalisiert, dass der Server antwortet.

Leider macht dieser Befehl nichts; er dient dazu, das Gerät mit dem UniFi Controller bekannt zu machen, wenn dieses aus irgendeinem Grund nicht automatisch auftaucht.

Zu neue Switch Firmware mit altem Controller?

Irgendwann entdeckte ich mit Schrecken, dass die Switches zwar auf der neuesten verfügbaren Firmware liefen (7.1.26, gemass UniFi Controller, aber auch der Shell-Linie), doch der UniFi Controller noch auf Version 7 festsass. Aktuell ist Version 9.

Es folgte ein langwieriges, stundenlanges Upgrade, welches ich hier nicht im Detail beschreiben möchte. Nur soviel: Zuerst musste ich von Bullseye auf Bookworm aktualisieren. Dann musste ich MongoDB Paketverzeichnis vom Hersteller direkt einbinden, nur um zu realisieren, dass die CPU des Lenovo ThinkPads, auf welchem Debian läuft, den AVX Befehlssatz nicht unterstützt, welcher seit MongoDB 5 benötigt wird. Nach einem gescheiterten Selbstkompilationsversuch fand ich dann einen Weg, um das letzte kompatible MongoDB-Release (4.4.26) zu installieren. Danach musste ich UniFi mit einem Backup migrieren, sowie viele andere Services, welche wegen dem Upgrade kaputt gegangen waren.

Nur um schlussendlich zu realisieren, dass das Adoptionsproblem auch weiterhin bestand.

DHCP-Logs

Der Lösung (unbewusst) näher kam ich, als ich auf dem Debian Server die DHCP-Logs genauer anschaute. Dort sah ich nach der Adoption im Sekundentakt folgende Einträge:

...
Aug  4 04:25:03 SERVER dhcpd[212067]: DHCPDISCOVER from 00:11:22:33:44:55 via eth0
Aug  4 04:25:03 SERVER dhcpd[212067]: DHCPOFFER on 1.2.3.4 to 00:11:22:33:44:55 via eth0
Aug  4 04:25:06 SERVER dhcpd[212067]: DHCPDISCOVER from 00:11:22:33:44:55 via eth0
Aug  4 04:25:06 SERVER dhcpd[212067]: DHCPOFFER on 1.2.3.4 to 00:11:22:33:44:55 via eth0
Aug  4 04:25:09 SERVER dhcpd[212067]: DHCPDISCOVER from 00:11:22:33:44:55 via eth0
Aug  4 04:25:09 SERVER dhcpd[212067]: DHCPOFFER on 1.2.3.4 to 00:11:22:33:44:55 via eth0
Aug  4 04:25:22 SERVER dhcpd[212067]: DHCPDISCOVER from 00:11:22:33:44:55 via eth0
Aug  4 04:25:22 SERVER dhcpd[212067]: DHCPOFFER on 1.2.3.4 to 00:11:22:33:44:55 via eth0
Aug  4 04:25:25 SERVER dhcpd[212067]: DHCPDISCOVER from 00:11:22:33:44:55 via eth0
Aug  4 04:25:25 SERVER dhcpd[212067]: DHCPOFFER on 1.2.3.4 to 00:11:22:33:44:55 via eth0
Aug  4 04:25:28 SERVER dhcpd[212067]: DHCPDISCOVER from 00:11:22:33:44:55 via eth0
Aug  4 04:25:28 SERVER dhcpd[212067]: DHCPOFFER on 1.2.3.4 to 00:11:22:33:44:55 via eth0
Aug  4 04:25:41 SERVER dhcpd[212067]: DHCPDISCOVER from 00:11:22:33:44:55 via eth0
Aug  4 04:25:41 SERVER dhcpd[212067]: DHCPOFFER on 1.2.3.4 to 00:11:22:33:44:55 via eth0
Aug  4 04:25:44 SERVER dhcpd[212067]: DHCPDISCOVER from 00:11:22:33:44:55 via eth0
Aug  4 04:25:44 SERVER dhcpd[212067]: DHCPOFFER on 1.2.3.4 to 00:11:22:33:44:55 via eth0
Aug  4 04:25:47 SERVER dhcpd[212067]: DHCPDISCOVER from 00:11:22:33:44:55 via eth0
Aug  4 04:25:47 SERVER dhcpd[212067]: DHCPOFFER on 1.2.3.4 to 00:11:22:33:44:55 via eth0
Aug  4 04:26:00 SERVER dhcpd[212067]: DHCPDISCOVER from 00:11:22:33:44:55 via eth0
Aug  4 04:26:00 SERVER dhcpd[212067]: DHCPOFFER on 1.2.3.4 to 00:11:22:33:44:55 via eth0
...

Der Switch versuchte verzweifelt, ein DHCP-Lease zu kriegen, aber aus irgendeinem Grund kam die Antwort nicht beim Switch an. Das war auch die Erklärung dafür, weshalb der Switch sich die UniFi Standard-IP 192.168.1.20 zuteilte, wenn dann zum Tragen kommt, wenn der Switch keine IP beziehen kann.

AppArmor

Bei BIND- und DHCP-Problemen mit Debian kann auch immer AppArmor das Problem sein. Da sich dieser Service schlecht deinstallieren lässt (respektive er sich irgendwie immer wieder selber installiert), ist es besser, mit entsprechender Konfiguration dafür zu sorgen, dass nur gewarnt, und nicht geblockt wird. Auf dem Server habe ich diese Einstellungen aktiv. Ich führte das Script zur Sicherheit noch einmal aus, doch das änderte leider nichts an der Sache.

Irgendwann gab ich auf und ging schlafen.

Die Lösung

Heute wählte ich mich mit Wireguard aus der Ferne in das Netzwerk ein, um im UniFi Controller etwas nachzuschauen. Aus irgendeinem Grund endete ich in den Netzwerk-Einstellungen, und … da starrte mich plötzlich die Option DHCP Guarding an.

Auf einmal war alles klar: Diese Scheiss-Funktion wird auf UniFi-Geräten erst aktiv, wenn man es adoptiert und die Konfiguration ausgerollt hat. In meinem Fall führte dies dazu, dass der Switch sich selber ins Knie schoss, sprich: Er verlangte vom DHCP-Server eine IP, doch diese Schutzfunktion verhinderte, dass der Switch die zugeteilte IP erhielt und konfigurieren konnte. Absolut schizophren.

Nicht nur das: Jetzt war mir auch klar, was mit den am Switch angeschlossenen Geräten passierte — sei es NAS, aber auch Access Point. Diese Geräte fragten beim DHCP-Server auch nach IPs an, doch die Pakete wurden vom Switch blockiert und kamen dementsprechend nicht bei den Endgeräten an. Nicht nur das — da am Switch zu Testzwecken noch der zweite Switch hing, und der Access Point, fielen diese alle zusammen auf 192.168.1.20 zurück. Das bedeutete, dass ich im Netzwerk insgesamt drei Geräte mit derselben nicht routbaren IP hatte.

Heute Abend kam ich nach Hause, deaktivierte die DHCP Guarding-Funktionalität, adoptierte zuerst einen Switch — was innert 1–2 Minuten erfolgreich war, und anschliessend noch den zweiten Switch. HALLELUJA!

(Nicht hilfreiche) Links

Tags: , , , , , , , , , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Mittwoch, 4. September 2024

UniFi-Geräten über den UniFi Controller eine fixe IP zuweisen (DHCP Static Lease)

Link zu diesem Artikel

Gestern habe ich das Heimnetzwerk eines Bekannten komplett neu aufgebaut: Kabelmodem in den Bridge/Modem-Modus gesetzt, den dahinter installierten Asus-Router rausgerissen, und die zwei Orbi Mesh Access Points entfernt.

Stattdessen läuft in der Wohnung nun ein UCG-Ultra der direkt am Kabelmodem hängt, gefolgt von einem USW-Ultra-60W, welcher unter anderem drei U6-Mesh über PoE mit Daten und Strom versorgt.

Obwohl nicht zwingend wollte ich den UniFi-Netzwerkkomponente eine fixe IP zuweisen. Das ist im UniFi Controller gar nicht so einfach wie für Netzwerkclients wie Laptops und andere Geräte.

Die folgende Anleitung von Marc Schabacker funktioniert tadellos, und ich habe sie mit der gestrigen Installation bereits an zwei Standorten erfolgreich verwendet:

Static DHCP Reservations for Unifi Devices

Tags: , , , , , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 27. August 2023

UniFi Switch PoE-Probleme — und meine Lösung

Link zu diesem Artikel

Unser Haushalt ist komplett mit Ubiquiti UniFi Netzwerk-Hardware ausgerüstet.

Unter anderem hängt im Verteilschrank beim g.fast-Modem ein UniFi US-8-60W. Die Ports dieses Switches sind auf 5 Ports einer UniversMCS Hausverkabelung gepatcht, plus Modem, plus Powerline in den Keller und die Waschküche.

Unter anderem führt ein UniversMCS-Multimediakabel in das Wohnzimmer. Dort geht es von einer Bodenklappe mittels eines braunen Ethernet-Kabels (ähnliche Farbe wie das Parket) zu einem UniFi US-8 (ohne eigenes PoE). Dieses Kabel liefert mittels PoE Strom für den Satelliten-Switch. An diesem Switch hängt unter anderem der Apple TV und der Sony Bravia-Fernseher, sowie ein UniFi FlexHD Access Point. Den UniFi FlexHD versorge ich ebenfalls mittels PoE mit Strom, d.h. der Access Point ist am PoE-Passthrough-Port (Nummer 8) angesteckt und wird indirekt vom Verteilkasten mit Strom versorgt.

Problem: Jedes Mal, wenn ich die Firmware des Switches im Verteilkastens aktualisiere und sich dieser neu startet, ist der Satelliten-Switch offline. Nach viel, viel Rätseln, aus- und umstöpseln (zuerst dort, dann hier, dann hier, dann dort) hier die Symptombekämpfung meines Problems:

Sobald der Satellitenswitch tot ist, begebe ich mich in das Wohnzimmer, und ziehe ALLE Ethernet-Kabel aus. Anschliessend stecke ich zuerst das braune PoE-Kabel ein — und nur dieses. Dann warte ich, bis die weisse LED des Switches zu leuchten beginnt. Erst dann stecke ich die zwei anderen Netzwerkgeräte sowie den Access Point ein. Nach ein paar Minuten ist der Switch online, und der Access Point auch wieder.

An was das liegt weiss ich nicht genau, vermute aber, dass der Switch irgendwie nicht damit klarkommt, wenn der Switch und FlexHD gleichzeitig PoE-Strom ziehen.

Das Problem besteht seit unserem Bezug der Wohnung im Oktober 2021, und unzählige Firmware-Updates haben es nicht gelöst. Beim heutigen Firmware-Upgrade aller Komponenten schien das Problem vorerst nicht aufgetreten zu sein (der Wohnzimmer-Switch ging um 21:23 Uhr offline, um 21:25 Uhr war er wieder da) — doch um 00:35:30 Uhr ging der Switch plötzlich offline.

Nachtrag: Ein Kollege gab mir den entscheidenden Tipp: Kann es sein, dass der Switch nicht mehr hochkommt, weil zu viel Strom gezogen wird? Volltreffer.

Der UniFi Controller verfügt über ein Log, und was fand ich dort?

The device plugged into Verteiler (UniFi US-8-60W) Port 8 requires more power than the port can provide. Please connect it to a port capable of the required PoE output.
Learn more.

Meine Recherchen über die PoE-Fähigkeiten meiner Hardware haben ergeben:

  • Wie es die Typenbezeichnung des US-8-60W bereits sagt, kann der Switch über PoE total 60W bereitstellen.

  • Diese 60W können über 4 der 8 Ports geteilt werden (Ports 5, 6, 7 und 8).
  • Ein einzelner Port aber kann maximal 15.4W bereitstellen.
  • Das bedeutet, dass mein US-8 zusammen mit dem UniFi FlexHD im Wohnzimmer maximal 15.4W ziehen dürfen. Wenn sie mehr ziehen, schaltet sich der Port wohl ab, oder der Verbraucher (Access Point) kriegt kein Strom mehr.
  • Der US-8 benötigt maximal 12W für das Switching. In Realität sind es aber unter 5W, obwohl ich vermutlich auch noch messen sollte, wenn man über Apple TV HD-Content streamt.
  • 12W ist auch die maximale Leistung, die über den PoE-Passthrough ausgeben werden kann
  • Kann der Switch somit maximal 24W ziehen? Das würde mit dem Netzteil passen, welches 48V mit 0.5A bereistellt (24W).
  • Die aktuelle Leistung, die über den PoE-Port gezogen wird, lässt sich im UniFi-Controller für den US-8-60W und auch für den US-8 ansehen: Aktuell gerade 10.38W, mit dem von mir höchsten je gesehenen Wert von 11.49W.
  • Somit ist der US-8-60W nicht wirklich das Problem — er könnte 15.4W bereitstellen, doch der US-8 kann nur maximal 12W weiterleiten.

Ich überlege mir deshalb zwei Möglichkeiten:

  1. Den US-8-60W durch einen US-8-150W zu ersetzen, welcher hier noch herumliegt. Der deutlich grössere Switch erlaubt bis zu 34.2W pro Port (Quelle, im Tab Specifications). Ob das das Problem wirklich lösen wird, weiss ich nicht.
  2. Einen anderen PoE-Passthrough-Switch kaufen, welcher über den Passthrough-Port mehr als 12W bereitstellen kann.

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

Sonntag, 27. November 2022

UniFi kommt auf einem Debian 11 Bullseye nicht hoch

Link zu diesem Artikel

Da am Freitag die SSD in einem meiner Lenovo-Laptops das Zeitliche gesegnet hat, musste ich das System komplett frisch aufsetzen.

Ich verwende diesen Laptop als Site-to-Site OpenVPN-Endpunkt. Mit der Zeit habe ich dort auch andere Software draufgeknallt, zum Beispiel den UniFi Controller zum Management der Netzwerk-Komponenten in der Aussenstation.

Bei der Installation des UniFi Controllers das erste Problem: Debian 11 Bullseye bietet kein MongoDB-Paket (mehr) an:

# apt-get install unifi
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 unifi : Depends: mongodb-server (>= 2.4.10) but it is not installable or
                  mongodb-10gen (>= 2.4.14) but it is not installable or
                  mongodb-org-server (>= 2.6.0) but it is not installable
         Depends: mongodb-server (< 1:4.0.0) but it is not installable or
                  mongodb-10gen (< 4.0.0) but it is not installable or
                  mongodb-org-server (< 4.0.0) but it is not installable
E: Unable to correct problems, you have held broken packages.

Auf einem Referenzsystem war folgende MongoDB installiert:

# dpkg --list | grep -i mongo
ii  mongo-tools                          3.4.14-4                       amd64        collection of tools for administering MongoDB servers
ii  mongodb-clients                      1:3.2.11-2+deb9u2              amd64        object/document-oriented database (client apps)
ii  mongodb-server                       1:3.2.11-2+deb9u2              amd64        object/document-oriented database (server package)

Mittels packages.debian.org fand ich dann rasch heraus, dass diese Pakete in Debian 9 Stretch enthalten waren. Damit ich diese installieren konnte, musste ich /etc/apt/sources.list anpassen:

...
deb         https://debian.ethz.ch/debian/ stretch main non-free
deb-src     https://debian.ethz.ch/debian/ stretch main non-free
...

Damit klappte die Installation von MongoDB und des UniFi Controllers.

Leider kam UniFi nach der Installation aber nicht hoch. Wenn ich die auf dem funktionierenden System gespeicherte URL ansurfte, erschien eine HTTP Status 404 – Not Found Fehlermeldung im Java-Layout:

Nach etwas Recherche und dem Vergleich mit einem baugleichen System an einer anderen Aussenstelle dann die Erkenntnis: Der UniFi Controller läuft ausschliesslich mit Java 8 (Running Unifi Controller on Java 9, 10 and 11). Auf dem neuen Debian hatte ich aber Java 17 (?) installiert gehabt.

Obwohl How can I install Java 8 on Debian 11 (Bullseye)? Hinweise gibt, wie man Java 8 zum Laufen kriegt, wählte ich den einfachsten Weg — über ein offizielles Debian-Paket: Ich hatte nämlich Glück: Den Zugang zu einem offiziellen Java 8-Paket hatte ich mir über die obigen Anpassungen von apt.sources bereits etabliert. Das Paket installierte ich folgendermassen:

# apt-get update
# apt-get install openjdk-8-jre-headless

Da ich noch eine Java 17-Installation auf dem System existieren hatte, war diese als Standardversion eingestellt:

# java --version
openjdk 17.0.4 2022-07-19
OpenJDK Runtime Environment (build 17.0.4+8-Debian-1deb11u1)
OpenJDK 64-Bit Server VM (build 17.0.4+8-Debian-1deb11u1, mixed mode, sharing)

Da ich Java 17 nicht brauchte, entfernte ich das Paket kurzerhand:

# apt-get remove openjdk-17-jre-headless

Wer aber auch auf dieses Paket angewiesen ist, kann folgendermassen Java 8 als Standard auswählen:

# update-java-alternatives --list
java-1.17.0-openjdk-amd64      1711       /usr/lib/jvm/java-1.17.0-openjdk-amd64
java-1.8.0-openjdk-amd64       1081       /usr/lib/jvm/java-1.8.0-openjdk-amd64
# update-alternatives --config java

Anschliessend kam der UniFi Controller hoch. Nun nur noch ein Backup einspielen, und der Controller funktionierte wieder wie vor dem Festplattendefekt.

Tags: , , , , , ,
Labels: Uncategorized

Keine Kommentare | neuen Kommentar verfassen

Dienstag, 15. März 2022

Wie viel Strom zieht ein US-16-150W ohne PoE-Geräte?

Link zu diesem Artikel

Ubiquiti UniFi Switch mit 16+2 Anschlüssen, von welchen alle Ethernet-Ports PoE machen können (maximal 150W)

Antwort: 16 Watt, ohne dass irgendwelche Geräte angeschlossen sind, und 20 Watt, wenn Netzwerkgeräte (ohne Power-over-Ethernet!) dran hängen.

Quelle: [Power Consumption] Unifi 8-60W vs 8-150W vs 16-150W

Tags: , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Samstag, 12. März 2022

Was, wenn man noch eine Weile auf der alten UniFi Controller-Version bleiben möchte?

Link zu diesem Artikel

Kürzlich:

Get:1 http://security.debian.org bullseye-security InRelease [44.1 kB]
Get:2 http://debian.ethz.ch/debian bullseye-backports InRelease [44.2 kB]                      
Hit:3 http://phoscon.de/apt/deconz buster InRelease                                            
Hit:4 https://debian.ethz.ch/debian bullseye InRelease                                         
Hit:5 https://deb.nodesource.com/node_16.x bullseye InRelease                                  
Get:6 https://debian.ethz.ch/debian bullseye-updates InRelease [39.4 kB]                  
Get:7 http://packages.cloud.google.com/apt cloud-sdk-bullseye InRelease [6,772 B]              
Hit:8 https://debian.ethz.ch/debian buster InRelease                                           
Get:10 http://debian.ethz.ch/debian bullseye-backports/main Sources.diff/Index [63.3 kB]
Get:11 http://debian.ethz.ch/debian bullseye-backports/main amd64 Packages.diff/Index [63.3 kB]
Get:12 http://debian.ethz.ch/debian bullseye-backports/main Sources T-2022-03-10-1401.49-F-2022-03-10-0801.51.pdiff [715 B]
Get:12 http://debian.ethz.ch/debian bullseye-backports/main Sources T-2022-03-10-1401.49-F-2022-03-10-0801.51.pdiff [715 B]
Get:13 http://debian.ethz.ch/debian bullseye-backports/main amd64 Packages T-2022-03-10-1401.49-F-2022-03-10-0801.51.pdiff [17.3 kB]
Get:13 http://debian.ethz.ch/debian bullseye-backports/main amd64 Packages T-2022-03-10-1401.49-F-2022-03-10-0801.51.pdiff [17.3 kB]
Get:9 https://dl.ubnt.com/unifi/debian stable InRelease [3,038 B]                             
Reading package lists... Done  
E: Repository 'https://dl.ubnt.com/unifi/debian stable InRelease' changed its 'Codename' value from 'unifi-6.5' to 'unifi-7.0'
N: This must be accepted explicitly before updates for this repository can be applied. See apt-secure(8) manpage for details.

Die relevante Zeile:

E: Repository 'https://dl.ubnt.com/unifi/debian stable InRelease' changed its 'Codename' value from 'unifi-6.5' to 'unifi-7.0'

Es war aber spätabends und ich war auf keine Experimente mit meinem WLAN aus.

Wie macht man, dass diese Meldung weggeht, und die restlichen, nicht-UniFi Pakete trotzdem aktualisiert werden? Ganz einfach: In /etc/apt/sources.list ersetzt man in der Unifi-Zeile „stable“ mit „oldstable“:

...
deb         http://www.ubnt.com/downloads/unifi/debian oldstable ubiquiti
...

Tags: , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Mittwoch, 29. September 2021

Elgato Key Light Air wird von Control App unter iOS und macOS nicht mehr erkannt

Link zu diesem Artikel

Gestern fand die Elgato Control App unter iOS mein Elgato Key Light Air plötzlich nicht mehr im Netzwerk. Auch die nachträglich installierte Control App unter macOS Big Sur meldete kein Licht zur Steuerung.

Ich setzte das Licht mehrere Male zurück, und verband es mit Müh und Not wieder mit dem WLAN. Das alles half nichts.

Mysteriös: Mein DHCP-Server erteilte dem Licht eine statische IP, und ich konnte die Lampe von allen Geräten aus auch pingen. Doch die Control App sah die Lampe nicht; ich vermute, dass es ein Problem mit Apples Bonjour gab.

Einige Ansätze: UniFi AP-AC-PRO Not Crossing mDNS/Multicast/Broadcast between 2.4GHz and 5GHz Networks?, iTunes Remote Multicast / Bonjour 2.4/5GHz Radio Issue).

Das Schlimmste am Ganzen: Das Licht verfügt einzig über einen Ein- und Ausschalter. Das Licht selber kann man aber nur über die App steuern (Helligkeit, und Lichttemperatur).

Auch der Trick mit der manuellen Anpassung von Settings.xml (auch: Elgato Control Center Settings.xml) funktionierte nicht, weil sich unter macOS keine solche Datei findet. Immerhin fand ich das Einstellungsverzeichnis (~/Application Support/com.corsair.ControlCenter), und (jetzt erst beim Schreiben des Blog-Artikels) die Einstellungsdatei (~/Preferences/com.corsair.ControlCenter.plist)

Was genau das Problem verursacht hat, kann ich nicht mit Sicherheit sagen. Aber allenfalls hat ein mehrmaliger Reboot meiner UniFi-Access Points während der Debugging-Übung das Problem unbeabsichtigt gelöst.

Doch zu dem Zeitpunkt hatte ich mir auf Basis von Automating Elgato Key Lights From macOS Touch Bar bereits selbst geholfen. Folgende zwei Scripts lassen einen die Lampe einschalten und eigene Lichtwerte einstellen, sowie die Lampe ausschalten:

on.sh

#!/bin/bash

IP="1.2.3.4"

BRIGHTNESS="100" #max
TEMPERATURE="256" #max

if [ $# -gt 0 ]
then
    BRIGHTNESS="$1"
fi

if [ $# -gt 1 ]
then
    TEMPERATURE="$2"
fi

DATARAW="{\"lights\":[{\"brightness\":$BRIGHTNESS,\"temperature\":$TEMPERATURE,\"on\":1}],\"numberOfLights\":1}"

curl --location --request PUT "http://$IP:9123/elgato/lights" \
--header 'Content-Type: application/json' \
--data-raw "$DATARAW"
echo ""

exit 0

off.sh

#!/bin/bash

IP="1.2.3.4"

curl --location --request PUT "http://$IP:9123/elgato/lights" \
--header 'Content-Type: application/json' \
--data-raw '{"lights":[{"on":0}],"numberOfLights":1}'
echo ""

exit 0

Als nächstes würde es mich reizen, für den Geschäftslaptop diese Funktionalität auch gleich noch auf die Touchbar zu legen, wie im Artikel weiter unten beschrieben

Mittlerweile „sendet“ die Lampe (wieder) unter Bonjour. Discovery.app zeigt folgenden Eintrag an:

_elg._tcp. - 1 item
Elgato
elgato.local.
1.2.3.4:9123
[fe80::]:9123
mf=Elgato
dt=200
id=3C:6A:9D:00:00:00
md=Elgato Key Light Air 123456789
pv=1.0

Unter Linux mit installierten avahi-utils kann man vermutlich mit folgendem Befehl dieselbe Information extrahieren:

$ avahi-browse -a

Tags: , , , , , , , ,
Labels: Home Automation, IT

Keine Kommentare | neuen Kommentar verfassen

Donnerstag, 27. Mai 2021

EdgeRouter ER-X wird mit aktiviertem hwnat bei Facetime-Anrufen instabil

Link zu diesem Artikel

Seit einiger Zeit fällt mir auf, dass FaceTime Video-Anrufe von mir (Fiber7, 1 Gbit/s symmetrisch) zu einem Bekannten (upc, mit ein paar 100 MBit/s up- and down, best effort) ruckeln und stocken.

Die Probleme beginnen wenige Sekunden nach der Etablierung des Anrufs. Symptome:

  • Pings von mir aus an die öffentliche IP-Adresse des Bekannten liegen normalerweise im 20-30ms Bereich. Während Facetime-Anrufen ist das in ca. 60-70 Prozent der Fälle weiter so, dann aber kommt es vor, dass die Latenz mehrerer aufeinanderfolgenden Pakete auf bis zu 600ms hochschnellt. Es kommt auch immer wieder vor, dass Ping-Pakete komplett verloren gehen.
  • Smokeping auf die öffentliche IP-Adresse des Bekannten zeigt einen besorgniserregenden Packet Loss.
  • Der Endpunkt eines OpenVPN-Tunnels beim Bekannten vermeldet zur selben Zeit wiederholt folgende Warnungen: 
    Thu May 27 21:44:10 2021 Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #33668492 / time = (1621559394) Fri May 21 03:09:54 2021 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings

Screenshots:

Die (triviale) Lösung: Auf dem EdgeRouter ER-X mit Firmware v1.10.0 muss das sog. Hardware Offloading (kurz hwnat) deaktiviert werden:

Offizielle Anleitung (CLI), aber dasselbe geht auch über das GUI und den Config Tree: System > Offloading > hwnat = disable.

Das Problem ist im Support-Eintrag Connecting to wireguard on edgerouter messes up outgoing UDP packets #23 beschrieben, mitsamt der Lösung:

If you use a Mediatek device with hwnat your UDP packages might get lost. Currently the only solution is to disable hwnat

UDP re-order problem

With hwnat disabled, the wg0 interface works great and the ER-X routes all my internet traffic out of it just fine, although CPU has much more overhead.

As soon as I enable hwnat, I start seeing problems, but only in certain scenarios, not all. For example, with hwnat disabled, I can use OpenVPN as a client on a local machine. Thus that OpenVPN connection gets routed out through the wg interface first, then on to server. The OpenVPN server shows the endpoint IP of the server ER-X wg is connected to as the OpenVPN client’s IP, not my ISP IP (what I want). As soon as I enable hwnat, this breaks. I can still make the initial outgoing connection and bring up the OpenVPN tunnel, but packets get dropped so that OpenVPN through the wg interface is unusable with hwnat enabled.

Also noticed Apple FaceTime is broken when hwnat is enabled with wg interface. Lots of disconnects and moments of me hearing them but them not hearing me. Again, disabling hwnat fixes it instantly, but again, at the cost of CPU.

Nachtrag

Das Problem ist leider immer noch nicht gelöst. Zuerst einmal scheint die Deaktivierung von hwnat über das Web GUI erst dann zu greifen, wenn man den Router neu startet. Bei mir zeigte das GUI „disabled“ an, doch auf der Kommandozeile erschien folgendes:

$ configure
[edit]
user@ROUTER# show system offload hwnat
 hwnat disable

$ show ubnt offload
IPSec offload module: loaded

HWNAT offload module: loaded

Traffic Analysis    :
  export    : disabled
  dpi       : disabled
    version       : 1.354

Nach dem Neustart dann:

$ show ubnt offload
IPSec offload module: not loaded

HWNAT offload module: not loaded

Traffic Analysis    :
  export    : disabled
  dpi       : disabled
    version       : 1.354

Trotz alledem macht FaceTime weiterhin Probleme.

Via: ERX Hardware Offload won’t load

Tags: , , , , , , , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

« Older Entries