Archiv ‘IT’

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, 9. Mai 2021

setlocale: LC_ALL: cannot change locale

Seit ich mein MacBook Air mit M1-Chip und macOS Big Sur verwende, erhalte ich beim Login auf meinen Raspberry Pi 3 über SSH folgende Warnung zu Gesicht:

ssh dashboard
Linux DASHBOARD 5.10.17-v7+ #1403 SMP Mon Feb 22 11:29:51 GMT 2021 armv7l
Last login: Sat May  8 05:00:24 2021
-bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)

Ursache des Problems: en_US.UTF-8 ist in /etc/locale.gen kommentiert:

$ cat /etc/locale.gen | grep -v "^#"

en_GB.UTF-8 UTF-8

Somit die Datei öffnen, die Zeile mit en_US.UTF-8 suchen, ent-kommentieren, speichern und dann folgenden Befehl ausführen:

# locale-gen

Via: warning: setlocale: LC_ALL: cannot change locale

Beim nächsten Login erscheint die Fehlermeldung nicht mehr.

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

Keine Kommentare | neuen Kommentar verfassen

Samstag, 10. April 2021

Was gibt der DELL P2421DC über USB-C als Ladeleistung her?

Vor einigen Wochen habe ich einen DELL P2421DC für einen Bekannten ausgesucht, um diesen an seinen neuen Mac mini M1 anzuschliessen. Der Monitor macht einen guten Eindruck und funktioniert über USB-C tadellos.

Was aber, wenn man stattdessen einen Laptop per USB-C anschliessen will, um ihn gleichzeitig zu laden? Der Monitor kann gemäss Herstellerangaben USB-C Peripherie maximal mit 65W laden.

Doch mit wieviel Volt, und Ampère? Im Handbuch steht es auf Seite 12:

You can attach the monitor to PC using a USB type C cable (shipped with your monitor), to get the monitor experience as below: support data transmission speed up to USB 3.1. Display resolution up to 2560 x 1440@60 Hz on Display Port 1.2 alternate mode. Power delivery of 20 V/3.25 A, 15 V/3 A, 9 V/3 A, 5 V/3 A.

Quelle: Dell 24 USB-C Monitor – P2421DC User’s Guide

Auslöser für die Recherche war diese Kundenfrage auf Digitec.

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

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 4. April 2021

Netatmo Modulchaos: Nach Jahren gelöst

Kürzlich konnte ich ein langjähriges Problem mit einer Netatmo Weather Station-Installation eines Bekannten lösen.

Auf Grund der Beschränkung der Anzahl Innenmodule pro Basisstation betreibt er zwei Basisstationen.

Die Temperaturwerte der Module werden von einem Script über die Netatmo API abgefragt und dann auf einem Dashboard angezeigt.

Das Problem: Ein bestimmtes Innenmodul fehlte bisher in den API-Daten, obwohl dessen Werte in der Netatmo App problemlos angezeigt werden. Anstelle der Stationsdaten wurde im Dump der PHP-Variable mit den API-Nutzdaten null angezeigt, umgeben von den Daten anderer Innenmodule.

Vor einigen Wochen entschied ich mich, dem Problem ein für allemal auf den Grund zu gehen — und es zu lösen. Nach längerem hin- und her mit dem Netatmo Support gab mir Leslie letzte Woche den entscheidenden Hinweis: Er wies mich darauf hin, dass ein Innenmodul an beiden Basisstationen angemeldet sei. Aus Sicht der Entwickler könnte dies das Problem verursachen.

Darauf angesprochen erwähnte der Bekannte, dass er seinerzeit das Modul zuerst an der einen Basisstation angemeldet hatte, sich dann aber anders überlegt und es dann mit der anderen Basisstation verbunden hatte.

Bemerkung am Rande: Komisch, dass Netatmo sowas überhaupt zulässt (zuliess?). Meine Vermutung: In der Datenbank wird von einer Basisstation auf die Modul IDs verlinkt, weshalb verschiedene Basisstationen auf dasselbe Modul linken können (n:1). Besser wäre es umgekehrt: Ein Modul sollte zu einer Basisstation gelinkt sein (1:1).

In der iOS App wurde das Geister-Innenmodul nicht angezeigt. Im Web GUI hingegen gab pro Basisstation je ein Modul-Eintrag mit einem Fragezeichen, doch in den Einstellungen wurde das Modul dann doch nicht aufgelistet.

