Posts Tagged ‘UniFi’

Mittwoch, 4. September 2024

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

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

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

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

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

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?

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?

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

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

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

Samstag, 3. April 2021

Ubiquiti UniFi UAP-AC-M zurücksetzen

Da heute um ungefähr 4 Uhr morgens mein Ubiquiti UniFi AP AC PRO plötzlich und ohne Vorwarnung verstorben ist (vermutlich, weil ich dessen Sendeleistung letzte Woche manuell auf High gesetzt habe …), musste ich ihn mit einem hier ungenutzt herumliegenden Ubiquiti UniFi UAP-AC-M ersetzen.

Leider klappte der Reset des noch für den vorherige Standort konfigurierten Access Points mit fünf Sekunden langem Druck auf den physischen Reset-Knopf nicht (wie im Handbuch auf Seite 7 beschrieben).

Schlussendlich loggte ich mich deshalb mittels SSH auf den Access Point ein (natürlich muss man dazu die Zugangsdaten der vorher genutzten Installation kennen, sonst hat man Pech), und führte folgenden Befehl aus:

# syswrapper.sh restore-default
Clearing CFG ... [%100] done!

Nach dem Neustart erschien der Access Point im Device Tab meines UniFi Controllers und konnte dort problemlos adoptiert werden.

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

Keine Kommentare | neuen Kommentar verfassen