HmIP-Sender an zwei verschiedenen CCU

[zautrix]

Nein, so einfach funktioniert das nicht.

Doch, ich finde schon!

Ich habe eine CCU A (angeschaltet) mit ca. 15 HM IP Geräten angelernt. Und ca 80 HM ohne IP.
Ich habe eine CCU B (ausgeschaltet) mit dem Backup der CCU A eingespielt.
Ich habe ein HMIP Gerät X.


Ich kappe die Internetverbindung.
Ich schalte HMIP Gerät X über Webui der CCU A ein uns aus. Geht.
Ich schalte CCU A aus.
Ich schalte CCU B an.
Ich schalte HMIP Gerät X über Webui der CCU B ein uns aus. Geht.
Wo wird da ein Schlüssel für wen von wo geholt? So ohne Internet?
Die Geräte von eQ3 können mittlerweile Telepathie?
So weit die Fakten, was ich gerade ausprobiert habe.

Nun folgendes Gedankenexperiment:
Ich schalte CCU B wieder aus, CCU A wieder an. Kann Gerät X schalten über Webui von A.
Ich nehme die CCU B und Gerät X unter den Arm und gehe mal so 1 km weit wech.
Ich schalte die CCU B ein. Ich muss Gerät X mit CCU B schalten können. Ging ja gerade auch noch.
Ich nehme Gerät X mit zur CCU A. Ich muß Gerät X mit CCU A schalten können. Ging ja gerade auch noch.

Also kann man ein portables HMIP Gerät mit zwei entfernten CCUs bedienen. Ohne Internetverbindung oder Schlüsselgenerierung.
q.e.d.

[hobbyquaker]

Das glaube ich nicht - und ich bin mir da sehr sehr sicher. Aber Du hast mich neugierig gemacht, werde das selbst mal testen und berichten

[zautrix]

Das glaube ich nicht - und ich bin mir da sehr sehr sicher. Aber Du hast mich neugierig gemacht, werde das selbst mal testen und berichten

Komm doch vorbei und schau es dir an. Sind doch wohl keine 100 km Entfernung...

[hobbyquaker]

Hab's nachgestellt - und wie ich mir schon dachte bestätigt es meine Annahme und widerspricht dem was Du schriebst. Ohne Internet kein Rekeying - ohne Rekeying keine HmIP-Devices. Hier der genaue Ablauf:

CCU-A: 2 HmIP Geräte angelernt

CCU-A backup erstellt

CCU-A ausgesteckt

Backup in CCU-B eingespielt, CCU-B macht reboot

CCU-B hmserver.log nach reboot zeigt Re-Keying:

Code: Alles auswählen

Jan 6 01:19:05 de.eq3.cbcs.server.local.base.internal.HMIPTRXInitialResponseListener INFO  [Thread-6] Exchanging adapter from 3014F711A0001F58A9XXXXXX to 3014F711A061A7D3CXXXXXX ... 
...
Jan 6 01:19:04 de.eq3.cbcs.server.local.base.internal.HMIPTRXInitialResponseListener INFO  [Thread-6] No NWK, try to set address ... 
...
Jan 6 01:19:23 de.eq3.cbcs.server.local.base.internal.HMIPTRXInitialResponseListener INFO  [vert.x-eventloop-thread-1] Adapter exchange successful. 

CCU-B: HmIP Geräte lassen sich steuern.

CCU-B ausgeschaltet

CCU-A eingeschaltet

CCU-A: HmIP Geräte lassen sich steuern

Firewallregel auf Router gesetzt um CCU-B Internet zu verbieten:

Code: Alles auswählen

iptables -I FORWARD -s 172.16.23.175 -j DROP
iptables -I FORWARD -s 172.16.23.175 -j LOG

CCU-A ausgeschaltet

CCU-B eingeschaltet

CCU-B versucht erfolglos Verbindungen ins Internet aufzubauen, sichtbar im Log meines Routers:

Code: Alles auswählen

Jan  6 01:27:38 apu kernel: [1224563.404082] IN=enp1s0 OUT=enp2s0 MAC=00:0d:b9:49:63:cc:b8:27:eb:74:5a:c5:08:00 SRC=172.16.23.175 DST=78.46.53.2 LEN=76 TOS=0x00 PREC=0x00 TTL=63 ID=41707 DF PROTO=UDP SPT=56473 DPT=123 LEN=56 
Jan  6 01:27:38 apu kernel: [1224563.404288] IN=enp1s0 OUT=enp2s0 MAC=00:0d:b9:49:63:cc:b8:27:eb:74:5a:c5:08:00 SRC=172.16.23.175 DST=134.102.201.104 LEN=76 TOS=0x00 PREC=0x00 TTL=63 ID=11526 DF PROTO=UDP SPT=56473 DPT=123 LEN=56 
Jan  6 01:27:39 apu kernel: [1224563.604083] IN=enp1s0 OUT=enp2s0 MAC=00:0d:b9:49:63:cc:b8:27:eb:74:5a:c5:08:00 SRC=172.16.23.175 DST=5.9.121.21 LEN=76 TOS=0x00 PREC=0x00 TTL=63 ID=15527 DF PROTO=UDP SPT=56473 DPT=123 LEN=56 
Jan  6 01:27:39 apu kernel: [1224563.804109] IN=enp1s0 OUT=enp2s0 MAC=00:0d:b9:49:63:cc:b8:27:eb:74:5a:c5:08:00 SRC=172.16.23.175 DST=167.86.121.184 LEN=76 TOS=0x00 PREC=0x00 TTL=63 ID=44956 DF PROTO=UDP SPT=56473 DPT=123 LEN=56 
Jan  6 01:27:39 apu kernel: [1224564.004112] IN=enp1s0 OUT=enp2s0 MAC=00:0d:b9:49:63:cc:b8:27:eb:74:5a:c5:08:00 SRC=172.16.23.175 DST=94.16.114.254 LEN=76 TOS=0x00 PREC=0x00 TTL=63 ID=1629 DF PROTO=UDP SPT=56473 DPT=123 LEN=56 
Jan  6 01:27:39 apu kernel: [1224564.204183] IN=enp1s0 OUT=enp2s0 MAC=00:0d:b9:49:63:cc:b8:27:eb:74:5a:c5:08:00 SRC=172.16.23.175 DST=144.76.0.164 LEN=76 TOS=0x00 PREC=0x00 TTL=63 ID=45058 DF PROTO=UDP SPT=56473 DPT=123 LEN=56 
Jan  6 01:27:39 apu kernel: [1224564.404097] IN=enp1s0 OUT=enp2s0 MAC=00:0d:b9:49:63:cc:b8:27:eb:74:5a:c5:08:00 SRC=172.16.23.175 DST=217.144.138.234 LEN=76 TOS=0x00 PREC=0x00 TTL=63 ID=1171 DF PROTO=UDP SPT=56473 DPT=123 LEN=56 
Jan  6 01:27:40 apu kernel: [1224564.604166] IN=enp1s0 OUT=enp2s0 MAC=00:0d:b9:49:63:cc:b8:27:eb:74:5a:c5:08:00 SRC=172.16.23.175 DST=80.152.201.148 LEN=76 TOS=0x00 PREC=0x00 TTL=63 ID=27512 DF PROTO=UDP SPT=56473 DPT=123 LEN=56 
Jan  6 01:27:40 apu kernel: [1224564.804131] IN=enp1s0 OUT=enp2s0 MAC=00:0d:b9:49:63:cc:b8:27:eb:74:5a:c5:08:00 SRC=172.16.23.175 DST=192.53.103.108 LEN=76 TOS=0x00 PREC=0x00 TTL=63 ID=24854 DF PROTO=UDP SPT=56473 DPT=123 LEN=56 
Jan  6 01:27:40 apu kernel: [1224565.004117] IN=enp1s0 OUT=enp2s0 MAC=00:0d:b9:49:63:cc:b8:27:eb:74:5a:c5:08:00 SRC=172.16.23.175 DST=213.172.105.106 LEN=76 TOS=0x00 PREC=0x00 TTL=63 ID=20540 DF PROTO=UDP SPT=56473 DPT=123 LEN=56 
Jan  6 01:27:40 apu kernel: [1224565.204169] IN=enp1s0 OUT=enp2s0 MAC=00:0d:b9:49:63:cc:b8:27:eb:74:5a:c5:08:00 SRC=172.16.23.175 DST=138.201.90.189 LEN=76 TOS=0x00 PREC=0x00 TTL=63 ID=60336 DF PROTO=UDP SPT=56473 DPT=123 LEN=56 
Jan  6 01:27:40 apu kernel: [1224565.404154] IN=enp1s0 OUT=enp2s0 MAC=00:0d:b9:49:63:cc:b8:27:eb:74:5a:c5:08:00 SRC=172.16.23.175 DST=134.102.201.104 LEN=76 TOS=0x00 PREC=0x00 TTL=63 ID=11657 DF PROTO=UDP SPT=56473 DPT=123 LEN=

CCU-B hmserver.log zeigt nach Start eine Exception:

Code: Alles auswählen

Jan 6 01:27:54 de.eq3.cbcs.server.core.persistence.AbstractPersistency ERROR [vert.x-worker-thread-0] Could not do command: PERSISTENCE_COMMAND_LOAD_DEVICES 

Hmipserver teilt der Rega mit dass es keine HmIP Devices mehr gibt (die 52 übrigen Geräte/Kanäle sind die virtuellen Tasten):

Code: Alles auswählen

Jan 6 01:29:05 de.eq3.cbcs.legacy.bidcos.rpc.internal.DeviceUtil INFO  [vert.x-worker-thread-4] updateDevicesForClient 1011 -> 77 device addresses will be deleted 
Jan 6 01:29:17 de.eq3.cbcs.legacy.bidcos.rpc.internal.DeviceUtil INFO  [vert.x-worker-thread-4] updateDevicesForClient 1011 -> 52 device addresses will be added 

CCU-B: Im WebUI sind (ausser den virtuellen Tasten) keine HmIP Geräte mehr vorhanden.

Keine Ahnung was Du da für Magic betrieben hast, folgende Vermutung drängt sich mir auf: Du hast die Verbindung zum Keyserver nicht wirklich unterbunden. Auf welche Art und Weise hast Du denn die Internetverbindung "gekappt"? War die wirklich schon vor dem Boot unterbunden?
Wenn das was Du da schreibst funktionieren würde hättest Du (jedenfalls soweit ich das HmIP-Protokoll richtig verstehe) eine Sicherheitslücke entdeckt, das darf imho nicht funktionieren. Der NWK (Network Key) ist (wie gesagt) auf dem CoPro des Funkmoduls gespeichert (und kann nicht ausgelesen werden), der ist nicht Teil des Backups.

Nichts desto trotz: man kann das natürlich schon so machen - aber das Re-Keying muss stattfinden wenn das Funkmodul und damit der NWK ein anderer ist, der Keyserver muss erreichbar sein, sonst ist HmIP tot. In der Praxis und bei der konkreten Frage "eine HmIP-Fernbedienung an zwei CCUs möglich?" bedeutet dass das beim ersten Tastendruck das Rekeying ausgelöst wird - beim zweiten Tastendruck könnte sie dann schon funktionieren, müsste man mal testen. Kann aber nur klappen wenn die Funkmodule beider CCUs die gleiche AP Adresse haben, man muss also wirklich auch mal ein Backup der einen auf der anderen eingespielt haben.
Je nach Anzahl der Geräte und Auslastung von secgtw.homematic.com kann das Rekeying aber durchaus auch mal länger dauern... Bei meinem Test mit nur 2 Always-Listener Geräten ging es natürlich sehr schnell (~20 Sekunden), sobald aber ein Config-Listener im Spiel ist (z.B. TFK oder Fernbedienung) zögert sich das raus bis die Geräte sich auch mal gemeldet haben.

Ich fänd's cool wenn noch ein Dritter die Muse hätte das zu verifizieren, ich bin mir zwar 99,9% sicher, aber das letzte Promill Unsicherheit müsste jemand anderes aus der Welt schaffen, ich schließe nicht aus dass ich mich irre oder irgendwas falsch verstehe - auch wenn ich es für sehr unwahrscheinlich halte

Auch interessant, ein anderer/weiterer Test - beim Versuch bei einer CCU die nicht ins Internet darf ein Backup einzuspielen erscheint folgendes Popup (das mich auch in meiner Ansicht bestärkt):

[Daimler]

Hi,

ich kann deine Beobachtungen nicht nachvollziehen!

Ich habe das jetzt hier auch einmal nachgestellt!
Mangels vorhandener IP-FB mit einem HMIP-Mio16 und einer HM-RC-4-3, welche einen Kanal des MIO16 per Programm ein- und ausschaltet.
CCU-A > Orignal mit RPI-RF-MOD
CCU-B > Backup-Clone mit HM-MOD-RPI-PCB

CCU-A Backup erstellt
CCU-A herunter gefahren
Backup auf CCU-B eingelesen > Neustart
Mit Netz, da hier beim 1. Start das Rekeying stattfinden muss - über diesen (Un)Sinn will ich mich jetzt nicht weiter auslassen.
Anschließend konnte ich mit der FB mittels des Progrämmchens Kanal 1 des MIO16 ein- auschalten!
CCU-B ohne Netz neu gestartet > gewartet, bis die piVCCU oben war..
Programm funktioniert - Aktor schaltet.
CCU-B herunter gefahren

CCU-A ohne Netz neu gestartet > gewartet, bis die piVCCU oben war.
Programm funktioniert - Aktor schaltet.

Für solche Tests sollte man sich ein Full-Stretch installieren, damit man sieht, was im UI geschieht.

Dann wurde ich dreist:
der CCU-B eine andere IP verpasst
CCU-A und CCU-B den INet-Zugriff untersagt
CCU-A und CCU-B ins Netz gehängt und neu gestartet:
Ich konnte den MIO16 jeweils von der CCU schalten, in deren Funkreichweite er sich gerade befand!

Ich wüsste auch nicht, warum und welches 'Rekeying' nach dem 1. Neustart noch stattfinden sollte.
Denn das ist doch wimre ein Akt zwischen CCU und INet und nicht zwischen Gerät und INet.


Übrigens scheint das ein neues Feature beim Restore zu sein:

Restore-Error.JPG (22.98 KiB) 1512 mal betrachtet

Die Meldung kam bei mir vorhin auch, obwohl die CCU zu dem Zeitpunkt noch ins INet konnte und durfte.
/Edith:
Das nehme ich zurück und behaupte das Gegenteil:
Die Basis-CCU, auf die ich das Backup zurückgelesen hatte, durfte - wie fast alle meine CCUen - nicht!

[zautrix]

Hab's nachgestellt - und wie ich mir schon dachte bestätigt es meine Annahme und widerspricht dem was Du schriebst. Ohne Internet kein Rekeying - ohne Rekeying keine HmIP-Devices. Hier der genaue Ablauf:
...

Ja, so habe ich das im Prinzip ja auch gemacht.

Keine Ahnung was Du da für Magic betrieben hast, folgende Vermutung drängt sich mir auf: Du hast die Verbindung zum Keyserver nicht wirklich unterbunden. Auf welche Art und Weise hast Du denn die Internetverbindung "gekappt"?

War die wirklich schon vor dem Boot unterbunden?

Definitiv.
Wie oben geschrieben habe ich die Verbing ganz am Anfang gekappt, bevor ich A ausgeschaltet habe.
Durch ziehen des Steckers der DSL Leitung. Weniger Internet geht nicht. Die CCU A hat auch dann bald (vor dem Ausschalten) den "No Internet" Alarm gezeigt.

Wenn das was Du da schreibst funktionieren würde hättest Du (jedenfalls soweit ich das HmIP-Protokoll richtig verstehe) eine Sicherheitslücke entdeckt, das darf imho nicht funktionieren.

Mit meinen Systemen funktioniert es.
Ausgeschaltet ist ausgeschaltet. Eingeschaltet ist eingeschaltet. Und DSL Leitung unterbrochen ist kein Internet. Da kann man nicht viel verkehrt machen.

Nichts desto trotz: man kann das natürlich schon so machen - aber das Re-Keying muss stattfinden wenn das Funkmodul und damit der NWK ein anderer ist, der Keyserver muss erreichbar sein, sonst ist HmIP tot.

Du kannst es so viel wiederholen, wie Du möchtest. Es mag für dein Testsystem stimmen. Für mein Produktivsystem stimmt es nicht.

Ich möchte Dir auf jeden Fall für deine Testreihe danken. Es wäre schon interessant, wo da nun der Unterschied ist.

Bei Gelegenheit werde ich da mal bei mir weiter forschen.
Mein System und dein Testsystem sind ja nicht identisch. Irgendwo müsste da ja etwas sein, das den Unterschied ausmacht.
Ob nun Bug oder Feature ist mir egal. Ich finde es cool, dass ich meine Zentrale sogar ohne Internetverbindung wechseln kann.
Und ich habe gar kein Interesse daran, dass eq3 eventuell diese Sicherheitslücke behebt.
Deswegen wird von meiner Seite auch keine Info mehr zu diesem Thema kommen.
Von mir aus können zu diesem Thema alle glauben, was sie wollen.

[Sammy]

Ist der Unterschied evtl. dass bei zautrix das 2. System mind. 1x Internet für das Rekeying hatte? (Eventuell also auch vor dem gezeigten Test)
Und hobbyquaker hat das 2. System noch nie mit dem Internet verbunden gehabt?

[hobbyquaker]

Hmm spannend, weckt auf jeden Fall weiterhin meine Neugier. Könnte natürlich sein dass ich irgendwas verbockt hab bei dem Test oder ein anderer Fehler reingespielt hat der dann dazu führte dass die HmIP Geräte weg waren. Werd's irgendwann mal noch weiter erforschen

Ich wüsste auch nicht, warum und welches 'Rekeying' nach dem 1. Neustart noch stattfinden sollte.
Denn das ist doch wimre ein Akt zwischen CCU und INet und nicht zwischen Gerät und INet.

Soweit ich das richtig verstehe (ohne Gewähr!) findet beim Rekeying eine Reinclusion der Geräte zum crRFD/hmipserver statt, bei der der Keyserver mit dem DLK (Device Local Key, der der auf den Aufklebern steht und im QR-Code codiert ist und vom crRFD in der Device Persistenz gespeichert wird) - und vermutlich irgendeinem weiteren Secret - den CoPro anweist den neuen NWK zu errechnen, der dann an alle Aktoren übertragen werden muss. Es ist also (glaube/vermute ich, reime ich mir zusammen ) ein Zusammenspiel von crRFD, KeyServer und den Geräten.

Daimlers Beobachtung wirft das allerdings alles über den Haufen und lässt mich stark daran zweifeln dass ich das richtig verstehe, auch da denk ich mir: das darf doch eigentlich nicht funktionieren, irgendwo hab ich da befürchte ich ein großes Missverständnis in meinen Überlegungen

[Daimler]

Hi,

es ist ja letztendlich egal, ob CCU-B nun beim 1. Neustart nach dem Restore aus CCU-A ins INet kam oder nicht.
Es scheint jedenfalls bewiesen zu sein, dass sich auch HMIP-Geräte per Backup / Restore an 2 CCUen betreiben lassen.
Und darum ging es ja hier im Fred.

Wobei auch ich während meines 3.47.22er Kampfes:
viewtopic.php?f=26&t=54963&start=20#p550551
die Erfahrung gemacht hatte, dass hier beim 1. Neustart nach dem Restore eine INet Verbindung von Nöten ist / war.
Hatte an einer CCU vergessen, das Kabel einzustecken und wollte schon losschreien, weil keine IP-Geräte vorhanden waren.
Aber nach dem zur Beruhigung genehmigten Bierchen fiel es mir dann wie Schuppen von den Augen.

Und hier

Es ist also (glaube/vermute ich, reime ich mir zusammen ) ein Zusammenspiel von crRFD, KeyServer und den Geräten.

- den Satz davor will ich jetzt lieber nicht zitieren
stellt sich mir zum. bei einer HmIP-KRC4 die Frage, wie das funktionieren soll.
Oder ist die - im Gegensatz zur HM-Mutter - WoR und demit 'Rekeying' -fähig.

Denn das man zum späteren Betrieb der HM(IP)(W)-Welt kein INet benötigt (NTP nat. auf lokal gestellt!) ist wohl unstrittig.

[hobbyquaker]

Ich glaub ich hab rausgefunden wo mein Missverständnis lag. Ich ging immer davon aus der NWK sei nur auf dem CoPro gespeichert und könne nicht ausgelesen werden. Das ist falsch. Der Networkkey steckt (verschlüsselt) in der /etc/config/crRFD/data/<AP-SGTIN>.apkx und wandert somit beim Backup mit auf die andere CCU, in der .apkx gibt es auch Properties für einen NWK und einen NWK2, vielleicht hat eQ-3 da für genau diesen Fall eine Art Fallback-NWK implementiert, es ist in dem Fall also glaube ich gar kein Rekeying nötig. Die Logmeldungen beim Start der "CCU-B" habe ich dahingehend wohl auch falsch interpretiert.

Fraglich warum eQ-3 dann das Einspielen eines Backups verweigert wenn der Keyserver nicht erreichbar ist, ganz klar ist mir die ganze Sache noch nicht, da gibt's noch Ungereimtheiten. Werde bei Gelegenheit mal jemand fragen der sich mit dem HmIP-Protokoll wirklich auskennt.

Und auch fraglich warum dann meine "CCU-B" bei meinem Test ihre HmIP-Devices verloren hat, aber das hatte dann vielleicht einfach eine andere Ursache die mit dem ganzen Thema gar nichts zu tun hat.

stellt sich mir zum. bei einer HmIP-KRC4 die Frage, wie das funktionieren soll.
Oder ist die - im Gegensatz zur HM-Mutter - WoR und demit 'Rekeying' -fähig.

Config-Listener erhalten das Rekeying wenn sie sich das nächste mal von sich aus melden. Burst-Listener werden (vermute ich) einfach aufgeweckt.