Archiv ‘IT’

Samstag, 13. September 2025

Synology NAS: TOTP-Code wird nicht (mehr) akzeptiert

Link zu diesem Artikel

Vorletzte Nacht wollte ich mich seit Langem wieder einmal in mein Synology NAS einloggen.

Das Administrator-Konto habe ich mit einem Time-based One-Time Password (TOTP) geschützt.

Leider wurde der von 1Password gelieferte Code irgendwie nicht akzeptiert. Die Fehlermeldung habe ich mir leider nicht notiert, doch eine Google-Suche leitete mich zu folgendem Artikel:

Why is my mobile device’s time different from my Synology NAS?

Zum Glück hatte ich auf dem NAS den Zugang zu einem Mail-Server konfiguriert und dem Administratorenkonto eine Email-Adresse hinterlegt. Deshalb wurde mir auf dem Login-Screen neben der Fehlermeldung die Möglichkeit angeboten, einen Einmal-Code emailen zu lassen. Das tat ich auch, und konnte mich mit dem Code einloggen.

In den Benutzerkonto-Einstellungen starte ich dann den Versuch, die Zwei-Faktor-Authentifizierung zu deaktivieren, und erneut einzurichten.

1Password auf meinem Mac erkannte den QR-Code leider nicht (das Problem besteht seit dem Upgrade auf 1Password 8, und auf macOS Sequoia: höchst enttäuschend, so ein nützliches Feature!), weshalb ich kurzerhand 1Password auf meinem iPhone verwendete. Die Kamera erkannte den QR-Code und fügte den Seed dem Login-Eintrag hinzu. Doch als ich den Code zur Bestätigung in das dafür vorgesehene Formular eintrug und absendete, erhielt ich folgende Fehlermeldung:

Code authentication failed. Please make sure the verification code you entered is correct or try synchronizing the system time of your mobile device and DSM. Refer to this article for details.

Was zum Teufel?!

Doch der aufmerksame Leser wird die Antwort vermuten: Für einmal war die Fehlermeldung wirklich hilfreich, und akkurat: Die Zeit des NAS ging eine halbe bis eine Minute hinter der tatsächlichen Uhrzeit nach. Für TOTP „tödlich“.

Dies sieht man im Control Panel unter Regional Options. Dort gibt es auch die Möglichkeit, einen NTP-Server zu erfassen. Der war in meinem Fall tatsächlich erfasst und lautete auf time.google.com — doch im Status-Feld unterhalt stand nicht „Normal“ in grüner Schrift.

Ich erfasste deshalb die IP eines lokalen Linux-Servers, auf welchem NTP läuft, speicherte die Einstellungen, und forcierte die Aktualisierung der Uhrzeit. Danach klappte das generieren und verifizieren des TOTP-Codes problemlos.

Gleich anschliessend passte ich die NTP-Einstellungen auf allen Synology NAS in meinem Fuhrpark an, um dieses Problem künftig zu vermeiden. Jetzt muss ich einfach nur sicherstellen, dass die lokalen NTP-Server stetig funktionieren.

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

Keine Kommentare | neuen Kommentar verfassen

Dienstag, 5. August 2025

Gelöst: Das Mysterium der nicht adoptierbaren UniFi Switches

Link zu diesem Artikel

TL;DR

Das ist der verfluchte Übeltäter: UniFis DHCP Guarding

Wie üblich in der IT eine eigentlich gut gemeinte Sicherheitsfunktion, die mich unzählige Stunden an Debugging gekostet hat:

Aus irgendeinem Grund war diese Funktion auf dem UniFi Controller, welcher früher bei einer Bekannten in Gebrauch war, aktiviert. Und nicht nur aktiviert, auch die eingetragene IP des DHCP-Servers stimmte nicht; anstelle des Servers war das Gateway eingetragen, welches hier keine DHCP-Funktionen (mehr?) ausübt.

Problembeschreibung

Seit dem Bezug der Wochenaufenthalter-Wohnung in Zürich hatte ich ein nerviges Problem:

Mir gelang es seinerzeit nicht, zwei gebrauchte, aktuell nicht mehr im Einsatz befindliche UniFi-Switches vom Typ US-8 und US-8-60W mit einem auf einem Debian Server laufenden UniFi Controller zu koppeln. Sie tauchten im nicht-adoptierten Zustand im Netzwerk auf, erhielten vom auf dem Linux-Server laufenden DHCP eine IP zugewiesen (static leases basierend auf deren MAC-Adresse) und erschienen im UniFi Controller als adoptierbare Geräte. Ich konnte die Switches anpingen. Doch sobald ich den Switch adoptierte, dauerte es ein paar Minuten, dann hiess es „Adoption failed“, der Switch zeigte im UniFi Controller die IP 192.168.1.20 und konnte nicht mehr angepingt werden. Da ich ursprünglich den Access Point auch noch hinter dem Switch betrieb, verlor dieser dann lustigerweise auch die Verbindung zum Netzwerk (rückblickend ein Indiz auf das zu Grunde liegende Problem, aber dazu später mehr).

In dieser Situation, in welche ich mich sicherlich ein gutes dutzend Mal hineinmanövrierte, half dann jeweils nur der physische Reset des Switches: Mit einer Büroklammer drückte ich auf den Reset-Knopf, hielt den 10 Sekunden gedrückt, und nach dem loslassen starte der Switch den Factory Reset.

Im UniFi Controller gab ich beim Switch dann den Befehl, diesen zu vergessen („Forget“), und schlussendlich tauchte der Switch irgendwann wieder in jungfräulicher Form in der Liste auf.

Erneuter Versuch

Gestern verschob ich aus Lärmgründen das kleine 1-Disk Synology NAS vom Router in die andere Ecke der Wohnung, weshalb ich es intelligent fand, in der Ecke auch einen der beiden Switches zu installieren — zumal ich in der Ecke auch den UniFi U6-LR platziert habe, der bis dahin von einem PoE-Injektor beim Router gespeist wurde.

Einschub: Der US-8-60W (!) liefert auf seinen PoE-Ports nicht ausreichend Strom, um einen U6-LR mit Strom zu versorgen. Dies führt dazu, dass der Access Point regelmässig abstürzt und im UniFi Controller eine entsprechende Warnmeldung aufpoppt. Somit verwende ich bis zur Ankunft des USW-Lite-8-POE weiterhin den PoE Injector. Hässlich, aber als temporärer Workaround machbar.

Selbstverständlich endete ich innert weniger Minuten wieder in der oben beschriebenen Situation.

Das Debugging begann erneut — dieses Mal wollte ich das Problem ein für allemal nachhaltig lösen.

Wirklich Factory Reset?

Waren die Geräte wirklich auf die Werkseinstellungen zurückgesetzt? Wie ich nach einer Weile herausfand, ist das ganz einfach zu überprüfen: Die Switches sind im nicht-adoptierten Zustand per SSH zu erreichen. Wenn in Werksteinstellungen, kann man sich mit folgenden Daten einloggen:

  • Benutzernamen: ubnt
  • Kennwort: ubnt

Das funktionierte in der Tat mit beiden Switches. Um ganz sicherzugehen kann man — ist man erst einmal eingeloggt — noch folgenden Befehl ausführen:

# set-default
Clearing CFG ... [%100] done!
syswrapper: restart triggered by restore-default

Dies hat denselben Effekt wie man den Switch physisch mit der Büroklammer zurücksetzt.

Ist der Controller erreichbar?

Ist man auf dem Switch eingeloggt, kann dem Switch sagen, wo sich der UniFi Controller befindet:

# set-inform "http://1.2.3.4:8080/inform"
Adoption request sent to 'http://1.2.3.4:8080/inform'.  Use UniFi Network to complete the adopt process.

Die URL kann man auch in einem Browser öffnen, und es sollte einem keine Fehlermeldung entgegenstarren.

Das war hier der Fall, ich sah ein leeres, weisses Browser-Fenster, was signalisiert, dass der Server antwortet.

Leider macht dieser Befehl nichts; er dient dazu, das Gerät mit dem UniFi Controller bekannt zu machen, wenn dieses aus irgendeinem Grund nicht automatisch auftaucht.

Zu neue Switch Firmware mit altem Controller?

Irgendwann entdeckte ich mit Schrecken, dass die Switches zwar auf der neuesten verfügbaren Firmware liefen (7.1.26, gemass UniFi Controller, aber auch der Shell-Linie), doch der UniFi Controller noch auf Version 7 festsass. Aktuell ist Version 9.

Es folgte ein langwieriges, stundenlanges Upgrade, welches ich hier nicht im Detail beschreiben möchte. Nur soviel: Zuerst musste ich von Bullseye auf Bookworm aktualisieren. Dann musste ich MongoDB Paketverzeichnis vom Hersteller direkt einbinden, nur um zu realisieren, dass die CPU des Lenovo ThinkPads, auf welchem Debian läuft, den AVX Befehlssatz nicht unterstützt, welcher seit MongoDB 5 benötigt wird. Nach einem gescheiterten Selbstkompilationsversuch fand ich dann einen Weg, um das letzte kompatible MongoDB-Release (4.4.26) zu installieren. Danach musste ich UniFi mit einem Backup migrieren, sowie viele andere Services, welche wegen dem Upgrade kaputt gegangen waren.

Nur um schlussendlich zu realisieren, dass das Adoptionsproblem auch weiterhin bestand.

DHCP-Logs

Der Lösung (unbewusst) näher kam ich, als ich auf dem Debian Server die DHCP-Logs genauer anschaute. Dort sah ich nach der Adoption im Sekundentakt folgende Einträge:

...
Aug  4 04:25:03 SERVER dhcpd[212067]: DHCPDISCOVER from 00:11:22:33:44:55 via eth0
Aug  4 04:25:03 SERVER dhcpd[212067]: DHCPOFFER on 1.2.3.4 to 00:11:22:33:44:55 via eth0
Aug  4 04:25:06 SERVER dhcpd[212067]: DHCPDISCOVER from 00:11:22:33:44:55 via eth0
Aug  4 04:25:06 SERVER dhcpd[212067]: DHCPOFFER on 1.2.3.4 to 00:11:22:33:44:55 via eth0
Aug  4 04:25:09 SERVER dhcpd[212067]: DHCPDISCOVER from 00:11:22:33:44:55 via eth0
Aug  4 04:25:09 SERVER dhcpd[212067]: DHCPOFFER on 1.2.3.4 to 00:11:22:33:44:55 via eth0
Aug  4 04:25:22 SERVER dhcpd[212067]: DHCPDISCOVER from 00:11:22:33:44:55 via eth0
Aug  4 04:25:22 SERVER dhcpd[212067]: DHCPOFFER on 1.2.3.4 to 00:11:22:33:44:55 via eth0
Aug  4 04:25:25 SERVER dhcpd[212067]: DHCPDISCOVER from 00:11:22:33:44:55 via eth0
Aug  4 04:25:25 SERVER dhcpd[212067]: DHCPOFFER on 1.2.3.4 to 00:11:22:33:44:55 via eth0
Aug  4 04:25:28 SERVER dhcpd[212067]: DHCPDISCOVER from 00:11:22:33:44:55 via eth0
Aug  4 04:25:28 SERVER dhcpd[212067]: DHCPOFFER on 1.2.3.4 to 00:11:22:33:44:55 via eth0
Aug  4 04:25:41 SERVER dhcpd[212067]: DHCPDISCOVER from 00:11:22:33:44:55 via eth0
Aug  4 04:25:41 SERVER dhcpd[212067]: DHCPOFFER on 1.2.3.4 to 00:11:22:33:44:55 via eth0
Aug  4 04:25:44 SERVER dhcpd[212067]: DHCPDISCOVER from 00:11:22:33:44:55 via eth0
Aug  4 04:25:44 SERVER dhcpd[212067]: DHCPOFFER on 1.2.3.4 to 00:11:22:33:44:55 via eth0
Aug  4 04:25:47 SERVER dhcpd[212067]: DHCPDISCOVER from 00:11:22:33:44:55 via eth0
Aug  4 04:25:47 SERVER dhcpd[212067]: DHCPOFFER on 1.2.3.4 to 00:11:22:33:44:55 via eth0
Aug  4 04:26:00 SERVER dhcpd[212067]: DHCPDISCOVER from 00:11:22:33:44:55 via eth0
Aug  4 04:26:00 SERVER dhcpd[212067]: DHCPOFFER on 1.2.3.4 to 00:11:22:33:44:55 via eth0
...

Der Switch versuchte verzweifelt, ein DHCP-Lease zu kriegen, aber aus irgendeinem Grund kam die Antwort nicht beim Switch an. Das war auch die Erklärung dafür, weshalb der Switch sich die UniFi Standard-IP 192.168.1.20 zuteilte, wenn dann zum Tragen kommt, wenn der Switch keine IP beziehen kann.

AppArmor

Bei BIND- und DHCP-Problemen mit Debian kann auch immer AppArmor das Problem sein. Da sich dieser Service schlecht deinstallieren lässt (respektive er sich irgendwie immer wieder selber installiert), ist es besser, mit entsprechender Konfiguration dafür zu sorgen, dass nur gewarnt, und nicht geblockt wird. Auf dem Server habe ich diese Einstellungen aktiv. Ich führte das Script zur Sicherheit noch einmal aus, doch das änderte leider nichts an der Sache.

Irgendwann gab ich auf und ging schlafen.

Die Lösung

Heute wählte ich mich mit Wireguard aus der Ferne in das Netzwerk ein, um im UniFi Controller etwas nachzuschauen. Aus irgendeinem Grund endete ich in den Netzwerk-Einstellungen, und … da starrte mich plötzlich die Option DHCP Guarding an.

Auf einmal war alles klar: Diese Scheiss-Funktion wird auf UniFi-Geräten erst aktiv, wenn man es adoptiert und die Konfiguration ausgerollt hat. In meinem Fall führte dies dazu, dass der Switch sich selber ins Knie schoss, sprich: Er verlangte vom DHCP-Server eine IP, doch diese Schutzfunktion verhinderte, dass der Switch die zugeteilte IP erhielt und konfigurieren konnte. Absolut schizophren.

Nicht nur das: Jetzt war mir auch klar, was mit den am Switch angeschlossenen Geräten passierte — sei es NAS, aber auch Access Point. Diese Geräte fragten beim DHCP-Server auch nach IPs an, doch die Pakete wurden vom Switch blockiert und kamen dementsprechend nicht bei den Endgeräten an. Nicht nur das — da am Switch zu Testzwecken noch der zweite Switch hing, und der Access Point, fielen diese alle zusammen auf 192.168.1.20 zurück. Das bedeutete, dass ich im Netzwerk insgesamt drei Geräte mit derselben nicht routbaren IP hatte.

Heute Abend kam ich nach Hause, deaktivierte die DHCP Guarding-Funktionalität, adoptierte zuerst einen Switch — was innert 1–2 Minuten erfolgreich war, und anschliessend noch den zweiten Switch. HALLELUJA!

(Nicht hilfreiche) Links

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

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 15. Juni 2025

Festplatten von einer defekten Synology DS416j wegmigrieren

Link zu diesem Artikel

Kurz: Festplatten aus der DS416j raus, und in der richtigen Reihenfolge in die DS423 rein. Starten, über die Web-Oberfläche die Migration durchführen, und das NAS läuft wieder wie auf der alten Kiste aus 2016. Inklusive der gesamten Konfiguration.

Ich hatte grosses Glück, denn die HDD Migration Matrix zeigt, dass man nicht kreuz und quer migrieren kann. Mein Fall, die Migration von einem J Series NAS auf die Value Series, wird unterstützt:

Quelle: Migrate From Old Synology To A New NAS

Tags: , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Samstag, 14. Juni 2025

Ein ZTE MF79U 4G USB-Modem unter Debian zum Laufen bringen

Link zu diesem Artikel

Ich habe mir kürzlich über Amazon ein ZTE MF79U 4G Mobilfunkmodem gekauft. Zusätzlich dazu noch eine Digitec IoT SIM mit 0.4 MBit/s (Anbieter: digital republic), welche im Jahr mit 44 CHF zu buche schlägt.

Einsatzzweck: Out-of-band (OOB) Lösung an einem WLAN-Travelrouter einer Bekannten. Der Router verbindet sich als WLAN-Client mit einem WLAN-Netzwerk eines Drittanbieters (analog zu einem Gäste-WiFi in einem Hotel), welches quartalsweise ein neues WLAN-Passwort erhält (ja, der Anbieter ist noch nicht auf die Idee gekommen, das WLAN zu öffnen und stattdessen mit Portal-Technologie zu arbeiten, welche einzelne Clients mit Benutzernamen und Passwort authentifziert).

Ich möchte damit künftig vermeiden, dass ich vor Ort das WiFi-Kennwort anpassen gehen muss, damit sich der WLAN-Travelrouter wieder mit dem WLAN-Netzwerk der Institution verbindet.

Der Plan ist, dass künftig auf dem Travelrouter basierend auf OpenWRT über das 4G-Interface ein Reverse SSH Tunnel zu einem meiner Server geöffnet wird, über welchen ich dann aus der Ferne auf den Router und das Web-Interface zugreifen kann (meines Wissens könnte ich das Kennwort vermutlich auch auf der Kommandozeile wechseln, aber soweit bin ich noch nicht).

Gestern habe ich den USB-Stick an einem Debian-Server in Betrieb genommen. Was ich dabei gelernt habe:

Das Teil findet man sofort nach Anschluss mittels lsusb:

# lsusb
...
Bus 001 Device 006: ID 19d2:1405 ZTE WCDMA Technologies MSM ZTE Mobile Boardband

Die Bedeutung der Produkt-ID 1405 ist hier dokumentiert: ZTE MF 823 (Megafon M100-3) 4G Modem

1405

A communication mode in which the device has a wikipedia:USB communications device class interface in addition to the card reader interface. Communications Device Class (CDC) should work in Linux. The cdc_ether kernel module is required. This mode will be the one usb_modeswitch will switch the device into.

Der Stick stellt auch ein Block-Device (Speicher) zur Verfügung; das ist nur unter Windows nützlich, weil sich auf dem Datenträger die Treiber für den Stick finden. Clever!

# lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
...
sr0     11:0    1   6.8M  0 rom
# blkid
...
/dev/sr0: BLOCK_SIZE="2048" UUID="2022-06-21-14-31-58-00" LABEL="ZTEMODEM" TYPE="iso9660" PTTYPE="mac"

Der USB-Stick spannt ein eigenes WLAN-Netzwerk auf, sobald er Strom hat. IP-Adressbereich ist 192.168.0.1/24. Die SSID und das Kennwort findet man unter der Abdeckung des Sticks, welche einem Zugang zum physischen SIM-Slot erlaubt.

Der Stick hat eine Weboberfläche unter http://192.168.0.1/, mit welcher man alle möglichen Einstellungen vornehmen kann. Das admin-Kennwort ist ebenfalls unter der Abdeckung aufgedruckt.

Ich musste meines Wissens eine Runde in der Web-Oberfläche drehen und die (bereits aktivierte) SIM-Karte einschalten, sonst hätte sich der Stick nicht mit dem Internet verbunden.

Der Clou: Verbindet man Geräte mit dem WiFi des USB-Sticks, können alle Geräte über die Mobilfunkverbindung ins Internet. Gemäss Web-Oberfläche ist die Zahl der Clients auf 10 beschränkt, diese Zahl scheint aber anpassbar zu sein.

Unter Debian wird der Stick problemlos auch als USB-basiertes Ethernet-Interface erkannt (Treiber: cdc_ether:

# lsmod | grep -i ether
cdc_ether              24576  0
usbnet                 57344  1 cdc_ether
usbcore               348160  8 ehci_pci,usbnet,usb_storage,uvcvideo,ehci_hcd,cdc_ether,uas,uhci_hcd
# ip a
...
5: enx344b50000000:  mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 34:4b:50:00:00:00 brd ff:ff:ff:ff:ff:ff

Damit man den Laptop über dieses Interface mit dem Internet verbinden kann, muss folgendes geschehen:

  • Interface hochbringen: ip link set enx344b50000000 up
  • IP-Adresse beziehen: dhclient enx344b50000000 -v
# dhclient enx344b50000000 -v
Internet Systems Consortium DHCP Client 4.4.1
Copyright 2004-2018 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/enx344b50000000/34:4b:50:00:00:00
Sending on   LPF/enx344b50000000/34:4b:50:00:00:00
Sending on   Socket/fallback
DHCPDISCOVER on enx344b50000000 to 255.255.255.255 port 67 interval 7
DHCPOFFER of 192.168.0.169 from 192.168.0.1
DHCPREQUEST for 192.168.0.169 on enx344b50000000 to 255.255.255.255 port 67
DHCPACK of 192.168.0.169 from 192.168.0.1
bound to 192.168.0.169 -- renewal in 38135 seconds.

Sobald der Server eine IP in der 192.168.0.1/24-Range besitzt, sollte man über dieses Interface ins Internet rauspingen können:

# ping -I enx344b50000000 1.1.1.1
PING 1.1.1.1 (1.1.1.1) from 192.168.0.169 enx344b50000000: 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=54 time=177 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=54 time=18.2 ms
^C
--- 1.1.1.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 18.203/97.527/176.851/79.324 ms

Die Frage ist nun, ob diese Schritte an einem OpenWRT-Router automatisiert werden kann.

Nachteil: Der Stick selber macht NAT, und somit kann man in Double-NAT-Situationen landen. Einige Sticks scheinen einen Bridge-Mode zu besitzen, doch diese Option habe ich bei meinem Stick nicht gefunden.

Nachtrag

Ich habe unter Linux beim rumpröbeln einige Pakete installiert, weiss aber nicht, ob das nötig gewesen wäre:

  • usb-modeswitch
  • ppp
  • libnss-myhostname
  • libnss-resolve
  • modemmanager

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

Keine Kommentare | neuen Kommentar verfassen

Dienstag, 25. März 2025

systemctl befindet sich bei unterschiedlichen Debian-Versionen an verschiedenen Orten

Link zu diesem Artikel

Kürzlich habe ich auf einem meiner Linux-Server einen Service nachgerüstet, welchen ich mit monit überwache, und gegebenenfalls neu starte.

Beim ersten Absturz des Services erhielt ich von monit folgende Fehlermeldung:

Execution failed Service homebridge 

	Date:        Mon, 24 Mar 2025 22:49:48
	Action:      alert
	Host:        SERVER
	Description: failed to start (exit status -1) -- Program /usr/bin/systemctl failed: File '/usr/bin/systemctl' does not exist

Your faithful employee,
Monit

Die Konfiguration hatte ich von einem anderen Linux-System kopiert, unter welchem Neustarts problemlos funktionierten.

Was ich nach etwas debuggen herausgefunden habe:

  • Unter Debian 11 (Kernel 5.10) befindet sich systemctl unter /bin/systemctl
  • Unter Debian 12 (Kernel 6.1.115-1) befindet sich systemctl unter /usr/bin/systemctl

Nachdem ich in der monit-Konfiguration den Pfad angepasst habe, funktioniert das Neustarten des Services nun problemlos.

Tags: , , ,
Labels: IT, Linux

Keine Kommentare | neuen Kommentar verfassen

Mittwoch, 12. Februar 2025

Die beste Intervall-Timer App für iOS

Link zu diesem Artikel

Nach meinem Ski-Unfall im Februar 2021 musste ich während der Rekonvaleszenz zu Hause täglich Physio-Übungen mit Wiederholungen machen (bspw. dehnen). Das heisst konkret: n Wiederholungen mit einer Dauer von n Sekunden, mit n Sätzen mit einer Verschnaufpause von n Sekunden zwischen den Sätzen.

Um mein Hirn davon zu entlasten und mich auf die Übungen zu fokussieren, stiess ich auf folgende iOS App, welche mit einem wunderschönen, benutzerfreundlichen Interface die benötigte Funktionalität bereitstellt:

Interval Timer • HIIT Timer

Labels: Apple, IT

Keine Kommentare | neuen Kommentar verfassen

Dienstag, 11. Februar 2025

UGREEN GaN USB-C Ladegeräte: Top!

Link zu diesem Artikel

Abdelkader Boui schreibt drüben auf Volker Webers Blog gerade über sein UGREEN GaN 100W USB-Ladegerät, welches auf Dienstreisen nicht mehr fehlen darf.

Bei mir ist es der kleinere Bruder, das UGREEN Nexode Pro 65W, welches auf meinen Reisen nicht mehr fehlt — ebenfalls mit GaN und deshalb extrem kompakt.

Mit dem Ladegerät lade ich mein gesamtes Equipment — das MacBook Air (USB-C), das iPad Air (USB-C), das iPhone 13 mini (USB-C auf Lightning), die Apple Watch Ultra (mit dem offiziellen Apple USB-C Fast Charging-Kabel), meine AirPods Pro (USB-C). Obwohl das Ladegerät nur 2 USB-C- und 1 USB-A-Anschluss hat, kam es noch nie zu Ladegerangel. Man muss aber entsprechend vorausdenken, und beispielsweise das MacBook über Nacht laden.

Für Länder mit US-amerikanischen Stromsteckern habe ich mir auf Amazon.com das entsprechende Pendant gekauft. Der Vorteil dieser Version: Die Ladestecker lassen sich einklappen.

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

Keine Kommentare | neuen Kommentar verfassen

Samstag, 21. Dezember 2024

Stromversorgung eines GL.iNet Slate AX (GL-AXT1800)

Link zu diesem Artikel

Für eine Bekannte habe ich diese Woche einen GL.iNet Slate AX (GL-AXT1800) gekauft und heute Samstag eingerichtet.

Um den Router in der Wohnung besser positionieren zu können, habe ich gestern eine alternative Stromversorgung gesucht. Einerseits ist das Netzteil sehr klobig, andererseits ist das kurze Stromkabel (mit USB-C-Anschluss) fix mit dem Netzteil verbunden. Ich kam zum Schluss, dass ich ein bis zu drei Meter langes Stromkabel benötige, um genügend Spielraum zu haben.

Auf dem Gerät steht: 5 Volt und 4 Ampere, d.h. das Gerät zieht bis zu 20 Watt, und benötigt somit auch ein Netzteil, welches bei 5 Volt mindestens 20 Watt liefern kann.

Schlussendlich habe ich auf Digitec folgendes Material gekauft:

Wieso ein USB-A auf USB-C Kabel? Weil ich folgende Forumsdiskussion gelesen habe:

Slate AX requirement for 4A adapter

Erkenntnis: Der Router spricht kein USB-C mit Power Delivery (PD). Somit kann man sich den Kauf eines reinen USB-C Netzteils sparen:

You can use any GaN power brick as long as you use a USB-A to USB-C cable. The router does not have true USB-C, its basically out of spec 5V (aka doesn’t have a PD chip, nor the resistors to tell USB-C to output 5V that are required). […] Also, the router only really needs 2A. The extra 2A are for external harddisks and other things you might connect to USB.

Quelle:

Auch wichtig zu wissen: Wie die Forumsteilnehmer (meiner Meinung nach korrekt) vermuten, sind 20 Watt die Spitzenleistung und die Ausnahme. Wer keine weitere Hardware am USB-A Port des Routers betreibt, sollte eine deutlich geringere Leistung messen. Oben werden 10 Watt genannt, tatsächlich gemessen gemäss diesem Post hingegen nur zwischen 4.5 bis 6 Watt.

Tags: , , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 8. September 2024

Hybrid7 mit Zyxel PM7300 und ZyWALL VPN100: Tips zum Debuggen

Link zu diesem Artikel

Gestern wurde ich zu einem Bekannten gerufen, um ihm bei der Installation seiner neuen Glasfaser-Verbindung zu helfen.

Ich hatte ihm Fiber7 wärmstens empfohlen, und er war meinem Ratschlag gefolgt. So konnte ich die Anfrage schlecht ausschlagen, aber im Grunde reizte es mich ungemein, ihm dabei zu helfen. Aber eigentlich hatte er auch keine grosse Wahl, da er seine bestehende Firewall weiterverwenden wollte, und das ist meines Wissens mit Swisscom als Glasfaser-ISP nicht möglich.

Leider ist seine Liegenschaft (wie auch die unsere) von Swisscom nur durch P2MP erschlossen worden. Zwar sind auf dieser Infrastruktur nun offenbar auch Drittanbieter erlaubt. Doch die Installation des Glasfaser-Anschluss ist nicht so einfach wie seinerzeit bei uns in Bern, wo unsere Mietwohnung mit vier Fasern erschlossen war, man das Glasfaserkabel in den richtigen Anschluss einsteckte, mit der Optik verband, dem Router die PPPoE-Zugangsdaten mitgab, und schon war man online.

Nach dem (glücklicherweise) schlussendlich erfolgreichen Installationsprozedere hat sich der Gedanke bei mir festgesetzt, dass der Monopolist das Onboarding absichtlich extrem kompliziert, dementsprechend fehleranfällig und langsam gestaltet hat, um die Konkurrenz auszuschalten. Aber wie gesagt, das ist nur eine Vermutung — vielleicht ist diese Technologie einfach deutlich komplizierter, und Swisscom hat das Beste daraus gemacht …

Auf jeden Fall schaffte es der Bekannte nicht, die von Fiber7 gelieferte Zyxel PM7300-Bridge an seiner ZyWall VPN100 zum Laufen zu bringen. Die Bridge zeigte zwar an, dass „Licht“ bei ihr ankommt, doch die sogenannte Splash Page wollte sich einfach nicht im Browser öffnen.

Als erstes suchte ich nach Installationsanleitungen für diese Gerätekombination, und wurde folgendermassen fündig:

Hier meine Erkenntnisse:

Keine VLAN-Konfiguration auf der Bridge nötig

Nach viel pröbeln am Vortag hatte sich der Bekannte auf die Bridge eingeloggt, und auch dort die VLAN-Konfiguration (VLAN10) vorgenommen.

Da in der Fiber7-Anleitung nichts davon stand, bat ich den Bekannten, die Bridge komplett zurückzusetzen, und es mit der Vanilla-Konfiguration zu probieren. Dies erwies sich im Grossen und Ganzen als guter Entscheid. Nach dem Zurücksetzen konnte sich die Bridge nicht mehr mit der Gegenstelle verbinden, doch nachdem wir einen einmaligen Kaltstart forcierten, klappte es dann wieder. Keine Ahnung was da los war.

Noch ein Hinweis zu den LEDs:

  • POWER: Muss konstant grün leuchten
  • Hexagon (PON): Muss grün leuchten (blinkend: Verbindungsaufbau)
  • Alarmglocke (LOS): Darf nicht leuchten/blinken (wenn sie rot leuchtet/blinkt, stimmt etwas nicht)
  • 10GE: Leuchtet grün wenn am anderen Ende des Ethernetkabels ein Netzwerkgerät dranhängt. Blinkt wenn Daten übertragen werden

Betriebssysteme und VLANs

Bevor wir die ZyWALL mit der Bridge verbanden, insistierte ich, einen Laptop an den Ethernet-Port der Bridge anzuschliessen um zu schauen was passiert.

Der HP-Laptop mit Windows konnten wir problemlos anschliessen, doch der Laptop erhielt keine IP zugewiesen. Ich wollte darauf hin VLAN10 konfigurieren, doch der Netzwerktreiber (Realtek irgendwas) scheint diese Option nicht anzubieten. Rasch gab ich auf, da ich mit Windows seit mehr als 10 Jahren nichts mehr am Hut habe.

Stattdessen schlossen wir nun ein MacBook Pro an die Bridge an. Hierzu verwendeten wir ein USB-C Dock mit Gigabit-Ethernet-Anschluss. Auch hier dasselbe Bild: macOS erhielt keine IP.

Nach einer kurzen Internet-Recherche fand ich einen offiziellen Apple Knowledgebase-Artikel, wie man unter macOS einen virtuellen VLAN-Adapter einrichtet: Set up a VLAN on Mac. Wie üblich deutlich einfacher als es unter dem Windows-Gefrickel je sein könnte.

Eingerichtet, und schwupp-di-wupp, der Mac erhielt via DHCP eine IP-Adresse und Netzwerkkonfiguration.

Swisscom DHCP-Infos

Der Mac erhielt folgende DHCP-Infos ausgehändigt:

IP address 100.95.137.141
Subnet mask 255.255.255.128
Router 100.95.137.129
DNS Server 1 195.186.1.162
DNS Server 2 195.186.4.162

IPv6 war Fehlanzeige, aber das störte uns ja nicht sonderlich.

Pingen, Surfen: Fehlanzeige

Auf dem MacBook versuchte ich dann, das Gateway (Router) zu pingen, Fehlanzeige. Auch die DNS-Server reagierten auf keine Pings. Ins Internet gelangte ich sowieso nicht. Auch das Ansurfen von Web-Sites wie bspw. www.spiegel.de oder www.admin.ch funktionierte nicht — elend lange Ladezeiten, um am Schluss mit einem Timeout zu enden. Egal mit welchem Browser ich es probierte — Safari, Firefox und Chrome.

Was aber funktionierte: Auf der Kommandozeile konnte ich mittels $ host www.spiegel.de tatsächlich DNS-Abfragen ausführen, und erhielt die korrekte aufgelösten IPs zurück.

Software-Firewall Gedöns ist des Teufels

Was das Debugging zu diesem Zeitpunkt verkomplizierte war die Little Snitch-Firewall, die der Bekannte auf seinem MacBook Pro installiert hatte. Obwohl wir sie deaktivierten, hatte ich das Gefühl, dass sie trotzdem weiterhin interferierte.

Zum Glück hatte ich mein MacBook Air ohne Firewall-Gedöns mit dabei, und wir wechselten kurzerhand auf dieses Gerät.

Swisscom Splash Page URL

Ich weiss nicht, was genau wir anstellten, aber auf meinem MacBook Air versuchte ich erneut www.spiegel.de aufzurufen. Ich setzte das Safari-Fenster in den Hintergrund, und als ich es wieder hervorholte erschien zwar nicht SPIEGEL Online, aber eine Safari Fehlermeldung „Safari Can’t Open the Page“. Und siehe da, als Adresse stand:

www.swisscom.ch/splashpage/guest/app/AccessId

Manueller Aufruf über Browser, und wget — Fehlanzeige!

Nun hatten wir also die URL der Splash Page, und natürlich versuchte ich sofort, diese direkt anzusurfen. Ewig lange Ladezeiten, und anfänglich ohne Erfolg. Schlussendlich aber lud etwas, aber nicht das, was ich erwartete:

Ich versuchte auch, die URL via wget herunterzuladen, aber das klappte im Gegensatz zum Browser überhaupt nicht — ich erhielt immer eine Timeout-Fehlermeldung.

Die IP des Swisscom Web-Servers lautet übrigens 195.186.210.170, aber nicht als wäre das irgendwie von Nutzen gewesen.

Zwischenfazit

Dank all diesen Erkentnissen war zumindest klar, dass der Glasfaser-Uplink funktionierte — Geräte erhielten via DHCP eine gültige IP und DNS-Informationen, und Swisscoms Server antworteten (wenn auch extrem langsam).

Wechsel auf ZyWALL und Windows

Jetzt fand ich den Zeitpunkt gekommen, um die Bridge an WAN2 der ZyWALL anzuschliessen. Allenfalls würde es ja damit besser klappen. WAN1 (an welchem derzeit noch ein Sunrise/upc Kabelmodem hängt) deaktivierten wir. Auch legte ich ein Augenmerk darauf, dass nur anfänglich die VLAN10 Konfiguration auf der ZyWALL aktiv war, und die VLAN11 Konfiguration (mit den PPPoE-Zugangsdaten) ebenfalls deaktiviert war.

VLAN10 erhielt wie zuvor die MacBooks im Keller eine IP-Adresse zugewiesen. Und siehe da: Noch bevor wir die Adresse des Splash Page manuell eingeben konnten, erschien auf Edge … wie von Geisterhand … die Splash Page!!! Heureka!

Ich glaube wir hatten zu dem Zeitpunkt bereits versucht, die Swisscom-Homepage anzusurfen, und ich weiss nicht, ob das die Anzeige der Splash Page ausgelöst, oder zumindest beschleunigt hat.

Registration über Splash Page

Ins Formular der Splash Page mussten nun drei Informationen eingetragen werden:

  • Die ID der OTO-Dose
  • Ein einmaliger Access Code, den der Bekannte von Fiber7 via Email erhalten hatte
  • (vergessen)

Obwohl in der Anleitung von Fiber7 stand, dass man nach dem Versand des Formulars ruhig einen Kaffee trinken gehen könnte, da die Registration bis zu 30 Minuten dauern würde, hatten wir gefühlt nach maximal 10 Minuten die Antwort: Anschluss aufgeschaltet!

Letzte Schritte

Als letzte Aktion deaktivierten wir nun VLAN10 auf der ZyWALL, und aktivierten VLAN11. Anschliessend löste der Bekannte über das ZyWALL Web-Interface die PPPoE-Einwahl aus, und tada, die Weltkugel leuchtete kurz darauf in Grün, und der Bekannte konnte im Internet surfen.

ifconfig.co

Um sicher zu gehen dass wir tatsächlich über Fiber7 ins Internet gelangten, rief ich ifconfig.co auf — und dort stand schwarz-auf-weiss: Init7. Heureka!

Obligatorisch: Speedtest

Schlussendlich lösten wir auch noch einen Speedtest aus:

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

Keine Kommentare | neuen Kommentar verfassen

Mittwoch, 4. September 2024

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

Link zu diesem Artikel

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

« Older Entries