Posts Tagged ‘Ubiquiti’

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

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

Mittwoch, 2. August 2023

unifi-video unter Debian Bullseye installieren

Link zu diesem Artikel

ACHTUNG: Wie ich erst nach der Installation von unifi-video und dem Verfassen des Blog-Beitrags realisiert habe, wurde UniFi Video eingestellt (End-of-Life EOL) (Quelle). Das Nachfolgeprodukt is UniFi Protect, welches ausschliesslich auf UniFi-Hardware läuft. Dann wird es dann wohl doch einfach eine Wyze Cam …

Momentan evaluiere ich für einen Bekannten UniFi Protect Videokameras.

Im Einführungs-Video What do I need to run Unifi Protect? (in diese Web-Seite eingebettet) zu UniFi Protect (der Produktlinie von Ubiquiti UniFi Videokameras) wird einem gesagt, dass man einen UniFi Cloud Key (UCK-G2-Plus), eine UniFi Dream Machine Pro (UDM-Pro) oder eine Ubiquiti Network Video Recorder-Appliance (UNVR) kaufen muss, um das LAN mit Network Video Recording-Fähigkeiten auszurüsten.

Ich habe aber meinen UniFi-Controller als Software-Paket auf einem Lenovo-Laptop mit Debian Bullseye laufen.

Tatsächlich ist auch ein Debian Package namens unifi-video verfügbar. Dieses lässt sich auch unter Bullseye installieren.

Entweder mit einem Bash-Script von Glenn Rietveld. Das Herunterladen von Bash-Scripts aus dem Internet und ausführen als root sagt mir aber nicht wirklich zu. Berufskrankheit.

Es geht aber auch anders, für Debianistas ganz „normal“: Mit apt-get install unifi-video. Wie man das macht, ist aber im Internet schlecht dokumentiert. Mit etwas pröbeln habe ich es soeben geschafft:

Zuerst fügt man den GPG-Key des Repositories hinzu:

# curl -fsSL http://www.ubnt.com/downloads/unifi-video/apt-3.x/unifi-video.gpg.key | apt-key add -

Anschliessend fügt man folgende Zeile in /etc/apt/sources hinzu:

...
deb         http://www.ubnt.com/downloads/unifi-video/apt-3.x stretch ubiquiti
...

WICHTIG: Obwohl ich bullseye am Laufen habe, kennt das Repository nur stretch. Dennoch funktioniert danach ein …

# apt-get update
# apt-get install unifi-video

… problemlos.

Danach läuft das Teil auch schon:

# ps ax | grep unifi-video
3629722 ?        Ss     0:00 unifi-video -cwd /usr/lib/unifi-video -user unifi-video -home /usr/lib/jvm/java-1.8.0-openjdk-amd64 -cp /usr/share/java/commons-daemon.jar:/usr/lib/unifi-video/lib/airvision.jar -pidfile /var/run/unifi-video/unifi-video.pid -procname unifi-video -Dav.tempdir=/var/cache/unifi-video -Djava.security.egd=file:/dev/./urandom -Xmx941M -Xss512K -XX:+UseG1GC -XX:+UseStringDeduplication -XX:MaxMetaspaceSize=1024M -Djava.library.path=/usr/lib/unifi-video/lib -Djava.awt.headless=true -Djavax.net.ssl.trustStore=/usr/lib/unifi-video/data/ufv-truststore -Dfile.encoding=UTF-8 com.ubnt.airvision.Main start
3629724 ?        Sl     0:32 unifi-video -cwd /usr/lib/unifi-video -user unifi-video -home /usr/lib/jvm/java-1.8.0-openjdk-amd64 -cp /usr/share/java/commons-daemon.jar:/usr/lib/unifi-video/lib/airvision.jar -pidfile /var/run/unifi-video/unifi-video.pid -procname unifi-video -Dav.tempdir=/var/cache/unifi-video -Djava.security.egd=file:/dev/./urandom -Xmx941M -Xss512K -XX:+UseG1GC -XX:+UseStringDeduplication -XX:MaxMetaspaceSize=1024M -Djava.library.path=/usr/lib/unifi-video/lib -Djava.awt.headless=true -Djavax.net.ssl.trustStore=/usr/lib/unifi-video/data/ufv-truststore -Dfile.encoding=UTF-8 com.ubnt.airvision.Main start
3632137 ?        Sl     0:05 bin/mongod --config /usr/lib/unifi-video/conf/mongodv3.0+.conf
3633173 ?        Sl     0:00 bin/evostreamms /usr/lib/unifi-video/conf/evostream/config.lua

Das Web-Interface öffnet man über 1.2.3.4:7443 (https nicht vergessen, mit http klappt es nicht).

Versucht man stattdessen, anstelle von stretch das Paket für den Release bullseye herunterzuladen, erhält man folgende Fehlermeldung:

...
Ign:8 https://dl.ui.com/unifi-video/apt-3.x bullseye InRelease
Err:9 https://dl.ui.com/unifi-video/apt-3.x bullseye Release
  404  Not Found [IP: 13.224.100.217 443]
Reading package lists... Done
E: The repository 'http://www.ubnt.com/downloads/unifi-video/apt-3.x bullseye Release' does not have a Release file.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.

Konsultierte Web-Seiten:

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

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

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

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

Sonntag, 28. März 2021

Mit gehärtetem SSH-Client kann man sich nicht mehr auf UniFi-Geräte einloggen

Link zu diesem Artikel

$ ssh us-8-60w
Unable to negotiate with 10.1.2.3 port 22: no matching MAC found. Their offer: hmac-sha1

