Archiv ‘IT’

Samstag, 14. Juni 2025

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

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

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

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!

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)

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

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