Sonntag, 10. August 2025

Wieso westliche Demokratien auf unbegrenzte Zuwanderung setzen

Offenbar scheint Kanada auch ungebremste Einwanderung zu erleben — doch wieso? Der YouTuber hinter Predictive History präsentiert seine Hypothese, und … um Herrn Drosten zu zitieren … es sieht nicht gut aus für den Westen:

Der Lehrer und YouTuber wurde mit der Prophezeiung des U.S.–Angriffs auf den Iran ein Jahr bevor Eintreten berühmt:

Tags:
Labels: Geschichte, Krieg, Politik, USA

Keine Kommentare | neuen Kommentar verfassen

Dienstag, 5. August 2025

Eine Stimme zum Gaza-Krieg

Die Lager sind zutiefst gespalten, aber eines kann man Many Patinkin nicht vorwerfen: Antisemitismus.

Tags: , ,
Labels: Krieg

Keine Kommentare | neuen Kommentar verfassen

Dienstag, 5. August 2025

Gelöst: Das Mysterium der nicht adoptierbaren UniFi Switches

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, 29. Juni 2025

Xiaomi Standventilatoren (Fans) in Homebridge einbinden

Es funktioniert, ist in meinem Fall aber komplizierter als ursprünglich gedacht. Aus zwei Gründen:

Xiaomi-„Heimatserver“ in China

Meine Xiaomi Mi Home App ist aus historischen Gründen seit Jahren auf Xiaomi-Servern in China eingerichtet.

Damit konnte ich aber einen kürzlich gekauften Xiaomi Mi Smart Standing Fan 2 Lite (interne Kennung: dmaker.fan.1c) für eine gerade zusätzlich erstellte Wohnung nicht registrieren — die Assoziierung über die iOS App auf dem iPhone schlug irgendwie immer bei etwa 50 Prozent fehl.

Ich habe deshalb für die zusätzliche Wohnung ein neues Konto eröffnet, und dieses auf Schweiz eingestellt.

Damit konnte ich den Lüfter mit der Xiaomi Mi Home App mit dem WiFi verbinden, er erscheint nun in der App unter macOS, welche mit meinem Zweitkonto registriert ist.

Token

Doch so ein Lüfter ist nur halb so lustig, wenn man ihn nicht auch in Apple HomeKit eingebunden hat, und ihn mittels der Siri-Spracherkennung eines Apple HomePods bedienen kann.

Hier kommt bei mir Homebridge zur Anwendung: Das Plugin homebridge-xiaomi-fan exponiert Xiaomi Lüfter gegenüber Apple HomeKit.

Randbemerkung: Dass die Fans dabei mit zig „Buttons“ exponiert werden, und sogar einer „Bulb“, finde ich nicht so schön. Item.

Das Problem: Ich musste den „Token“ des Fans irgendwie auslesen und in der Homebridge-Konfiguration hinterlegen. Neben der IP des Geräts, als nichts mit „auto discovery“.

Gar nicht so einfach, denn das Kommandozeilen-Tool eines anderen Entwicklers — Xiaomi-cloud-tokens-extractor funktioniert aktuell nicht mehr.

Doch verzweifelt nicht, die erste Option in Obtain Mi Home device token bringt die Lösung: Mi Home Toolkit.

Den deutschen Heimatserver ausgewählt (Schweiz existiert nicht im Drop Down), eingeloggt — und da steht er im Klartext, der Token. Einziges Problem: Das Element war mit Version 1.2.1 der App nicht selektierbar, weshalb Copy & Paste nicht funktionierte. Ungefähr eine Stunde, nachdem ich den Feature Request platziert hatte, war Version 1.2.2 live, welche das Problem behob.

WICHTIG: Ich vertraue diesen Wrapper-Applikationen nicht, auch wenn sie Open Source sind — zu einfach ist es, die Zugangsdaten mittels eines kleinen HTTP-Requests noch an einen Drittserver zu senden. Ich habe das Kennwort deshalb nach der erfolgreichen Einbindung vorsichtshalber noch einmal geändert.

Tags: , , , , , , , ,
Labels: Home Automation

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 15. Juni 2025

Israel gegen Iran: Wer gewinnt?

Israel und Iran decken sich seit zwei Tagen mit Bombardements ein. Wie das ausgehen wird, kann ich nicht sagen.

Einer der Podcasts, welchen ich konsumiere, vertritt die Meinung, dass Israel (respektive der um sein Amt bangende Premierminister) die USA mit dieser Eskalation zum Eintritt in einen grösseren Krieg in Nahost bewegen möchten. Der erste Schritt dazu wäre getan. Sind wir gespannt, wie Trump reagieren wird. Hört er auf die Neocons und War Hawks des Deep States, oder geht er seinen eigenen Weg?

Doch in diesem kleinen Beitrag eines Laien geht es nicht um die Analyse der Motive beider Seiten, sondern um die ökonomischen Realitäten der Kriegsführung.

