Seit kurzer Zeit habe ich mein erstes Xiaomi device. Ein air-purifier 3H. Design u. Funktion sind prima. Als seeeeehhhhr vorsichtiger u. skeptischer Mensch habe ich vorerst nicht den üblichen Weg einer Erstinstallation über eine App-Blackbox gewählt.
Meinen außergewöhnlichen Beginn einer FHEM-Anbindung hab ich hier (https://forum.fhem.de/index.php/topic,73052.msg1113100.html#msg1113100)bereits beschrieben.
Problem ist also der token. Nun gibt es zahlreiche Infos im Net, wie man denn an ihn kommt. Leider ist immer nur der Weg beschrieben. Nie die Zusammenhänge.
Nach meinem Kenntnisstand MUSS einmal mit der App "initialisiert" werden. Danach findet sich der token in der Cloud, von wo er ausgelesen werden kann. Klingt eigentlich nicht dramatisch.
Aber was passiert bei der "Initialisierung" ? Man teilt dem device seinen WLAN-Zugang(SSID,key) mit. Logisch, wie soll es auch sonst lokal kommunizieren. Dass diese Daten auch nach China wandern, äußerst unschön. Aber hey, einmal mit fakeSSID u. onetime-key initialisieren müsste ja gehen. DENKSTE. Jede Änderung des lokalen Netzwerks erfordert auch die erneute "Initialisierung" des devices.
Zwischenfazit: Netzwerkanbindung eines devices ist gleichbedeutend mit der Offenlegung des WLAN-Zugangs an die Chinesen.
Erst einmal nur unschön. Hätte man nicht die Info, dass auch noch die Lokation übertragen wird(slide 22.) (https://dgiese.scripts.mit.edu/talks/BeVX-2018/BeVX_prepublic.pdf)Und spätestens jetzt hört der Spaß auf.
Fazit: Netzwerkanbindung eines devices ist gleichbedeutend mit der Offenlegung des WLAN-Zugangs an die Chinesen. Und dem Ort des WLANs
Hinzu kommt die permanente Datenübermittlung des devices. Der Grundriss der Wohnung(vacuum cleaner), womöglich Streams/Bilder der Cam....Dagegen kann man sich wenigstens noch wehren, indem man dem device den Internetzugriff "verbietet".
Was soll nun dieser Thread ? Aufklären u. vielleicht eine Lösung finden, die eine FHEM-Anbindung möglich macht, ohne dass der Chinese morgen vor der Tür steht, sich im WLAN anmeldet u. dann Gott-weiß-was anrichtet.
Wer also irgendwelche Infos hat, wie man dem Hersteller seine Spionage abgewöhnen, man seinen WLAN-Zugang verschleiern kann, bitte hier posten.
Wenn ich etwas falsch oder unzureichend dargestellt haben sollte: Kritik willkommen.
Und noch eins: aufgrund der Vielzahl der device typen, unterschiedlichen Generationen und firmwares ist das WWW mit Vorsicht zu genießen. Selten sind die Infos allgemeingültig. So lassen sich manche devices mit alternativer firmware flashen(z.B. Valetudo bei vacuum cleanern :-\). Aber eben nur manche.
Ich recherchier mal weiter u. versuche mal die dustcloud zu verstehen.....
Grüße Markus
Edit: Kaspersky Hintergrundinfo (https://www.kaspersky.com/blog/xiaomi-mi-robot-hacked/20632/)
dustcloud: Do Xiaomi know the exact position of the vacuum or my smart device(e.g. address)? (https://github.com/dgiese/dustcloud/wiki)
.
Hi,
was mir dazu einfällt (leider gehen die WLAN Daten trotzdem einmalig nach China):
- Saugroboter: Valetudo und somit keine Wohnungsdaten mehr
- Xiaomi Mijia Gateway3: https://github.com/AlexxIT/XiaomiGateway3#zigbee-home-automation-mode damit wird das Ding auch von der Cloud getrennt
- Zigbee2MQTT oder ähnliches: Als Ersatz für Gateways und damit komplett cloudfrei für die Sensoren
Ich glaube man wird je Device eine Möglichkeit zum Rooten finden müssen. Eventuell mal Aufschrauben und nach entsprechenden PINs suchen die man dann seriell nutzen kann um die Firmware zu bearbeiten.
Zitat(leider gehen die WLAN Daten trotzdem einmalig nach China)
Einmalig wäre ja nicht schlimm. Dann könnte man ja
Zitateinmal mit fakeSSID u. onetime-key
Oder etwa jedesmal, wenn die WLAN-Zugangsdaten lokal geändert werden ? :o
Wenn Letzteres, auch bei z.B. Valetudo(hab ja keinen cleaner), also gerooteten devices ?
Gute Frage, da bin ich mir jetzt nicht sicher. Eigentlich sollte mit root am Saugroboter problemlos ein WLAN Wechsel möglich sein.
Ja, mit root-Zugang bei den Xiaomi/rockrobo vacuum kann das WLAN lokal umgestellt werden...
Und wie im anderen Thread geschrieben hab ich mir für meine Sauger mal eine FW-Brutzel-VM" gebastelt"...
Hier mal noch mal meine Links aus dem anderen Post:
https://python-miio.readthedocs.io/en/latest/vacuum.html
https://github.com/Hypfer/Valetudo
https://valetudo.cloud/pages/installation/roborock.html
https://heinz-otto.blogspot.com/2019/06/root-und-gut.html
Einen Xiaomi-Gateway hatte (also hab ich noch, nutze EDIT: jaja ;) ihn es aber nicht mehr) ich auch mal.
Ging auch ohne Cloud aber nat. 1x anmelden WLAN (denke ich)...
Beim Anlernen neuer Geräte weiß ich nicht mehr, denke aber ging (bei mir) auch nur mit App (also wieder kurz Zugang)...
War noch V1 und die zugehörigen Sensoren haben mich (trotz des niedrigen Preises) nicht überzeugt...
-> Grabbelkiste... ;)
EDIT: bei Kameras hab ich auch kurz überlegt mir so ein China-Ding zu kaufen und zu flashen/rooten/hacken... Aber dazu fehlte dann doch die Zeit...
Ich "hör" hier mal mit... :)
Gruß, Joachim
Und hier noch der Hack für die Xiaomi 1080p 360 Kamera
https://github.com/telmomarques/xiaomi-360-1080p-hacks
Gibt es auch für dafang Modelle.
Das klingt ja wenigstens danach, dass man bei gerooteten devices Abhilfe schaffen kann.
Ich wette aber, dass die meisten folgende Vorgehensweise wählen:
- Erstinstallation mit App/Cloud.... --> WLAN-Zugangsdaten landen in China
- rooting und man ist glücklich dem Chinesen ein Schnippchen geschlagen zu haben
- wer ändert jetzt noch seine Zugangsdaten. ::)
==> nur die Vorgehensweise Ersteinrichtung mit "fakeSSID u. onetime-key "(also kurzzeitig veränderte Zugangsdaten) hält die Cloud dumm
Ich kenne da einen, der mich vermutlich bestätigen/berichten kann. ;) ;D Er hat sich auch mit dustcloud hier im Forum (https://forum.fhem.de/index.php/topic,86535.0.html) auseinandergesetzt. Vermutlich aber nie ausprobiert, da der Thread dann abrupt abbricht. :'(
Ich denke, dass dustcloud der Ansatz ist. Entweder nur zum rooten von bereits gehackten device typen(Liste hier (https://github.com/dgiese/dustcloud/wiki/Supported-Devices) u. hier (https://github.com/dgiese/dustcloud-documentation)) oder um evtl. aus dem Programm code etwas abzuleiten(für mich kaum lösbar; für dominik u. Markus.M sicherlich einfacher nachzuvollziehen).
Grüße Markus
Beim Sauger geht es auch anders, sofern man ihn nicht in der Cloud bruacht...
Zurückgesetztes Gerät mit "Root-FW" versorgen und dann per ssh-Zugang WLAN setzen...
(Ansonsten braucht man für das Rooten ja schon den Token ;) )
Gruß, Joachim
[OT: Frage an die Deutschen]
ZitatEinen Xiaomi-Gateway hatte (also hab ich noch, nutze ihn aber nicht mehr) ich auch mal.
Der, die oder das Gateway?
:D
[/OT]
[OT] das Gateway (https://www.duden.de/rechtschreibung/Gateway) ;)[/OT]
[OT]
ZitatDer, die oder das Gateway?
Das ist doch noch einfach. Aber der oder das token ? ;D[OT]
Zurück zum Thema. Dummycloud (https://github.com/dgiese/dustcloud/tree/master/dummycloud)(Bestandteil von dustcloud ? :-\) scheint mir ganz interessant. Nur welchen "key" zur Hölle muss man angeben ?(Ich hab ja zwischenzeitlich gelernt: es gibt den "device-key"[gerätespezifisch,fix] zur Kommunikation mit der Cloud u. das "token"[generiert bei der "Initialisierung"] zur Kommunikation mit der App(oder alternativ halt FHEM....) Jemand ne Idee ?
Und noch eine Anmerkung am Rande: mein 3h befand sich ja im lokalen Netz ohne Zugang zum Inet(1. Stufe pi-hole, 2.Stufe Fritte). Nun las ich, dass angeblich auch IP-Adressen fest in der firmware verdrahtet sind. Da die Fritte auch deren Zugriff nicht zulässt, wollte ich mir mal im Ereignisprotokoll ansehen, ob ich IP's finde. Keine vorhanden. Allerdings stellte ich fest, dass der 3h sich permanent an- u. abmeldet. Seit ein paar Tagen hab ich auch permanent Probleme im WLAN. Also hab ich den 3h mal wieder resettet und seitdem scheinen meine WLAN-Probleme weg zu sein.
Was ich auch nirgends finden konnte: Lässt sich der Schlüssel des WLAN-Zugangs ändern, ohne dass ein neues token generiert wird ?
Du kannst es Mal mit miio probieren
https://github.com/aholstenson/miio/blob/master/docs/management.md#changing-the-wifi-settings-of-a-device
Ich weiß nicht ob sich dann der Token ändert, wenn nicht, hätten wir schon eine Lösung für alle Geräte.
ZitatIch weiß nicht ob sich dann der Token ändert, wenn nicht, hätten wir schon eine Lösung für alle Geräte.
Das war mein Gedanke bei meiner Frage. ;)
ZitatDu kannst es Mal mit miio probieren
Ich ja leider nicht. Ich komm doch gar nicht so weit mangels token. Deshalb hoffte ich, dass das von Euch mal jemand probiert.
ZitatNur welchen "key" zur Hölle muss man angeben ?(Ich hab ja zwischenzeitlich gelernt: es gibt den "device-key"[gerätespezifisch,fix] zur Kommunikation mit der Cloud u. das "token"[generiert bei der "Initialisierung"] zur Kommunikation mit der App(oder alternativ halt FHEM....) Jemand ne Idee ?
Ich denke, ich habs selber herausgefunden. Valetudo gibt die Antwort
ZitatdeviceId and cloudSecret can be found in the /mnt/default/device.conf as did and key on the robot. Since both values are static, you'll only need to do that once.
The localSecret can be found in the robots FS as well: /mnt/data/miio/device.token. Note that this one might change when you're switching wireless networks etc.
Mist. Alles was ich finde ist immer auf die vacuum cleaner zugeschnitten. :'(
wieder etwas weiter im Verständnis. Ich befürchte, dass das device nach der Übertragung der WLAN-Zugangsdaten den neuen token verschlüsselt mit dem device-key in die Cloud schickt. Die Cloud kennt den device-key und bestätigt dann das neue token. Mit gesperrtem Inet empfing ich per wireshark
magic bytes
I length bytes
I I counter(id)
I I I 32-character token ???? encrypted ???
I I I I
21310020ffffffffffffffff00000075 0da9a61ffd3b38c0713854b5c4cde5af
21310020ffffffffffffffff00000077 05d8c015a71b5b12513d6ce3dada22f6
21310020ffffffffffffffff00000079 bca5fca713105bd177d58d02fbaa57e6
21310020ffffffffffffffff00000084 9c4047bca36cc5d8524cdb475203359c
21310020ffffffffffffffff00000086 bb4a594451b1e7875ed8963e3272adb4
21310020ffffffffffffffff00000088 8b8d09b31ab51cae380f8acac426dd50
21310020ffffffffffffffff00000093 0f0f27c99adce2c765b4cd084fa01e20
21310020ffffffffffffffff00000095 c0bca63141bbe8587fa44d55a3c866b3
21310020ffffffffffffffff00000097 87f6d32906e2578cc87316606ac0cfd5
21310020ffffffffffffffff00000ba2 8c99385bae7438d9ac8c96be566f7435
21310020ffffffffffffffff00000ba5 ba192a633a033f3089f05793762c322c
21310020ffffffffffffffff00000baf 5893466b3364db5ac5868848cee63929
21310020ffffffffffffffff00000bb2 2e5b84cf27bf194e986d86fe08d9daf3
21310020ffffffffffffffff00000bb4 c1aa242d495b1d3d5397fc0c019b16e8
21310020ffffffffffffffff00000bbe ffe4dd206e45f768cec731e37bc7e7b3
21310020ffffffffffffffff00000bc1 198fac288e8b538b15cf41b74f14bcf6
21310020ffffffffffffffff00000bc3 fd3db4369adde79754595ffcc34fb97c
21310020ffffffffffffffff00000bcd b6afd9b3e7192f32e8824e90fd4f7699
21310020ffffffffffffffff00000bd0 50f38124b180f1fc28485104bec6c2c3
21310020ffffffffffffffff00000bd2 e926f4871da2448893e8f20dc24e50d5
21310020ffffffffffffffff00000bdd 59e876a4351c8d356227448a42c9c347
21310020ffffffffffffffff00000bdf 5d81be7aff9aafcc25c958d26c64437a
21310020ffffffffffffffff00000be1 d9e8a8411ba7e1851414a330483a73a4
21310020ffffffffffffffff00000bec 0c69563a84352c4475322518434cddac
21310020ffffffffffffffff00000bee bfd3092f445be1090d527c9ce85f0473
21310020ffffffffffffffff00000da6 995d3da1dd6a859b9f7e3952ca5e9abbNach einigen Versuchen probiert das device eine TLS-Verbindung aufzubauen.
Domains u. IPs
udp 161.117.49.2, 161.117.52.228 ot.io.mi.com
https 161.117.93.220 ots.io.mi.com
dns ohne traffic: dlg.io.mi.com 124.251.58.88, 124.251.58.124, 183.84.6.98
Und dann wurde noch dieser unverschlüsselte request an dns.io.mi.com[110.43.0.83] übertragen GET /gslb?tver=2&id=317353509&dm=ots.io.mi.com×tamp=21&sign=Oiv14ZbzR46frBEmyxt%2BQgR8udGtCyho6DW3hGVlLaQ%3D HTTP/1.1\r\n
Antwort: <html><head><title>302 Document moved</title></head><body><h1>302 Document moved</h1>This document has moved <a href="http://fritz.box/tools/kids_not_allowed.lua?account=IPdesDevice">here</a>.<p></body></html>
Keine Ahnung wie das überhaupt durchgehen konnte. :o :-\
Und die App erhält wohl nach Authorisierung einen temporären service-key aus der Cloud und überträgt dann die device-id. Der Kreis(Dreieck) ist geschlossen.
Wie gesagt, Spekulation....
Zitat von: KölnSolar am 24 Dezember 2020, 14:05:23
[OT]Aber der oder das token ? ;D[OT]
beides richtig -> Substantiv, Neutrum, oder Substantiv, maskulin , Quelle : https://www.duden.de/rechtschreibung/Token
Hallo,
Vorbemerkung:
nun bin ich doch noch mal bei diesem Thread gelandet, bei der Recherche, ob sich zwischenzeitlich bei der Integration der Xiaomi Luftreiniger in Fhem etwas grundlegendes geändert hat; dem scheint leider nicht so zu sein, es besteht vom Hersteller so vorgesehen immer noch "Cloud-Zwang."
Da die Geräte meiner MEinung nach technisch gesehen aber sonst ihre Aufgabe gut erledigen, habe ich mehrer davon im Einsatz. Alllerings erst, als ich für mich eine Lösung gefundet hatte, die den Betrieb in Fhem mit WLAN-Integration ermöglicht, OHNE jegliche Verbindung zur Hersteller Cloud. Keine Frage, die u.g. Lösung stellt eine Hilfskonstruktion dar, aber es funktioniert bei mir .
Kurzbeschreibung:
- die Xiomi-Luftreiniger arbeiten nach Einschalten/Inbetriebnahme als individueller WLAN-AP auch in der weiteren Nutzungsphase durch Fhem im Auslieferungszustand (wie auch nach WLAN-Factory-Rset.
- um mit einem Xiomi-Luftreiniger von Seiten Fhem aus Kontakt aufzunehmen, konfiguriert man von Fhem aus einzusätzliches separates "Xiaomi"-WLAN (z.B. AVM-WLAN-Stick ... akzeptable Reichweite) mit den WLAN-Accessdaten des jeweiligen Luftreinigers (Dieses WLAN-Interface hat Server-seitig gar keine Möglichkeit "nach draußen" eigene Nachrichten abzuschicken)
- Ergebnis: alle wichtigen Readings der einzelnen Geräte können Fhem-üblich bearbeitet werden, z.B. Betriebszeiten ... notify auf notwendigen Filterwechsel, ... power on/off zwecks Ruhezeiten und ähnliches.
- Randbedingungen dieser Lösung: da die Abarbeitung von Anfragen und Settungs pro Gerät bei dieser Notlösung nur sequential über eine Queue erfolgt, kann es auch mal länger dauern, bis Aktionen zum betreffenden Gerät drankommen und umgesetzt werden. Das hat sich aber bisher in keiner Weise als nachteilig erwiesen. Im Gegenteil, der Vorteil, die Geräte auch ohne Cloud-Zwang unter Fhem nutzen zu können, überwiegt aus meiner Sicht bei weitem. Daher ist für mich auch die App zur Steuerung der Geräte absolut nicht notwendig, das alles erledigt Fhem viel besser ;-)
Gruß
JHS
Morjen,
meine vollste Zustimmung
ZitatIm Gegenteil, der Vorteil, die Geräte auch ohne Cloud-Zwang unter Fhem nutzen zu können, überwiegt aus meiner Sicht bei weitem. Daher ist für mich auch die App zur Steuerung der Geräte absolut nicht notwendig, das alles erledigt Fhem viel besser ;-)
Weg mit dem Cloud-Spion.
so ganz hab ich
Zitatkonfiguriert man von Fhem aus einzusätzliches separates "Xiaomi"-WLAN
nicht verstanden. Zumal Du den airpurifiern doch dieses WLAN mitteilen musst(per App) und das dann neue token zu dessen Generierung doch die Kommunikation mit der Cloud erfordert. :-\
Oder Du hast etwas ganz Neues "entdeckt", dann bitte her damit. :D
Grüße Markus
Hallo,
vorweg, ich habe nichts neues entdeckt, sondern einfach nur versucht, aus dem etwas zu machen, was mir "trotz" Xiaomi per WLAN für Fhem zur Verfügung steht.
Das Ergebnis dieser Steuerung wirkt zwangsweise ziemlich "ge-hacked" und gefrickelt, weil - diese Lösung war überhaupt und so wohl nicht so vom Hersteller vorgesehen, wie man vermuten könnte.
Aus Fhem Anwendersicht stellt sich das Ergebnis meiner Einbindung der Xiaomi airpurify devices wie folgt dar, z.B.:
# Fhem für airpurifyX mit X=[1-N]
I. requirements
- Wichtig: von Fhem steuerbare 230V Schaltsteckdose(n) , jeweils 1x pro Xiaomi device zum Schalten des airpurify device, um dieses in den "Anlern-Mode" der Inbetriebnahme zu versetzen. Diese Power-Schalter wird sinnvollerweise auch verwendet, um aus Energiespargründen die airpurify devices vom 230V-Netz zu nehmen, wenn sie nicht benötigt werden.
- die dynamische Veränderung der dedizierten Server-WLAN-Schnittstelle, die ausschliesslich für die Kommunikation mit den airpurify devices reserviert ist (z.B. per WLAN Stick mit genügend Reichweite)
- die Steuerung der Queue, die dafür sorgt, dass die airpurify devices der Reihe nach abgearbeitet werden, da die Kommunikation zwischen Fhem und den N airpurify devices immer nur mit _einem_ device abgearbeitet werden kann, erst danach ist ggf. das nächste airpurify device dran. Grund: das WLAN muss für jeden Auftrag mit einem anderen airpurify device umprogrammiert werden.
Ein Teil der Steuerung der airpurify devices ist in Fhem Macros verborgen, ein Teil in FHEM/99_myUtils.pm und ein Teil in Mini C-Programm Schnipsel, um mit den notwendigen Systemprivilegien das o.g. WLAN-Interface dynamisch gem. Aufrufparameteren von Fhem zu konfigurieren.
Eine wichtige hilfreiche Steuergröße ist das user reading
setreading airpurifyX xpower [on|off]
das Aufschluss über den Zustand von airpurifX gibt, auch wenn dieses Gerät gerade mal nicht erreichbar ist. Die Aktualisierung dieses Readings erfolgt in den Faellen, wenn airpurifyX erreichbar ist, bzw. der programmierbare Netzschalter das Gerät das airpurify definitiv AUS-schaltet.
II Anwendungsbeispiele
- # Queue gesteuertes Ein-/Ausschalten der airpurify devices:
trigger power_on_airpurifyX ... trigger power_off_airpurifyX - # Maintenance, wenn Filter länger als MAX Stunden in Betrieb:
define airpurifyX_ck_stat_filter_used notify airpurifyX:filter_used:.* { airpurify1_ck_stat_filter_used_msg ("airpurifyX") } - # set defaults je airpurify device X
define set_on_airpurifyX_defaults notify set_on_airpurifyX_defaults
...
set airpurifyX reconnect
set airpurifyX buzzer off
set airpurifyX on
set airpurifyX mode auto
set airpurifyX led dim
setreading airpurifyX xpower on...
Der grundlegende "Trick", um mit den Xiaomi airpurify devices "out-of-the-box" zu kommunizieren, ohne auch nur an die Xiaomi App zu denken ;-) besteht darin, das Server-WLAN mit dem factory-|reset-WLAN ESSID (Accesspoint-Mode "AP" !) des airpurify devices kommunizieren zu lassen. und daran danach nichts mehr zu ändern.
Um in diesen Modus des Airpurify zu gelangen, muss das Gerät im Zustand
factory-|reset jeweils eingeschaltet werden, mittels des o.g. 230V~ von Fhem steuerbaren Power-Schalters.
Der WLAN-AP-Mode wird dann nach Einschalten für eine begrenzte Zeit von den Xiaomi airpurify devices aktiviert (Vorausetzung: das Gerät wurde nicht mit Xiaomi-APP "verbogen" und solange das Gerät nicht für die Cloud konfiguriert wurde; aber DAS wollen wir ja gerade vermeiden ;-)
Dass dieses WLAN in dieser Form - offen, unverschlüsselt - genutzt wird, stört in diesem Anwendungsfall nicht.
Diese factory-|reset-WLAN ESSID unterscheidet sich von Geraet zu Geraet und beinhaltet Teile der MAC-Adresse "aa:bb:cc:dd:ee:ff" (last 4 char. ) wie folgt
zhimi-airpurifier-mc2_miapeeff
Die IP-Adresse der airpurify devices in diesem Inbetriebnahme Mode als WLAN-AP ist konstant 192.168.13.1.
Damit steht fest, wie die SSID des dedizierten Server-WLANs (als WLAN client) zu konfigurieren ist. Als IP-Adresse des Server-WLAN kann man dann z.B. fest 192.168.13.11 verwenden.
# 192.168.13.1 # als statische default IP-Adresse
# ESSID:"zhimi-airpurifier-mc2_miapeeff"
# Encryption key:off
# MAC-Adress :aa:bb:cc:dd:ee:ff
# Frequency:2.437 GHz
# Mode:MasterUm mit den bzw. dem aktuellen airpurify device kommunizieren zu können, ist nun der "berüchtigte" Token des airpurify devices erforderlich.
Im Auslieferungszustand bzw. nach factory reset ist ein jeweils individueller token auslesbar. Da wir den Auslieferungs-/Reset-Mode
Zitat> Nur zur erstmaligen Inbetriebnahme nach UnBoxing oder WLAN-Reset
> (by pressing both button Mode+LED for >5 sec )
in unserem airpurify-Steuersystem nicht ändern (!) können wir diesen Token verwenden.
1. das dedizierten Server-WLAN entsprechend aufsetzen
Zitat- auf die ESSID des neuen airpurify (im AP-Mode nach uslieferungszustand bzw. nach factory reset )
- Encryption key:off
- inet 192.168.13.11 netmask 255.255.255.0 broadcast 192.168.13.255
2. per 'ping' muss nun der airpurify erreicht werden können
Zitatund im arp-Cache die MAC-Adresse des airpurify
sudo arp -a | grep 192.168.13.1
3. Inbetriebnahme Code in Fhem
Zitat# define airpurify1 XiaomiDevice 192.168.13.1
# attr airpurify1 subType AirPurifier
# attr airpurify1 room TEST_xiaomi
4. Wenn nun bis hier die WLAN-Verbindung "steht", dann sollte der aktuelle token in den device internals unter Fhem bei Anklicken des "airpurify1" im room "TEST_xiaomi" sichtbar sein.
5. Zur Übernahme von airpurify1 in die Fhem Produktivumgebung
aendert sich dann die define Zeile:
#
define airpurify1 XiaomiDevice 192.168.13.1 fd98e26c0e7e1875a33fa1258f330cd5
attr airpurify1 alias airpurify1_EG_Wohnimmer
attr airpurify1 event-on-change-reading device_uptime,error,favorite,filter,filter_life,filter_used,filter_volume,humidity,led,mode,pm25,pm25_average,power,sleep_auto,speed,state,temperature,turbo,usage
attr airpurify1 stateFormat pm25 µg/m³ / speed rpm / mode
attr airpurify1 subType AirPurifierdefine airpurify1 XiaomiDevice 192.168.13.1 fd98e26c0e7e1875a33fa1258f330cd5
attr airpurify2 alias airpurify2_EG_Schlafzimmer
attr airpurify2 event-on-change-reading device_uptime,error,favorite,filter,filter_life,filter_used,filter_volume,humidity,led,mode,pm25,pm25_average,power,sleep_auto,speed,state,temperature,turbo,usage
attr airpurify2 stateFormat pm25 µg/m³ / speed rpm / mode
attr airpurify2 subType AirPurifier... usw
Ich hoffe, ich habe zumindest prinzipiell darstellen können, dass man damit diese widerborstige Ansteuerung der Xiaomi airpurify in den Griff bekommen kann. So würde es auch keinen großen Aufwand darstellen, jetzt noch etliche weitere Geräte dieser Art in Fhem zu integrieren. Der Rahmen steht und lässt sich leicht erweitern.
Wenn weitere Fragen bestehen, will ich die gerne mit meinen Möglichkeiten beantworten. Kann ggf. etwas dauern, da ich nicht so häufig im Forum unetrwegs bin.
Gruß
JHS
Danke für Deine Beschreibung.
Nun ist mir klar, was Du treibst. So hatte ich ja auch schon die Anbindung an FHEM erreicht. Vielleicht noch einmal etwas anders beschrieben(mir fehlt in Deiner Beschreibung die eigentliche Grundlage).
Grundlage: ein noch nicht per App "gepairter" airpurifier schaltet sich nach jedem "Stromspannung ein" für ca. 15 min. in den Pairingmodus. Dafür öffnet er einen eigenen WLAN-AP(je nach Modell mit unterschiedlicher SSID und IP[bei mir 192.168.4.1])
Um eine Netzwerk-Verbindung bzw. eine Verbindung zu FHEM zu erreichen, muss der FHEM-Server eine WLAN-Verbindung zum AP aufbauen. Das erreicht man durch einen WLAN-Client, dem man eine feste IP aus dem Subsegment der Airpurifier-IP[192.168.4.x] vergibt(ich nutze dafür die WLAN-Funktion meines RPi3).
Mit dem XiaomiDevice-Modul lässt sich der airpurifier in FHEM mit der IP des airpurifier-WLAN-AP definieren
define airpurifier XiaomiDevice 192.168.4.1
Nun ist der airpurifier von FHEM aus bedien- und abfragbar. Aber nur für jeweils die vorgenannte Viertelstunde. Denn dann schließt der airpurifier wieder seinen AP.
Um nun trotzdem regelmäßig kommunizieren zu können. kann über eine schaltbare Steckdose der airpurifier aus bzw. wieder eingeschaltet werden. So öffnet man immer wieder das 15min-Zeitfenster.
Da der airpurifier seine Einstellungen mit jedem Abschalten "verliert", müssen nach jedem Wiedereinschalten die "Wunscheinstellungen" neu über FHEM mit den set-Befehlen ausgeführt werden.
Somit ein gangbarer Workaround, um die Cloud zu vermeiden.
Was man noch machen sollte: der WLAN-AP-IP muss vermutlich der Zugang zum Internet gesperrt werden(direkt am Router, die Xiaomi-domains über pi-hole, die Xiaomi-IPs über iptables,.....)
Und, wie schon geschrieben, der airpurifier-WLAN-AP ist offen. Also für jedermann sichtbar und ohne Kennwort zugänglich. Man muss also irgendwie sicherstellen, dass nur die Antworten auf die FHEM-requests verarbeitet werden. Sämtlicher sonstige Traffic müsste gesperrt werden. Ist mir noch unklar wie man das erreichen kann...
Deine Methode hat natürlich den großen Nachteil, dass eine durchgängige Aufzeichnung der Sensorwerte oder eine FHEM-Reaktion auf Sensorwerte nicht sinnvoll möglich ist. :'(
Durch die von Dir gewählte "Methode" hast Du mich aber auf einen Ansatz gestoßen, der es wert ist einmal auszuprobieren: Das Viertelstundenfenster anderweitig(softwaretechnisch) "neu" zu erzwingen.
Was mag der AP machen, wenn man
- kurzzeitig die WLAN-Verbindung kappt
- mit einer anderen IP (also Änderung der Client-IP) erneut zugreift
- andere Dinge macht, die der AP normalerweise von der Äpp erwartet
- ..... ?
Hallo,
... Du hast das jetzt viel verständlicher (und kürzer) beschrieben; so kann ich das jetzt 1:1 in meine Doku übernehmen, natürlich mit Quellenangabe ;-)
Zu Deinen Anmerkungen:
- das ganze läuft jetzt bei mir mit 5x Geräten zur vollsten Zufriedenheit, mit einem Regelwerk, das die Airpurifys an- und ausschaltet z.B. bei Fenster/Zu/Auf oder Raum/genutzt/Ja/Nein u.a.
Und das immer mit "meinen" Konfigurationswerten (individuell pro Gerät) - die Messwerte (readings) aus den Geräten (wie temperature, humidity, ...) sind für mich Nebensache, da ich von den Sensoren aus den Airpurifys nichts benutze; die Werte bekomme ich von anderen Sensoren mit Fhem "stressfreier". Ausnahme, und da reicht der Aktualisierungstakt alle Mal: filter_life, filter_used
- Danke für Deinen Hinweis; das werde ich mal ausprobieren. Bestenfalls kann ich mir die aktuelle Re-Konfig der dedizierten WLAN-Schnittstelle mit externem setuid-coded C-Progrämmchen ersparen.
ZitatMit dem XiaomiDevice-Modul lässt sich der airpurifier in FHEM mit der IP des airpurifier-WLAN-AP definieren
Code: [Auswählen]
define airpurifier XiaomiDevice 192.168.4.1
Nun ist der airpurifier von FHEM aus bedien- und abfragbar. Aber nur für jeweils die vorgenannte Viertelstunde. Denn dann schließt der airpurifier wieder seinen AP.
- Dass der Airpurify die Einstellungsänderungen bei Abschalten (230V) vergisst, stört nicht besonders (Ausnahme: ggf., buzzer piept 1x beim Einschalten), da in der Einschalt-Prozedur die von Fhem festgelegten Änderungen an den default Einstellungen von Xiaomi überschreibt.
Immerhin: die aktuellen readings der Filterwerte werden durch Ausschalten nicht vergessen! ZitatWas man noch machen sollte: der WLAN-AP-IP muss vermutlich der Zugang zum Internet gesperrt werden(direkt am Router, die Xiaomi-domains über pi-hole, die Xiaomi-IPs über iptables,.....)
Klar, sonst macht der ganze Aufwand wenig Sinn ...ZitatUnd, wie schon geschrieben, der airpurifier-WLAN-AP ist offen. Also für jedermann sichtbar und ohne Kennwort zugänglich. Man muss also irgendwie sicherstellen, dass nur die Antworten auf die FHEM-requests verarbeitet werden. Sämtlicher sonstige Traffic müsste gesperrt werden. Ist mir noch unklar wie man das erreichen kann...
Zur Zeit schätze ich das nicht als echte Betrohung ein: zum hacking von extern muss der bekannte Aufwand betrieben werden, um an das notwendige token zu kommen. Na toll, dann kann die Attake auf den jeweiligen Airpurify ja starten ;-) Mit dem Risiko kann ich - gemessen am Nutzen zur Steuerbarkeit der Airpurifys - leben.
Ansonsten ist damit kein offenes Tor zur sonstigen IT-Infrastruktur verbunden, oder habe ich etwas übersehen ?Zitat
Deine Methode hat natürlich den großen Nachteil, dass eine durchgängige Aufzeichnung der Sensorwerte oder eine FHEM-Reaktion auf Sensorwerte nicht sinnvoll möglich ist.
Wie schon gesagt, auf die Sensorwerte der Airpurify kann ich gerne verzichten, da mir entsprechende Werte von anderen Sensoren zur Verfügung stehen;
und wichtig, die readings über die Filter sind nutzbar, zwar nicht in "Realzeit" aber alle Mal in ausreichendem Intervall mittels "notify" u.a.ZitatDurch die von Dir gewählte "Methode" hast Du mich aber auf einen Ansatz gestoßen, der es wert ist einmal auszuprobieren: Das Viertelstundenfenster anderweitig(softwaretechnisch) "neu" zu erzwingen.
Was mag der AP machen, wenn man
- kurzzeitig die WLAN-Verbindung kappt
- mit einer anderen IP (also Änderung der Client-IP) erneut zugreift
- andere Dinge macht, die der AP normalerweise von der App erwartet
Das ist komplett gelöst über die Verwaltung mittels Queue (in 99_myUtils.pm) und spezielle userreading xpower [on|off] (welcher Airpurify wird aktuell über konfiguriertes WLAN "beackert" und mittels "xpower" kann Fhem jederzeit abfragen, ob der Airpurify eingeschaltet und mit den eigenen Vorgabewerten läuft).
"Änderungswünsche" zum Status der Airpurifys - seitens Fhem - werden immer über die Queue abgewickelt; um nicht den komplizierten WLAN-connect Ablauf zu stören.
Wird eine Konfig-setup Prozedur nicht vollständig abgearbeitet, bleibt der Auftrag in der Queue bestehen, und wird bei Gelegenheit wiederholt.
Und, nach meinen Beobachtungen veranstalten die Airpurifies in dem hier beschriebenen setup/config selbstständig keine irgendwelchen Dinge, die fremdgesteuert den eigenen Vorgaben zuwiderlaufen, sondern laufen nach dem setup (und den bekannten 15 Minuten bzw. Abbruch der WLAN-Verbindung) im gewünschten Zustand autark weiter, sollen sie auch ! ;-)
Vielleicht liest der Autor des Moduls
72_XiaomiDevice.pm ja mit.
Ich könnte mir vorstellen, dass man aus unserer Diskussion durchaus Anregungen in das Modul einbauen könnte, um die Xiaomi-Devices cloud-less zu "zähmen" oder ?
Das wäre eine große Vereinfachung, statt sich auf Fhem-Anwenderebene in "system-nahe" Frickelei zu verirren.
Wenn's hilft, natürlich stelle ich meine Code-Teile zur Verfügung, auch wenn die aus meiner Anwendungs so nicht übernoimmen werden können.
Gruß
JHS
Zitat
Was man noch machen sollte: der WLAN-AP-IP muss vermutlich der Zugang zum Internet gesperrt werden(direkt am Router, die Xiaomi-domains über pi-hole, die Xiaomi-IPs über iptables,.....)
Klar, sonst macht der ganze Aufwand wenig Sinn ...
Das erschließt sich mir nicht...
Der AP ist doch "isoliert", also steht "nur für sich".
Fhem verbindet sich über einen "extra" WLAN-Client-Zugang genau nur mit diesem AP...
Solange niemand zwischen 192.168.4.0/24 und dem Internet routet gibt es doch eh keine Verbindung?
Wenn also die NW-Konfiguration auf dem fhem-Server NICHT routet, sondern eben "nur" im Restnetz "steckt" und sich Daten vom AP holt kann doch nichts passieren?
Es dürften ja nicht mal Pakate (die geblockt werden müssten) bei der Firewall ankommen?
EDIT: eher kritisch sehe ich das mit dem, dass der AP offen ist! Solange sich nur EINER damit verbinden kann und fhem immer dieser EINE ist, ist alles (halbwegs) ok. Wenn aber mehr Verbindungen zulässig sind, dann kann sich doch einfach noch jemand mit dem AP verbinden und dann (theoretisch) auf fhem zugreifen?
Gruß, Joachim
Hallo,
liegt da ein technisches Missverständnis zur Anmerkung von
KölnSolar vor ? ich hatte das wie folgt gemeint:
in der Konfig, die ich beschrieben habe und konfigiert habe, unabhängig ob 192.168.4.0/24 oder 192.168.13.0/24 ...
- ist der Airpurify der "offene" WLAN-Access-Point, der von einem externen unbefugten WLAN client gehacked werden könnte. Aber was kann man mit diesem Hack erreichen:
schlimmstenfalls, mit entsprechend Aufwand die Airpurifys verbiegen, aber zumindest das nicht unbemerkt;
ein factory reset am Airpurify sorgt dann wieder für klare Ausgangsverhältnisse; somit würde ich diese Konfig schon fast als "honeypot-WLAN" für die Fhem Infrastruktur bezeichnen ;-) weil, interessant zu wissen, dass Attacken auf das eigene WLAN geritten werden.
Also für wen lohnt sich der hacking Aufwand? Für mich überwiegt eindeutig der Vorteil, die (diese) Hersteller-cloud nicht benutzen zu müssen und die Airpurifys trotzdem über ein eigenes WLAN ansteuern zu können. - auf Fhem von außen zugreifen über das dedizierte exklusive Airpurify-Server-WLAN-Interface - im client mode - ist meiner Meinung nach nicht möglich (aus Sicht mit meinen bescheidenen Netzwerkkentnissen)
Gruß
JHS
Auch meine Netzwerkkenntnisse gehen ad-hoc nicht weit genug. :'( Ich meide ja WLAN-FHEM-devices wie der Teufel das Weihwasser und hab daher auch keinen Plan, wie man WLAN-devices in einem eigenen Subnet "einsperrt" und trotzdem mit dem FHEM-Server(dessen Subnet) kommunizieren lässt.
In meiner "Standard-Konstellation" mit Nutzung des RPi-WLAN-Adapters wird wohl geroutet(glaube ich). Und speziell zu FHEM: Mein FHEM ist nicht per "allowed" geschützt, da ich dafür in meinem lokalen Netzwerk keine Notwendigkeit sehe.(umgekehrt ist es lästig sich anmelden zu müssen)
Spielen wir es doch mal grob durch:
- Das Xiaomi-Linux kennt kein Gateway. Neben dem WLAN-AP wird vermutlich auch noch ein DNS gestartet(nehme ich an, weil die Äpp ja keine statische IP haben wird). Offen wie ein Scheunentor.
Der FHEM-Server meldet sich nun mit seiner IP am AP an.
Nun meldet sich noch "jemand" am AP an. Der DNS vergibt ggfs. eine IP (oder eine statische IP meldet sich an).
Nun befinden sich alle 3 devices in einem Subnet und alles ist in diesem Subnet theoretisch erst einmal möglich, oder ?
Sofern mehrere Clients am Xiaomi-Server möglich sind, lässt sich dann doch vom Dritten schon mit z.B. nmap alles Wissenswerte(IP,Ports,Services) ermitteln.
Und dann ist es doch nur noch eine Frage der jeweiligen Absicherung der Services, zu denen man sich Zugang verschaffen kann. Also "nur" noch User/Passwort der jeweiligen Services und man hat als Dritter alle Möglichkeiten, die der Service bietet.(Bei meinem "offenen" FHEM also quasi alles für einen FHEM-Kenner).
Wenn ich mit meinem Laienverständnis nicht falsch liege: Wie blockiere ich Zugriffe mit Linux-Bordmitteln von anderen IPs als der des APs ?
Grüße Markus
Solange keiner routet (und normalerweise, wenn du "nur" mit einem SP verbindest und "nur" damit in diesem Subnetz also 192.168.4.0/24 unterwegs bist) dann findet nmap auch "nur" IPs/Rechner in diesem Subnetz, schlimm genug, weil ja bei dir damit fhem ohne Schutz zu finden ist/wäre.
Blocken kannst du das mit lokalen Firewall-Regeln auf dem fhem-PI.
Allerdings kenne ich mich mit dem "Consolen-Firewall-Tool" auf dem PI zu wenig aus.
Habe Unifi mit Security-Gateway und erstelle Firewall-Regeln dort "graphisch"... 8)
Aber es gibt wohl ein Tool (UFW?) mit dem es zumindest angenehmer als mit iptables geht, ohne das wirklich beurteilen zu können.
Damit kannst du dann den PI auf dem WLAN-Netz (192.168.4.0/24) komplett abschirmen, weil eigentlich ja keine aktive Verbindung zu fhem muss?
fhem will ja nur zum Xiaomi-Gerät?
Also kannst du alles blocken, außer (related) und established.
Heißt: niemand darf "rein". Wenn aber fhem mal rausgerufen hat, dürfen Antworten zurück. Sonst nichts. Theoretisch kannst du auch noch Ports beschränken. Musst du aber nicht, da du ja in fhem im Griff hast welche Ports du nutzt/nutzen willst/musst.
Wenn doch das Xiaomi-Gerät aktiv auf fhem zugreifen muss (was mich wundern würde), dann musst du halt in die Firewall ein (weiteres) "Loch" machen, dass da heißt: source 192.168.4.1 und destination 192.168.4.x (wobei x halt die fhem Adresse ist in dem Subnetz) ist.
Da das Xiaomi-Gerät ja offenbar immer die 192.168.4.1 hat, kann das ja fix so sein/bleiben.
Wichtig wäre halt, dass fhem auch immer dieselbe IP bekommt (ob da nämlich localhost geht: keine Ahnung)...
Also wie geschrieben hätte ich nur/eher "Angst" davor, dass jemand sich auch/zusätzlich mit dem AP verbindet und dann auf mein fhem käme...
Weiter als fhem sollte dann ohne, dass ein Routing eingerichtet ist/wurde (und das musst du wirklich tun, also das kommt [normalerweise] nicht einfach "von selbst") niemand kommen.
Aber das wäre ja schon schlimm genug.
Ich denke du meinst nicht DNS sonder DHCP-Server zur Vergabe von IPs ;)
Gruß, Joachim
Hallo,
... mit meinen rudimentären Netzwerkkenntnissen ... habe ich mal eben ein Test gemacht:
- Wie ich für meine Konfig beschrieben habe, IP Adresse/airpurifX 192.168.13.1 (=factory reset Wert) und wlan2 (192.168.13.11 =Fhem-Server das für die Kommunikation mit airpurify reservierte WLAN-Interface).
- Die Kommunikation zwischen diesen beiden Netzwerkteilnehmern lief, a) ließ sich das auf dem Fhem-Server beobachten und b) war danach der Airpurify eingeschaltet, online und konfiguriert (und mdst. die bekannten 15 Minauten über als AP erreichbar)
- Für diese 15 Munten habe ich einen Laptop wlan-mäßig für dieses Netzwerk vorbereitet und von je einem Consolen Fenster aus ping auf 192.168.13.1 und 192.168.11 gestartet, mit folgenden Ergebnissen:
- Vom AirpurifyX bekam das Laptop-WLAN-Interface die Adresse 192.168.13.2 zugewiesen, wie zu erwarten war.
- Der AirpurifyX (192.168.13.1) war vom Laptop (192.168.13.2) aus per ping erreichbar; auch das war zu erwarten.
- Der AirpurifyX (192.168.13.1) war vom Laptop (192.168.13.2) aus aber nicht zu erreichen per ssh | telnet | ftp!
- Das Fhem-Server-Interface war in keiner Weise zu erreichen (per ping etc. und folglich auch nicht mit andern services, weder direkt noch via routing über den AP des Airpurify)
Fazit:
ich persönlich sehe zur Zeit keine Gefahr für erfolgreiche Angriffe über den Umweg des (temporär) offenen Airpurify WLANs auf meine sonstige Fhem-IT.
Und wie gesagt, eine Cloud, in der meine WLAN-Zugangsdaten etc. gehalten werden und dass diese Daten in falsche Hände geraten, stellt aus meiner Sicht eine viel größere Gefahr dar.
Zu erwähnen bleibt noch, an dieser Stelle nochmals nachzufragen - falls mein genannter Vorschlag zur Steuerung der Xiaomi Airpurifyer Anklang findet, ob dieses Verfahren nicht in das Modul verankert werden könnte ?
Ich denke, es würde sich lohnen; die Geräte sind wohl recht zahlreich verbreitet.
Mir fehlen dafür leider die Kenntnisse für die Implementierung.
Gruß
JHS
Hast du mal versucht dich per ssh auf dem fhem Server einzuloggen (vors. ssh ist dort konfiguriert)?
EDIT: überlesen... Hast do offenbar getestet...
Dass das Xiomi Gerät nicht per ssh/telnet usw. "erreichbar" ist kann logisch sein: die Dienste werden dort halt nicht laufen...
Trotzdem kann man per se auf den fhem Server zugreifen bzw. ist zumindest schon mal im selben Netz.
D.h. wenn Dienste laufen, kann man evtl. Schaden anrichten...
Daher wäre der ssh-Test interessant...
Gruß, Joachim
ZitatIch denke du meinst nicht DNS sonder DHCP-Server zur Vergabe von IPs ;)
Yes. ::)
Die Tests bestätigen also, dass sich mehr als ein client beim AP anmelden können. :'(
ZitatDass das Xiomi Gerät nicht per ssh/telnet usw. "erreichbar" ist kann logisch sein: die Dienste werden dort halt nicht laufen...
Denke ich auch.
Ich fände daher interessanter per nmap zu testen(ich hab derzeit leider das WLAN des RPi anderweitig in Nutzung, so dass ein Test derzeit nicht möglich ist). Damit sieht man welche services auf welchen Ports auf dem AirpurifyX laufen(wenn man etwas sieht)
ZitatDas Fhem-Server-Interface war in keiner Weise zu erreichen (per ping etc. und folglich auch nicht mit andern services, weder direkt noch via routing über den AP des Airpurify)
Das kann ich Dir mangels eigener Tests nur glauben. Verwundert mich aber schon. Einen ping habe ich noch immer im selben subnet hinbekommen. Also ping von Laptop an 192.168.13.11 ohne Erfolg ?
Was mag dann der "Mechanismus" sein, dass sogar einen ping im subnet verhindert ? Ob es was damit zu tun hat, dass die IP des FHEM-Servers statisch und nicht per DHCP vergeben ist ? :-\
ZitatUnd wie gesagt, eine Cloud, in der meine WLAN-Zugangsdaten etc. gehalten werden und dass diese Daten in falsche Hände geraten, stellt aus meiner Sicht eine viel größere Gefahr dar.
Ich bin immer noch einig mit Dir. ;)
Aber wir sollten halt schon gucken, dass wir hier eine Lösung erarbeiten, die größtmöglichen Schutz bietet. Will heißen: Wenn sowieso sichergestellt ist, dass man nur an den Airpurify kommt, so what. Wenn nicht, sollte als Ergebnis unserer Diskussion(Deiner Tests) eine zusätzliche Maßnahme zur Absicherung herausspringen.
Grüße Markus
Edit: Hab gerade mal ins Modul geguckt: UDP-Zugriff auf Port 54321
Und um auf Joachims Mutmaßung zu antworten: Es sieht nicht danach aus, als ob der Airpurify etwas aktiv in Richtung des Clients(bei uns FHEM) pushed. Könnte man per tcpdump noch checken.
Hallo,
nur mal so ins Blaue geraten:
ZitatEdit: Hab gerade mal ins Modul geguckt: UDP-Zugriff auf Port 54321
Und um auf Joachims Mutmaßung zu antworten: Es sieht nicht danach aus, als ob der Airpurify etwas aktiv in Richtung des Clients(bei uns FHEM) pushed. Könnte man per tcpdump noch checken.
Man darf unterstellen, dass das Airpurify device darauf ausgerichtet ist, in der Initialisierungs-Phase mit der Xiaomi APP Kontakt aufzunehmen, und diese Daten dürften eigentlich keinen Schaden in Fhem anrichten, sondern wenn Sie für das Fhem-Modul keinen Sinn machen, einfach "im Müll" landen.
Die Frage ist noch offen, ob der Maintainer von Modul
72_XiaomiDevice.pm hier mitliest und evtl. noch mal in die Problematik einsteigt.
Gruß
JHS
Mir ging es nicht drum, dass das Xiaomi Gerät Richtung fhem was "pushed", sondern ein zusätzlicher Client (da der AP ja offen ist und mehrere Clients zulässt) etwas anrichten kann/könnte...
Daher ja auch der Vorschlag alles (außer established) in Richtung fhem Server per Firewall auf dem fhem Server zu blocken...
Und was nun sicherer ist: WLAN-PW in China was aber nur jemandem nutzt, der dann örtlich nah ist...
...oder ein (wenn auch begrenztes?) offenes WLAN (mit "Zugang" zum fhem Server)... ;)
EDIT: bei mir würde ein potentieller "Angreifer", der das WLAN-PW kennt max. in mein IoT-VLAN gelangen ohne Zugriff auf irgendwas, nicht mal zwischen IoT Geräten selbst. Und zu fhem oder sonstigen Diensten in einem anderen VLAN darf nur, was ich explizit freischalte... 8)
Drum hab ich am liebsten Geräte, die gleich mit einer alternativen FW geflasht werden können oder zumindest auch ohne App/Cloud eingerichtet werden können... :)
Allemal interessant hier...
Gruß, Joachim
ZitatMan darf unterstellen, dass das Airpurify device darauf ausgerichtet ist, in der Initialisierungs-Phase mit der Xiaomi APP Kontakt aufzunehmen, und diese Daten dürften eigentlich keinen Schaden in Fhem anrichten, sondern wenn Sie für das Fhem-Modul keinen Sinn machen, einfach "im Müll" landen.
Sehe ich so.
ZitatDie Frage ist noch offen, ob der Maintainer von Modul 72_XiaomiDevice.pm hier mitliest und evtl. noch mal in die Problematik einsteigt.
keine Antwort ist auch ne Antwort. ;)
ZitatDaher ja auch der Vorschlag alles (außer established) in Richtung fhem Server per Firewall auf dem fhem Server zu blocken...
Vermutlich ein guter Vorschlag aber für mein Know how ne Nummer zu groß(ohne mich weiter aufzuschlauen) ;)
ZitatDrum hab ich am liebsten Geräte, die gleich mit einer alternativen FW geflasht werden können oder zumindest auch ohne App/Cloud eingerichtet werden können... :)
Frag mich. Geht aber leider nicht. :'(
Ich weiß, dass man die Firmware auslesen und flashen kann. SSID U. Key stehen angeblich im Klartext dort.
Meine Idee: an fremdem Router und WLAN pairen, Token ermitteln. Firmware auslesen, SSID U. Key überschreiben, zurück flashen. Natürlich nach außen "mundtot" machen. Aber die Zeit.....
Grüße Markus
Edit: Ich hab gerade noch einmal schnell einen Blick in meine über ein Jahr alten Recherchen gemacht. Zum einen mal attached ein anonymisierter Extrakt der firmware/flash-Speicher :-\(aus dem Internet). Gibt einem ein wenig ein Gefühl wie das "Ding" so aussieht. Und vielleicht erzeugt das bei Euch ja ne Idee. Die unverschlüsselt sichtbaren hardcodierten domain-names und IP-Adressen hatte ich glaube ich bereits irgendwo (https://forum.fhem.de/index.php/topic,117021.msg1114081.html#msg1114081) im Forum veröffentlicht(Gerade habe ich noch gesehen, dass in der attachten Datei auch noch ein wenig Info über die firmware hinaus steht. Und in der letzten Zeile der Hinweis auf die unerwünschte Cloud-Kommunikation)
Da ich nun auch ein Jahr schlauer bin und die Meldungen der Services(Logmeldungen des Moduls) überflogen habe, spekuliere ich, dass es sich möglicherweise um mDNS/m-DNS handelt(UPnP/SSDP schließe ich eher aus). Denn in den Logmeldungen findet sich vergleichbar den UPnP-Service-messages die Stichworte "properties" und "events". UPnP ließe sich leicht mit meinem UPNPController (https://forum.fhem.de/index.php/topic,118837.msg1132815.html#msg1132815) eroieren. Für mDNS/m-DNS ist André (https://forum.fhem.de/index.php/topic,126262.msg1208783.html#msg1208783) gerade dabei ein Modul zu entwickeln(ich selber habe davon gar keine Ahnung), welches man zum Testen einsetzen könnte.
Und der UPNPController ist leider genau der Grund, warum ich derzeit nur rudimentär unterstützen kann. Das Modul muss endlich produktiv werden. 8)
Zitat von: jhs am 20 April 2022, 21:43:37zhimi-airpurifier-mc2_miapeeff
Die IP-Adresse der airpurify devices in diesem Inbetriebnahme Mode als WLAN-AP ist konstant 192.168.13.1.
Hallo! Ich hoffe es ist in Ordnung, wenn ich den Thread nochmal eröffne. Ich versuche mich gerade an dieser Lösung mit dem Xiaomi Air Purifier 4 Lite und einem RPI Zero. Erste Feststellung: Es scheint als wäre der initiale WLAN-AP bei meinem Xiaomi etwas länger als 15 Minuten an (konnte das Netz ca. 30 Minuten nach Start sehen). Die Mac-Adresse und SSID habe ich identifizieren können; aber wie genau finde ich die IP-Adresse raus, die der Xiaomi nutzt? Da scheint es ja Unterschiede zwischen den Geräten zu geben. Mir ist auch nicht ganz klar, wie ich die vorgeschlagenen WLAN-Einstellungen dann im Raspberry vornehme.
Vielen Dank und viele Grüße
EDIT: Ich habe inzwischen Verbindung zu dem WLAN, allerdings bekomme ich mit sudo arp -a zurück: ? (192.168.4.1) at <incomplete> on wlan0. Habe jetzt 192.168.1.1 bis 192.168.13.1 durchprobiert. Bin ich da auf dem richtigen Weg? Ich rechne damit, dass irgendwann die Mac-Adresse des Xiaomi zurückgegeben wird