Schlussendlich entschied ich mich für einen anderen Weg: Ich lud die App NetatmoModulesManager.app herunter. Es handelt sich um eine macOS App, die man mit einer Google-Suche nicht einfach so zum Download findet — deshalb hier die Wegbeschreibung:

Wenn man auf dieser Seite startet und den Link No smartphone? No tablet? Click here for an alternative installation using your computer. klickt, loggt man sich in Netatmo ein und es wird einem dann der Download-Link präsentiert (meinem Verständnis nach setzt dies voraus, dass man bereits eine Weather Station in Betrieb hat?). Der Direktlink lautet derzeit (4. April 2021) fw.netatmo.net/NetatmoModulesManager_MacOS.dmg.

Nach der Installation verbanden wir nacheinander die zwei Basisstationen mit dem Mac (Screenshots der Oberfläche). Hierzu starteten wir zuerst die App, klickten auf Weiter und schlossen die Basisstation erst an, als wir dazu aufgefordert wurden. Nach 10-15 Sekunden warten erschien die Basisstation dann auf dem Bildschirm. Als erstes wurde ein Firmware-Update durchgeführt, anschliessend startete die Basisstation neu und uns wurde in der App die Liste der Aussen- und Innenmodule angezeigt.

Leider entsprachen die Namen der Module hier nicht dem Web GUI. Ich notierte deshalb die Modul ID in der App, und verglich diese mit dem Web GUI um sicher zu gehen, dass ich die richtigen Modulnamen notieren konnte.

Schlussendlich fand ich den Übeltäter; d.h. ein Modul, dessen ID bei beiden Basisstationen aufgeführt wurde. In der App löschte ich das richtige Modul von der richtigen Basisstation — und die App stürzte ab. Beim zweiten Versuch gelang es tatsächlich, das Modul zu löschen.

Seither ist das API-Problem gelöst.

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

Samstag, 3. April 2021

IKEA TRADFRI Gateway plötzlich offline

Heute in der Nacht erhalte ich von monit plötzlich die Meldung, dass mein IKEA TRADFRI Gateway offline gegangen sei.

Das Gateway verrichtet seinen Dienst seit Februar 2020 anstandslos und steuert zwei FLOALT Lampen in der Stube. Sowie einen FYRTUR Verdunkelungsrollo, den ich aussenseitig bei der Balkontür angebracht habe, um zu verhindern, dass die Morgensonne die Küche zu sehr aufheizt.

Fast gleichzeitig stirbt ein Ubiquiti UniFi UAP AC PRO (vermutlich, weil ich dessen Sendeleistung letzte Woche manuell auf High gesetzt habe …), weshalb ich zuerst vermute, dass TRADFRI ein Kollateralschaden des kaputten Access Points ist. Bis ich realisiere, dass das Gateway ja mittels Ethernet-Kabel am Switch hängt … hängt wortwörtlich wohl doch nicht damit zusammen.

Ausserdem: Mit der IKEA Home Smart App unter iOS ist es mir nicht möglich, auf das Gateway zuzugreifen. Mysteriös!

Mehrmals trenne ich das Gateway vom USB-Strom, es kommt hoch, scheint ein paar Minuten zu funktionieren, doch dann stirbt es. Ich starte den Switch neu, stecke auch das Ethernet-Kabel einmal aus und wieder ein, nichts hilft.

Auf dem DHCP-Server sehe ich, dass das Gateway am Vormittag seine fix zugewiesene IP bezogen hat, und in den Logs von Bind9 sehe ich, dass das Gateway regelmässig DNS-Queries absetzt (auf webhook.logentries.com mindestens alle 10 Sekunden, der Abfrageabstand kann sich aber auch auf ein bis zwei Minuten ausdehnen; sowie auf einen AWS IoT service mit kryptischem Subdomain %random%.iot.eu-central-1.amazonaws.com).

Doch wenn ich das Gateway pinge, antwortet es eine Weile lang (teilweise mit einer Latenz von bis zu 20 Sekunden — muss eine extrem schwachbrünstiger Compute-Chip verbaut sein), und dann ganz lange Perioden, wo alle Pings im Nirvana enden.

Plötzlich die Erkenntnis, dass ich gestern ja die Liste der mit Bind9 RPZ geblockten Ad- und Tracking-Server aktualisiert habe. Und tatsächlich, pixelserv-tls zeigt in seinen Logs seit dem Update Hits vom TRADFRI Gatway auf die Domain webhook.logentries.com.