Mich erinnert das Ganze an die Anfänge des Ukraine-Kriegs. Eindrücklich war für mich damals, wie Raytheons Javelin (Kostenpunkt: $250,000 $500,000 bestehend aus der „Command Launch Unit (CLU)“ und der „Missile“) Panzer (Kostenpunkt: $500,000–$2m) zerstören (mein Post von damals). Eine Javelin herzustellen ist viel einfacher, und das Ding kann wiederverwendet werden (eine Ersatzrakete kostet $100,000). Ausserdem ist die Waffe extrem einfach zu bedienen. Somit ein klarer Vorteil für die Besitzer der Javelin.

Eine wichtige Frage bei den aktuellen Bombardements muss deshalb sein: Wie viel kostet den Angreifer eine Rakete, und wie viel kostet es dem Verteidiger, eine solche Rakete in der Luft abzufangen und zu detonieren, bevor sie ihr Ziel erreichen kann?

Die Jerusalem Post hat sich dem Thema bereits im Oktober 2024 angenommen: Eine iranische Rakete kostet mindestens $1,000,000. Eine israelische Abwehrrakete (Arrow-2 oder Arrow-3) kosten $3,000,000 respektive $2,000,000. Unklar ist, wie viele Arrows auf ein Ziel abgefeuert werden: Eine, oder mehrere? Gemäss dem Artikel wird eine iranische Rakete von Iron Dome nicht abgefangen, wenn der Computer berechnet, dass sie unbewohntes Gebiet ansteuert.

Was ich auf Grund von auf Twitter kursierender Videos erkennen kann: Iron Dome scheint nicht so gut zu funktionieren wie gewünscht. Einige Raketen kommen durch, und für mich als kompletten Waffensystem-Laien sieht es aus, dass es sich dabei um Überschallraketen handelt.

Und hier schliesst sich der Kreis vermutlich wieder: Anstelle mit enormen Kosten und einer nicht hundertprozentigen Erfolgschance angreifende Raketen abzufangen, macht es für Israel vermutlich mehr Sinn, den Gegner daran zu hindern, überhaupt solche Raketen zu produzieren.

Tags: , , , , , , ,
Labels: Krieg

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 15. Juni 2025

Festplatten von einer defekten Synology DS416j wegmigrieren

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

Sonntag, 15. Juni 2025

Apple veröffentlicht haptischen Trailer zu F1

Auf dem iPhone schauen in Landscape schauen, und das Telefon mit beiden Händen halten:

apple.co/_Haptic

Tags: , , , ,
Labels: Apple

Keine Kommentare | neuen Kommentar verfassen

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

Montag, 9. Juni 2025

Sold: Dyson PencilVac Fluffycones

Via: JAMES DYSON PROVES THAT LIVE ON-STAGE DEMOS ARE STILL THE BEST

Einziges Problem:

Der Verkauf startet zwar dieses Jahr in Japan, in Europa kommt der schlanke Sauger erst 2026 auf den Markt. Zum Preis ist noch nichts bekannt.

Quelle: PencilVac: der dünnste und leichteste Dyson-Staubsauger aller Zeiten

Tags: , , ,
Labels: Shopping

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 8. Juni 2025

DER SPIEGEL: Warum die Deutschen sich immer weniger leisten können

Gestern entdeckt:

Warum die Deutschen sich immer weniger leisten können

Ich habe den Artikel — primär wegen der Bezahlschranke, aber auch, weil mich der SPIEGEL längst verloren hat — nicht gelesen. Meine Vermutung ist aber, dass hier in 2000+ Worten sehr viel geschrieben, aber kaum etwas gesagt wird. Und die Elefanten im Raum ganz sicher nicht benannt werden. Spontan, ohne lange zu überlegen:

  • Unkontrollierte Einwanderung („es kommen zu viele, und es kommen die Falschen“) und der Verzicht der Institutionen, geltende Gesetze anzuwenden
  • Exorbitante Sozialleistungen, die weiter rasant wachsen, trotzdem kontinuierlicher Ausbau des Sozialstaates
  • Verteufelung des Unternehmertums, Neid und Gleichmacherei
  • Viel zu teure fossile Energie, weil Russland der neue „Antichrist“ sei
  • Gescheiterte Energiewende
  • Kriegstreiberei
  • Moralismus, Weltverbesserertum, internationaler Oberlehrer
  • Überbordende, völlig ineffiziente Bürokratie, inklusive Vetternwirtschaft (Nepotismus)
  • De facto gleichgeschaltete öffentlich-rechtliche Medien
  • Das unfähigste Politpersonal der Nachkriegszeit, Schulabbrecher, Parvenüs, die selten bis nie in der Privatwirtschaft gearbeitet haben; plus ein riesiges Parlament (630 Abgeordnete, irr)
  • Dysfunktionale Demokratie mit eklatanter Ignorierung des Wählerwillens
  • Mehr und mehr zerbröckelnde Infrastruktur

Tags: , ,
Labels: Geschichte, Politik

1 Kommentar | neuen Kommentar verfassen