Posts Tagged ‘EdgeRouter-X’

Donnerstag, 22. September 2022

ddclient: WARNING: found neither ipv4 nor ipv6 address

Seit dem 19. September meldet ein von mir verwalteter Router sporadisch folgendes Problem bei der Aktualisierung der IP einer Dynamischen DNS-Adresse (mein DynDNS Anbieter: no-ip.com; sunrise upc ist der ISP, an welchem der Router hängt):

Sep 19 14:00:13 ROUTER ddclient[2733]: WARNING:  found neither ipv4 nor ipv6 address

Bis jetzt konnte ich das Problem nicht lösen. Mittlerweile habe ich den DynDNS-Service auf dem EdgeRouter ER-4 deaktiviert, und führe stattdessen auf einem Debian GNU/Linux-System im dahinterliegenden LAN ddclient aus.

Leider hat das auch nicht komplett geholfen, obwohl die Fehlermeldungen weniger wurden:

Sep 22 12:31:56 SERVER ddclient[3248354]: WARNING:  found neither ipv4 nor ipv6 address

Als ich gestern das Problem analysiert habe, fiel mir Folgendes auf:

$ host checkip.dyndns.org
checkip.dyndns.org is an alias for checkip.dyndns.com.
checkip.dyndns.com has address 132.226.247.73
checkip.dyndns.com has address 193.122.130.0
checkip.dyndns.com has address 158.101.44.242
checkip.dyndns.com has address 132.226.8.169
checkip.dyndns.com has address 193.122.6.168

$ wget "http://checkip.dyndns.org/"
--2022-09-22 01:42:06--  http://checkip.dyndns.org/
Resolving checkip.dyndns.org (checkip.dyndns.org)... 132.226.247.73, 132.226.8.169, 193.122.130.0, ...
Connecting to checkip.dyndns.org (checkip.dyndns.org)|132.226.247.73|:80... connected.
HTTP request sent, awaiting response... 502 Bad Gateway
2022-09-22 01:42:09 ERROR 502: Bad Gateway.

$ wget "http://checkip.dyndns.org/"
--2022-09-22 01:42:48--  http://checkip.dyndns.org/
Resolving checkip.dyndns.org (checkip.dyndns.org)... 132.226.8.169, 193.122.130.0, 158.101.44.242, ...
Connecting to checkip.dyndns.org (checkip.dyndns.org)|132.226.8.169|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 105 [text/html]
Saving to: ‘index.html’

index.html              100%[===============================>]     105  --.-KB/s    in 0s      

2022-09-22 01:42:50 (8.82 MB/s) - ‘index.html’ saved [105/105]

Es scheint, als würde entweder eine der 5 IPs hinter checkip.dyndns.org streiken, oder aber der ERROR 502-Fehler tritt unregelmässig bei allen IPs auf.

Ob das aber wirklich das Problem hinter den Fehlermeldungen ist, kann ich derzeit nicht sagen.

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

1 Kommentar | 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

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

Donnerstag, 31. Mai 2018

Init7 TV7: Installation mit einem Ubiquiti Edgerouter X SFP

(Folgeartikel zum Artikel Init7 TV7: Installation mit einem Turris Omnia-Router)

An einem Zweitstandort betreibe ich einen Ubiquiti Edgerouter X SFP (Firmware v1.10.0) mit einem offiziellen FlexOptix-Transceiver von Fiber7. Damit dieser Router IPTV-Multicast ins LAN weiterleitet, waren folgende Anpassungen an der Konfiguration nötig (hat mich 90 Minuten meines Lebens gekostet):

Firewall

Auf rudimentärem Deutsch: Lasse IGMP sowie Multicast UDP durch die Firewall gegen das Internet

...
firewall {
    ...
    name WAN_IN {
        ...
        rule 4 {
            action accept
            description "Allow IGMP (max)"
            log disable
            protocol igmp
        }
        rule 5 {
            action accept
            description "Allow Multicast"
            destination {
                address 224.0.0.0/4
            }
            log disable
        }
    }
    name WAN_LOCAL {
        ...
        rule 4 {
            action accept
            description "Allow IGMP"
            log disable
            protocol igmp
        }
        ...
    }
    ...
}
...

IGMP Proxy

Auf rudimentärem Deutsch: Empfange IGMP-Traffic aus dem Internet und leite ihn in das LAN weiter.

...
protocols {
    igmp-proxy {
        interface switch0 {
            alt-subnet 0.0.0.0/0
            role downstream
            threshold 1
        }
        interface eth5 {
            alt-subnet 0.0.0.0/0
            role upstream
            threshold 1
        }
    }
    ...
}