Ich generiere die Liste der Ad- und Trackingserver neu (ich beziehe sie von Steven Black), whiteliste aber webhook.logentries.com.

Die IKEA Home Smart App kann sich weiterhin nicht mit dem Gateway verbinden. Wahlweise werden mir eine der folgenden zwei Meldungen gezeigt:

Der Hilfetext könnte auch noch relevant werden:

Schlussendlich reicht es mir, und ich wähle den kleinen Link Disconnect Gateway aus, um das Gateway aus der App zu löschen. Hinzufügen kann ich dasselbe Gateway sowohl mittels Barcode als auch manuell via IP hingegen nicht mehr.

Schlussendlich entscheide ich mich, das Gateway noch einmal vom Strom zu trennen und neu zu starten. Und siehe da: Aus irgendeinem Grund klappt die Registration des Gateways mit der App nach dem Neustart reibungslos.

In der App entdecke ich, dass die Firmware des Gateways am 25. März 2021 das letzte Mal aktualisiert wurde:

Könnte es sein, dass die Firmware buggy ist? Ich weiss es nicht; bis jetzt kann ich die Lichter wieder mittels unserer Apple Homepods ein- und ausschalten, sowie den Rollo betätigten.

Ich behalte die Situation im Auge.

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

Keine Kommentare | neuen Kommentar verfassen

Freitag, 2. April 2021

Videos auf WhatsApp hochladbar machen

Soeben wollte ich einen Playback-Mitschnitt meiner Wyze-Kamera über WhatsApp teilen, doch auf dem iPhone erhalte ich beim Versand die Meldung:

This video could not be sent. Please choose a different video.

Unter macOS war der Versand möglich, das Video wird aber nicht abspielbar angezeigt, sondern nur als Attachment zum Download angeboten (als wäre es irgendein Binärformat).

Die Lösung:

$ ffmpeg -i "2021-04-01 23-25.mp4" -c:v libx264 -profile:v baseline -level 3.0 -pix_fmt yuv420p "2021-04-01 23-25.whatsapp.mp4"

Quelle: ffmpeg – whatsapp: video format not supported

Wie unterscheiden sich die beiden Videoformate?

$ ffmpeg -i "2021-04-01 23-25.mp4"
...
Guessed Channel Layout for Input Stream #0.1 : mono
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '2021-04-01 23-25.mp4':
  Metadata:
    major_brand     : mp42
    minor_version   : 0
    compatible_brands: mp42isom
  Duration: 00:01:39.40, start: 0.000000, bitrate: 841 kb/s
    Stream #0:0(und): Video: h264 (Main) (avc1 / 0x31637661), yuv420p, 1920x1080, 1143 kb/s, 15 fps, 15 tbr, 90k tbn, 20 tbc (default)
    Metadata:
      encoder         : JVT/AVC Coding
    Stream #0:1(und): Audio: pcm_alaw (alaw / 0x77616C61), 8000 Hz, mono, s16, 64 kb/s (default)

sowie der WhatsApp-kompatible Clip:

$ ffmpeg -i "2021-04-01 23-25.whatsapp.mp4" 
...
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '2021-04-01 23-25.whatsapp.mp4':
  Metadata:
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2avc1mp41
    encoder         : Lavf58.45.100
  Duration: 00:01:39.53, start: 0.000000, bitrate: 1628 kb/s
    Stream #0:0(und): Video: h264 (Constrained Baseline) (avc1 / 0x31637661), yuv420p, 1920x1080, 2344 kb/s, 15 fps, 15 tbr, 15360 tbn, 30 tbc (default)
    Metadata:
      handler_name    : VideoHandler
    Stream #0:1(und): Audio: aac (LC) (mp4a / 0x6134706D), 8000 Hz, mono, fltp, 36 kb/s (default)
    Metadata:
      handler_name    : SoundHandler

Tags: , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Mittwoch, 31. März 2021

Cacti motzt über cactiNotifyDeviceFailedPoll

SNMPAGENT WARNING: No notification receivers configured for event: cactiNotifyDeviceFailedPoll (CACTI-MIB), severity: medium

Die Lösung: Aus irgendeinem Grund wurde in der Administrationsoberfläche folgende Einstellung aktiviert, die man nun deaktivieren sollte, wenn man die Fehlermeldung nicht mehr im Log sehen möchte:

  1. Console
  2. Configuration
  3. Settings
  4. Poller
  5. SNMP Agent Support von Enabled auf Disabled setzen

Quelle: about snmpagent warning

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