Posts Tagged ‘Latenz’

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, 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

Montag, 20. April 2020

upc kappt Peering mit Init7 / Fiber7

Ich habe vor einigen Jahren mit OpenVPN ein Site-to-Site VPN zu einem Bekannten in der Agglomeration Bern aufgebaut und betreibe dieses VPN bis heute.

Der Bekannte ist Kunde von upc cablecom (der schnellste und preiswerteste Anbieter in der Agglomerationsgemeinde) mit einem 300 MBit/s Download-Abo, ich als Städter bekanntermassen Kunde von Fiber7 mit (theoretisch) symmetrischen 1 GBit/s.

Letzte Woche (KW16 2020) waren SSH-Verbindungen zu einem Server beim Bekannten auf einmal sehr, sehr hakelig — die Latenz zwischen Tastatureingabe und erscheinen des Zeichens auf dem Bildschirm war sehr hoch. Bestätigt wurde diese durch meine Überwachung der Geschwindigkeit mit speedtest-cli und Aufzeichnung und Visualisierung der Werte mit Cacti:

Der Einbruch am Dienstag-Morgen war offensichtlich.

Eine fiebrige, verbissene Suche begann: War ein Angreifer in das Netzwerk eingedrungen und zog nun Gigabyte-weise an Daten ab? Oder war ein Rechner eines Mitbenutzers von Malware gekapert worden? Oder führte der Mitbenutzer einfach nur tonnenweise Bittorrent-Downloads durch? Oder war eine Netzwerkkomponente ausgetickt und flutete das Netzwerk und den Router mit Paketen? Oder hatte upc cablecom einfach etwas am Netzwerk geschraubt, worauf der Geschwindigkeitseinbruch manchmal nur mit einem Neustart des Modems behoben werden konnte?

Die Nachforschungen brachten nichts zu Tage, aber immerhin lernte ich folgende Netzwerkanalyse-Tools/Features meiner Infrastruktur kennen:

  • Traffic Analysis des EdgeRouters X ER-X, welcher am Kabelmodem hängt
  • iftop Zeigt in Echtzeit an, von und zu welchen IPs ein Server Daten übertragt (Homepage)
  • iptraf-ng (Homepage)

Am Dienstag-Abend ereilte mich ein Geistesblitz: speedtest-cli misst die Geschwindigkeit von einem Server am Agglomerations-Standort zum Ookla Speedtest-Server von Init7 (Server „Init 7 (Winterthur, Switzerland)“ mit ID 3026). Aus Interesse wählte ich einen anderen Server aus der Liste aus, und zwar den Speedtest-Server von Sunrise. Zuerst führte ich einen manuellen Speedtest zu Init7 durch, danach zu Sunrise. Und siehe da, hier lag die Antwort wie auf dem Präsentierteller:

$ ./speedtest-cli --server 28045
Retrieving speedtest.net configuration...
Retrieving speedtest.net server list...
Testing from UPC Schweiz (80.218.X.X)...
Hosted by Sunrise Communication AG (Lausanne) [6X.XX km]: 30.667 ms
Testing download speed........................................
Download: 302.88 Mbit/s
Testing upload speed..................................................
Upload: 42.32 Mbit/s

$ ./speedtest-cli --server 3026
Retrieving speedtest.net configuration...
Retrieving speedtest.net server list...
Testing from UPC Schweiz (80.218.X.X)...
Hosted by Init 7 (Winterthur) [13X.XX km]: 165.956 ms
Testing download speed........................................
Download: 25.82 Mbit/s
Testing upload speed..................................................
Upload: 9.48 Mbit/s

Am selben Abend sendete ich eine Anfrage an Init7 raus, ob und wie sie sich diesen markanten Geschwindigkeits-Unterschied erklären können. Am Morgen hatte ich die Antwort, und wurde auf folgendes Schreiben verwiesen. Diese Meldung war bei mir im Corona-Trubel vollkommen untergegangen.

Fazit: upc cablecom, how dare you?

Nachtrag

smokeping visualisiert die Latenz von DNS-Abfragen aus dem upc cablecom-Netz gegen den DNS-Server von Init7 ebenfalls sehr schön:

Auf Wunsch Thomas‘ (siehe Kommentar unten) noch dieselbe Grafik für Test-Abfragen an einen der DNS-Server der upc cablecom (ns10.cablecom.net) …

… zu Swisscom (dns2.bluewin.ch) …

… und zu Sunrise (cache02.sunrise.ch)

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

7 Kommentare | neuen Kommentar verfassen

Sonntag, 15. Oktober 2017

Nach einem RAM-Upgrade eines iMacs laufen die Module nur noch mit 1600 MHz

Kürzlich habe ich mir einen iMac Late 2015 mit 27 Zoll Retina-Display geleistet. Nun haben ausnahmslos all meine Apple-Geräte (iPhone, iPad, iMac, MacBook) Retina-Auflösung.

Die popeligen 8GB RAM musste ich aber noch aufrüsten, weshalb ich mir zusätzlich zwei Mal 8GB Riegel geleistet habe. Nach der Installation dann die Ernüchterung: Während vor dem Upgrade die zwei Mal 4GB Riegel mit 1867 MHz angesprochen wurden, laufen die insgesamt vier Module nun nur noch mit 1600 MHz.

Wieso ist das so? Nach etwas Recherche die Antwort:

Die Originalbausteine von Apple haben eine CAS Latency CL von 13. Die zusätzlich installierten Module von Corsair mit der Produktenummer CMSA16GX3M2C1866C11 haben dagegen CL 11.

Dies führt zu folgendem Verhalten:

EDIT: Actually, looks like it’s just that the default RAM can’t run below CL13 at 1866, so when you add another set of 1866 with a lower CL, it decides to slow it down so it can match the faster CL at the cost of lower frequency.

Quelle: Late 2015 iMac Not Picking up 1866MHz RAM

Doch offenbar spürt man diese Verlangsamung im Alltag nicht, wie jemand in einem anderen Thread erklärt:

RAM speed is one of those things that really only helps at the margins, and isn’t worth stressing about too terribly much (unless you use onboard graphics that use regular RAM for VRAM). That said…
The formula for figuring out the true latency (as opposed to CAS latency) is: CAS latency / clock speed. That’s a measure of time, usually expressed in nanoseconds, and you want to minimize it. The two kits you mentioned:

  • 14 / 2400000000 = 6 ns
  • 16 / 3333000000 = 5 ns

On paper, the 3333 MHz RAM wins. But in the real world, you won’t actually notice a difference between the two. So get whichever you would prefer.

Quelle: Choosing DDR4: Clock vs Latency? C14 vs C16

Tags: , , , , , , , , , , , , , , , , ,
Labels: Apple

Keine Kommentare | neuen Kommentar verfassen