Multicast-Status abfragen

Um zu überprüfen, ob Multicast grundsätzlich funktioniert, loggt man sich per SSH auf den Router ein und gibt im CLI folgende Befehle ein:

$ show ip multicast interfaces 
Intf             BytesIn        PktsIn      BytesOut       PktsOut            Local
switch0            0.00b             0       31.17MB         24316        Y.Y.Y.1
eth5             31.17MB         24316         0.00b             0   X.X.X.X
$ show ip multicast mfc
Group           Origin           In          Out                Pkts         Bytes  Wrong
239.254.127.63  Y.Y.Y.5        eth5        switch0               1       116.00b      1
239.255.255.250 Y.Y.Y.50       eth5        switch0              56       17.61KB     56
239.77.3.21     77.109.129.16    eth5        switch0           37379       47.91MB      0

Die letzte Zeile war das Resultat, dass ich probehalber Dracula Untold auf Film 4 geschaut habe …

Nachtrag 1: Stream friert ein

Nach der Installation der TV7-App auf dem Apple TV (eigener Blog-Artikel zur App) musste ich entdecken, dass das Bild eines TV-Senders jeweils nach etwas mehr als 3 Minuten einfror (ich tippte nach mehreren Messungen auf ein Timeout von 200 Sekunden — und somit ein strukturelles Problem).

Recht schnell realisierte ich nach etwas Googlen, dass die Firewall-Regel 4 unter WLAN_LOCAL zwingend auch aktiviert werden muss. Diese hatte ich ursprünglich als überflüssig erachtet. Mein Fehler.

Meine Vermutung als IPTV-Laie: Diese (zusätzliche) Regel erlaubt ausgehende IGMP-Pakete. Wenn diese nicht an TV7 gesendet werden können (Heartbeat?), stellt TV7 den Multicast wieder ein. Sobald die Firewall-Rule aktiviert wurde, entfror sich das Bild und die Sendung lief weiter.

Nachtrag 2: Multicast flutet das Netzwerk

Obwohl die Streams nun auf dem Apple TV mit der offiziellen App problemlos laufen, habe ich einen schwerwiegenden Nachteil entdeckt, welcher bei meinem Turris Omnia nicht auftritt: Schaut man mit dem Apple TV einen TV7-Stream, wird das ganze LAN mit Multicast-Paketen geflutet. Dies beeinflusst meinen UniFi Access Point besonders, konnte ich doch einen spürbaren Lag zwischen Tastendruck und Anzeige des Buchstabens auf dem Bildschirm feststellen, wenn ich von meinem MacBook per WLAN per SSH auf einem Laptop im LAN verbunden war.

In meiner derzeitigen Konfiguration sendet der Edgerouter den eingehenden Multicast-Traffic an alle LAN-Interfaces weiter, die am switch0 hängen. Leider habe ich bis jetzt noch keine Lösung gefunden, wie man das auf einzelne Ports einschränken kann (ich brauche eigentlich nur den Apple TV- sowie den Laptop-Port, auf welchem udpxy läuft) respektive wie man IGMP-Snooping aktivieren kann, damit der Edgerouter selber realisiert, welches Gerät/welche Geräte im Netzwerk aktuell gerade Multicast-Streams abspielen möchte.

Links

Tags: , , , , , , , , , , ,
Labels: IT, Linux, Medien, Schweiz

4 Kommentare | neuen Kommentar verfassen

Samstag, 14. April 2018

Ein Backup oder eine alte Version einer Ubiquiti Edgerouter-Konfiguration einspielen

Ich habe bei Bekannten derzeit je ein Ubiquiti Edgerouter X in Betrieb, welche als Router an einem Kabelmodem angeschlossen sind.

Die Router habe ich so konfiguriert, dass sie bei jeder Aktualisierung der Konfiguration über das Web-GUI resp. das CLI ein Backup der vorherigen Konfiguration per TFTP auf einen Linux-Laptop im lokalen Netz ablegen. Dies mit der folgenden Konfiguration:

...
system {
    config-management {
        commit-archive {
            location tftp://10.1.2.3/
        }
        commit-revisions 10
    }
...
}
...

Gestern trat der Notfall ein, dass ich einen der Router komplett zurücksetzen musste und danach eine ältere Version der Konfiguration einspielen wollte.

Dies ist recht trivial: Auf dem Linux-Laptop, auf welchem die Konfiguration versioniert ist, kopiert man das Backup folgendermassen auf den auf Fabrikzustand zurückgesetzten Router:

$ scp config.boot-ROUTER.20180413_133604 ubnt@10.1.2.1:/config

Das Kennwort lautet ubnt und sollte in der so übermittelten Konfiguration zwingend angepasst werden.

Anschliessend verbindet man sich per SSH mit dem Router und führt folgende Befehle aus (compare ist nicht nötig, zeigt aber schön auf, welche Anpassungen zur derzeit aktiven Konfiguration vorgenommen werden):

$ configure
$ load /config/config.boot-ROUTER.20180413_133604
$ commit
[$ compare]
$ save

Quelle: Re: Swap X-SFP to Pro8 – can we upload config.boot from X-SFP?

Siehe auch: EdgeRouter – Archiving and Managing the Configuration Files — Saving and Loading Backup Configurations

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

Keine Kommentare | neuen Kommentar verfassen

Donnerstag, 22. März 2018

Ubiquiti Edgerouter und DynDNS hinter einem doppelten NAT

Kürzlich musste ich einen Ubiquiti Edgerouter ER-X temporär hinter einem doppelten NAT betreiben (dass das nicht optimal sein kann, weiss ja wohl jeder).

Obwohl DynDNS auf dem Edgerouter konfiguriert war, um den statischen Hostnamen mit der jeweils aktuellen dynamischen IP anzupassen, funktionierte dies in einer solchen Konfiguration nicht mehr: Der Router meldete seine private IP-Adresse (192.168.0.X) am WAN-Port an DynDNS, was natürlich nicht funktionieren kann.

Damit der Edgerouter in solchen Situationen zuverlässig die öffentliche IP-Adresse des Anschlusses verwendet, muss über das GUI unter Config Tree > service > dns > dynamic > interface > eth0 des Routers das Attribut web mit dem Wert dyndns ergänzt werden:

Damit ist sichergestellt, dass der Router nicht die IP seines eth0-Interfaces zurückmeldet, sondern über den Web-Service von DynDNS seine öffentliche IP anfragt.

Wer das CLI bevorzugt:

$ configure
# set service dns dynamic interface eth0 web dyndns
# commit
# save

Quelle: Dynamic DNS behind double NAT?

Tags: , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 7. Mai 2017

Ein Gästenetzwerk auf dem Ubiquiti EdgeRouter-X vom restlichen Netzwerk isolieren

Heute habe ich meinen ersten EdgeRouter-X in Betrieb genommen. Die Konfiguration war etwas gewöhnungsbedürftig, aber im Zusammenspiel mit Web-GUI und CLI hat es tatsächlich geklappt. Am meisten schätze ich, dass die Konfiguration des Routers eine simple Text-Datei ist, die man mit Subversion (oder: Git) versionieren kann und bei Bedarf mit ein paar Handgriffen für neue Umgebungen oder zusätzliche Installationen anpassen kann.

Da solche Ubiquiti-Geräte semi-professionelle Router und Switches sind, habe ich heute auch einen lang ersehnten Spezialfall umgesetzt: Am Installationsort teilen sich Vermieter und Mieter einen Internetanschluss. Der Vermieter möchte dabei aber dem Mieter aber eigentlich nur den Internetzugang ermöglichen und ihn aus dem heimischen LAN heraushalten.

Dies ist nicht sonderlich kompliziert, da der Mieter ein Ethernet-Kabel vom Router auf seinen Switch gezogen hat — es muss also einfach ein Faden geschützt werden.

Mit WLAN stellt man dies mit einer zweiten SSID sicher, die im UniFi-Controller als Gästenetzwerk konfiguriert wird. Auf Ethernet-Ebene ist es etwas komplizierter. Doch freundlicherweise hat sich ein geschätzter Zeitgenosse die Zeit genommen, genau diesen Use Case zu dokumentieren:

Setting up a guest network with the EdgeRouter Lite

Zwei kleine Anpassungen habe ich gemacht:

  1. Im DHCP-Server gebe ich als DNS die Server von Cablecom mit, weshalb sich aus meiner Sicht eine Firewall-Regel für internes DNS erübrigt.
  2. Als Privates Netz habe ich 192.168.1.0/24 gewählt und nicht 172.16.x.x.

Die Trennung mittels VLANs und Firewalls ist nun eingerichtet, aktiv und versioniert — leider konnte ich den Mieter aber noch nicht fragen, ob seine Geräte damit auch weiterhin funktionieren.

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

Keine Kommentare | neuen Kommentar verfassen