Posts Tagged ‘Ubiquiti’

Sonntag, 27. August 2023

UniFi Switch PoE-Probleme — und meine Lösung

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

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

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?

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

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

$ 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

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

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

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

Sonntag, 30. Juni 2019

Irgendwas ist am UniFi Firmware 4.0.42.10433 nicht ganz koscher

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