Archiv ‘IT’

Sonntag, 8. September 2024

Hybrid7 mit Zyxel PM7300 und ZyWALL VPN100: Tips zum Debuggen

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)

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, 18. August 2024

Notifications von fremden, mit einem geteilten Wyze-Kameras deaktivieren

Ein Bekannter von mir hat eine Wyze-Kamera installiert und diese mit mir geteilt.

Ein grosses Problem ist, dass ich den lieben langen Tag hindurch gefühlt fünf bis zehn Mal eine Meldung kriege, wenn jemand das Mehrfamilienhaus verlässt, oder betritt. Das hat der Besitzer so eingerichtet.

Gemäss diesem riesigen Forum-Thread ist es einem Wyze-Gast nicht möglich, diese Notifications einfach zu deaktivieren.

Der Workaround ist im Forum beschrieben: Man erstelle eine sog. Automation, wähle die geteilte Wyze Cam aus, aktiviere „Turn off notifications“, und stelle die Start Time auf 12:01 AM (00:01), und die End Time (Optional) auf 11:59 PM (23:59):

Ich musste danach noch bis kurz nach Mitternacht warten — und seither ist die Kamera ruhig. Wunderbar.

Tags: , , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Donnerstag, 9. Mai 2024

Sony XAV-AX5550D Firmware Update

Gestern funktionierte Apple CarPlay mit dem Sony XAV-AX5550D (siehe Toyota Verso-S mit Apple CarPlay aufrüsten) meinem iPhone 13 mini aus irgendeinem Grund nicht mehr. Bei der Fahrt von Neuenegg nach Bern–Bethlehem funktionierte es reibungslos, doch bei der Rückfahrt ging nichts mehr: Auto neu starten — nix. iPhone neu starten — nix. Us Da das iPhone meiner Frau einige Stunden später am Autoradio mit CarPlay funktionierte, vermutete ich ein ein Problem mit meinem iPhone.

Nichtsdestotrotz entschied ich mich heute, ein Firmware-Update durchzuführen. Den Radio hatte ich 2020 gekauft und einbauen lassen, und die Firmware wies Version 1 auf: CPU 1.0.0, MCU: 1.0.0. Gemäss Treiber und Software-Updates für XAV-AX5550D ist nun Version 1.13 aktuell.

Ich lud das Firmware-Update herunter, kopierte es auf einen mit FAT32-formatierten USB-Stick, ging in die Tiefgarage, startete die Stromversorgung des Autos und folgte der exzellenten Anleitung Sonys. Nach fünft Minuten und dem einmaligen Wechsel des USB-Sticks vom USB 1-Anschluss auf den USB 2-Anschluss auf Anweisung hin war die Firmware auf dem neuesten Stand.

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

Keine Kommentare | neuen Kommentar verfassen

Mittwoch, 27. März 2024

Headless Chrome verrät sich über seinen User Agent

Headless Chrome eignet sich wunderbar, wenn man Web-Seiten mittels über Cron Jobs aufgerufenen bash-Scripts automatisiert abrufen möchte.

In meinem Anwendungsfall sende ich mir an Werktagen um 9:00 Uhr jeweils das Mittagsmenu des örtlichen Metzgers per Email zu.

Dies tat ich bis vor einigen Wochen mittels wget, doch serverseitig hat irgendwas geändert, und das CMS und/oder der Serverbetreiber haben nun eine Landeseite vorgeschaltet, die überprüft, ob ein „realer“ Benutzer oder ein Bot auf die Seite zugreift.

Anstelle des gewünschten Seiteninhalts bekam ich so seither nur noch eine HTML-Seite mit viel komprimiertem JavaScript-Code zu sehen, welcher höchstwahrscheinlich für die Erkennung und Weiterleitung verantwortlich ist.

Headless Chrome half hier:

chromium --proxy-auto-detect --temp-profile --disable-gpu --headless --virtual-time-budget=5000 --dump-dom "https://www.mittagsmenu.com/" > "/tmp/mittagsmenu.html"