Bummer. Ich musste meine gehärtete ~/.ssh/config folgendermassen abschwächen, um mich per SSH wieder auf den Access Point einloggen zu können:

...
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com,hmac-sha1
...

Siehe auch SSH Into Ubiquiti Access Point

Die lokal verfügbaren MACs zeigt man folgendermassen an:

$ $ ssh -Q mac
hmac-sha1
hmac-sha1-96
hmac-sha2-256
hmac-sha2-512
hmac-md5
hmac-md5-96
umac-64@openssh.com
umac-128@openssh.com
hmac-sha1-etm@openssh.com
hmac-sha1-96-etm@openssh.com
hmac-sha2-256-etm@openssh.com
hmac-sha2-512-etm@openssh.com
hmac-md5-etm@openssh.com
hmac-md5-96-etm@openssh.com
umac-64-etm@openssh.com
umac-128-etm@openssh.com

Tags: , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 28. März 2021

Auf einem UniFi Switch die Vitaldaten eines SFPs auslesen

Link zu diesem Artikel

Dieses Anliegen ist zum Glück deutlich besser dokumentiert als bei einem EdgeRouter ER-X-SFP, generell aber etwas komplizierter umgesetzt:

Nachdem man sich per SSH auf den UniFi Switch mit SFP-Modul eingeloggt hat, gibt man folgende Befehle ein:

# telnet localhost
(UBNT) >show fiber-ports optics all

                                    Output    Input
Port      Temp  Voltage  Current     Power    Power   TX     LOS
           [C]   [Volt]     [mA]     [dBm]    [dBm]   Fault
--------  ----  -------  -------   -------  -------   -----  ---
0/9       42.9    3.284     34.3    -5.983   -8.520   No     No

Quelle: SFP/SFP+ info on UniFi switches

Nachtrag

Um anzuzeigen, was genau für SFPs im Switch verbaut sind, verwendet man folgenden Befehl (Achtung, es handelt sich um einen anderen Switch als den obigen):

# swctrl sfp show
Port  Vendor Name      Serial Number    Part Number      Rev  Compliance
----  ---------------- ---------------- ---------------- ---- ----------------
   9  UBNT             X20061111111     UF-RJ45-1G       1.0  1000T           
  10  UBNT             X20061111112     UF-RJ45-1G       1.0  1000T

Quelle: Ubiquiti US-16-XG 10GbE switch command line

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

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 28. März 2021

Auf einem ER-X-SFP die Vitaldaten eines SFPs auslesen

Link zu diesem Artikel

Nirgends sauber dokumentiert, habe ich es nach einigen Stunden Recherche geschafft, die Temperatur, die Spannung, den Strom sowie die Sende- und Empfangsstärke eines in einem ER-X-SFP verbauten Fiber7-SFPs auszulesen:

/usr/sbin/ubnt-hal getSfp eth5
connector=LC
vendor=FLEXOPTIX       
oui=38-86-02
part=S.B1312.10.XDL  
rev=A   
serial=1234567
date=170110  
temp=67.601 C
voltage=3.23 V
current=17.03 mA
tx_power=0.15 mW
rx_power=0.23 mW
tx_fault=no
rx_los=no

Diesen goldenen Tipp erhielt ich von diesem Kommentar im Community-Thread Support for g.fast SPF. Was /usr/sbin/ubnt-hal sonst noch kann, ist im (leider seit 2013 nicht mehr aktualisierten) Artikel Undocumented EdgeOS commands beschrieben.

Wieso ich wusste, dass das geht? Im Router GUI werden diese Daten angezeigt, wenn man mit der Maus über den im Header graphisch dargestellten SFP-Port fährt. Das GUI holt diese Daten über die Websockets-Schnittstelle /ws/stats, welche von lighthttpd auf den Socket /tmp/ubnt.socket.statsd zeigt. Leider habe ich nicht herausgefunden, wie ich diesen Socket von der Kommandozeile aus ansprechen kann.

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

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 19. Januar 2020

Signal-Werte meiner Ubiquiti UF-SM-1G-S

Link zu diesem Artikel

Kürzlich hat ein Bekannter ein zweites Stockwerk mit Netzwerkverkabelung erschlossen. Hierzu haben wir nicht Ethernet Cat6 gewählt, sondern wegen der Grösse der Lehrrohre auf Glasfaser gesetzt.

Dies bedingt leider aber auch, dass an beiden Enden des Glasfasers SFP-Module verwendet werden müssen, die die Lichtwellen auf Ethernet konvertieren.

Ich habe mich auf der einen Seite für einen gebrauchten Ubiquiti Unifi Switch US-8-150W entschieden, auf der anderen Seite ein bei mir nach Fiber7-Tests unbenutzt herumliegender TP-Link MC220L, der im Modus Auto mit Ethernet auf einen Ubiquiti Unifi Switch US-8-60W gepatcht ist. Als SFP-Module verwende ich beidseitig Ubiquiti UF-SM-1G-S. Als Kabel hat der Bekannte ein Lightwin LWL-Patchkabel LC/APC-LC, Singlemode, Simplex, 15m gezogen.

Aktuell erreiche ich mit diesem Setup auf Seite des US-8-150W folgende Signal-Werte:

  • Output Pwr. -6.03 dBm
  • Input Pwr. -8.57 dBm

Das SFP-Modul ist 47 Grad Celsius warm, die Spannung beträgt 3.284 Volt und der Strom beträgt 31.890 mA. Diese Infos kann man allesamt in Echtzeit über die UniFi Controller-Software auslesen.

Leider habe ich keine Ahnung, ob diese Werte gut oder schlecht sind …

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

2 Kommentare | neuen Kommentar verfassen

« Older Entries