Die Option --virtual-time-budget=5000 ist super, denn sie gaukelt vor, dass nach dem Laden 5 Sekunden vergangen sind. Genug, um die Landeseite aufzurufen, die Checks durchlaufen zu lassen, und dann den tatsächlichen gewünschten Inhalt anzuzeigen.

Das funktionierte wunderschön bis vor einigen Tagen, als kein Menu mehr via Email eintraf. Irgendwie kam auch Headless Chrome nicht mehr über die Landeseite hinaus. Doch wieso?

Bald einmal kam ich darauf: Wird Headless Chrome wie oben aufgerufen, identifiziert sich der Browser als Headless laufender Chrome (!):

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) HeadlessChrome/96.0.4664.110 Safari/537.36

Kein Wunder entdeckte und blockierte die Bot-Abwehr den Zugriff.

Zum Glück war die Lösung des Problems ganz einfach:

chromium --proxy-auto-detect --temp-profile --disable-gpu --headless --virtual-time-budget=5000 --dump-dom --user-agent="Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.110 Safari/537.36" "https://www.mittagsmenu.com/" > "/tmp/mittagsmenu.html"

… und seither funktioniert das Script wieder wie gewünscht. Das Argument --user-agent="" war alles, was es dazu brauchte.

Selenium headless: How to bypass Cloudflare detection using Selenium half mir dabei auf die Sprünge.

Tags: , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 17. März 2024

Wo ist der GRUB Bootloader alles installiert?

Vor einigen Wochen spukte eine SSD in einem meiner physischen Servern. Ich entschied mich, eine neue SSD zu kaufen, den kompletten Inhalt der alten SSD auf die neue SSD zu klonen, und dann die neue SSD als neue Festplatte in den Server einzubauen (die alte SSD wanderte ins Archiv).

Als ich gestern das Debian GNU/Linux auf diesem Server aktualisierte, bemerkte Debian, dass es auf einer neuen SSD lief, und fragte mich, wo ich den GRUB Bootloader überall installieren wollte (/dev/sda, das heisst auf der Festplatte selber, plus /dev/sda1, auf der ersten (Boot-)Partition).

GRUB war natürlich bereits installiert, sonst hätte der Server nach dem SSD-Wechsel nicht gebootet — aber vermutlich war in der GRUB-Konfiguration noch die Referenz auf die alte SSD enthalten und nicht auf die neue.

Überfordert entschied ich mich wie im Dialog angeregt, den Bootloader sowohl auf /dev/sda als auch /dev/sda1 zu installieren. Das sei die sicherste Methode.

Später dann fand ich nach einer mehrminütigen Internetsuche heraus, wie ich bei einem „baugleichen“ Server hätte nachschauen können, wo der Bootloader alles installiert ist:

# debconf-show grub-pc
  grub2/kfreebsd_cmdline:
  grub2/device_map_regenerated:
* grub2/linux_cmdline_default: quiet
  grub-pc/timeout: 5
* grub2/linux_cmdline:
  grub-pc/partition_description:
  grub2/kfreebsd_cmdline_default: quiet
* grub-pc/install_devices_disks_changed: /dev/disk/by-id/ata-SanDisk_SDSSDA120G_XXXXXXXXXXXX
  grub-pc/install_devices_failed_upgrade: true
  grub2/force_efi_extra_removable: false
  grub-pc/disk_description:
* grub-pc/install_devices: /dev/disk/by-id/ata-SanDisk_SDSSDA120G_XXXXXXXXXXXX
  grub-pc/kopt_extracted: false
  grub-pc/chainload_from_menu.lst: true
  grub-pc/postrm_purge_boot_grub: false
  grub2/update_nvram: true
  grub-pc/install_devices_failed: false
  grub-pc/install_devices_empty: false
  grub-pc/mixed_legacy_and_grub2: true
  grub-pc/hidden_timeout: false

Sprich: Nur auf /dev/sda.

Auf dem Server mit der ausgewechselten SSD schaut es nun halt leider so aus:

# debconf-show grub-pc
* grub-pc/install_devices: /dev/disk/by-id/ata-KINGSTON_SA400S37480G_XXXXXXXXXXXXXXXX, /dev/disk/by-id/ata-KINGSTON_SA400S37480G_XXXXXXXXXXXXXXXX-part1
  grub-pc/install_devices_empty: false
  grub2/force_efi_extra_removable: false
  grub-pc/install_devices_failed: false
  grub-pc/install_devices_failed_upgrade: true
* grub2/linux_cmdline:
  grub-pc/postrm_purge_boot_grub: false
  grub-pc/mixed_legacy_and_grub2: true
* grub-pc/install_devices_disks_changed: /dev/disk/by-id/ata-KINGSTON_SA400S37480G_XXXXXXXXXXXXXXXX, /dev/disk/by-id/ata-KINGSTON_SA400S37480G_XXXXXXXXXXXXXXXX-part1
  grub-pc/timeout: 5
  grub2/kfreebsd_cmdline:
  grub-pc/chainload_from_menu.lst: true
  grub2/update_nvram: true
  grub-pc/disk_description:
  grub-pc/hidden_timeout: false
  grub-pc/kopt_extracted: false
* grub2/linux_cmdline_default: consoleblank=60
  grub2/kfreebsd_cmdline_default: quiet
  grub-pc/partition_description:

Sprich: Man sieht, dass der Bootloader sowohl auf die Festplatte, als auch die erste Partition („part1“) installiert wird.

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

Keine Kommentare | neuen Kommentar verfassen

Mittwoch, 31. Januar 2024

Firefox nervt mit Übersetzungs-Pop-Up

Man öffne about.config und wechsle browser.translations.automaticallyPopup auf false, um dem Spuk ein Ende zu bereiten.

Tags: , ,
Labels: IT, Web

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 28. Januar 2024

Lustige Sicht auf Machine Learning

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

Keine Kommentare | neuen Kommentar verfassen

Dienstag, 16. Januar 2024

Ein für allemal: rsync, und die mühseligen Slashes

Ganz wichtig, und eigentlich ganz einfach, aber ich mache es immer falsch:

SOURCE Source is the directory that is backed up. At least one source is required. A trailing slash on a source path means „copy the contents of this directory“. Without a trailing slash it means „copy the directory“.

DESTINATION Destination is the directory that source is copied to. Trailing slash on the destination directory doesn’t matter.

Quelle: ‎rsync_tutorial‎.md

Tags: , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 10. Dezember 2023

Email-Adresse lässt sich in der Grab App nicht speichern

Über Weihnachten geht es nach Asien, mit einem ersten Stop in Singapur, gefolgt von Bangkok, bevor ich schlussendlich das eigentliche Ziel Taipei erreiche.

Bei Recherchen im Internet habe ich herausgefunden, dass die Grab App für Transport und Essenslieferungen empfohlen wird.

Ich habe die App gestern installiert, mich erfolgreich mit meiner Schweizer Mobilfunknummer registriert — doch beim Speichern der nachträglich erfassten E-Mail-Adresse meldet die App:

Sorry, our server reported an error. Please try again later.

Lösen konnte ich das Problem nicht. Egal ob über WiFi (ich habe hier ein PiHole-ähnliches Setup, das manchmal für solche Probleme sorgt), oder 5G, die Fehlermeldung erschien immer und immer wieder.

Nun habe ich die E-Mail-Adresse über einen Umweg doch noch erfassen können: Unter „Account“ > „Settings“ besteht die Möglichkeit, die App mit einem PIN zu schützen. Diesen habe ich eingerichtet. Um die App entsperren zu können, wenn man den PIN vergessen hat, kann man entweder seine E-Mail-Adresse hinterlegen, oder die App mit einem Facebook- oder Google-Konto verbinden. Ich habe mich für E-Mail entschieden. Das Onboarding funktioniert hier problemlos, und nach der erfolgreichen Registration erscheint die E-Mail-Adresse im Profil.

Somit ein weiterer Stolperstein aus dem Weg geräumt.

Tags: , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen