Keine Kommunikation mit HmIP-Geräten nach Zentralen-Update / Reboot... User-Hilfe benötigt

[jp112sdl]

was das ganze _ueberhaupt_ soll

Aus Architektur-Sicht könnte ich mir mindestens zwei sinnvolle Funktion vorstellen: Replay Schutz und Teil der Verschlüsselung.
Es ist dadurch einem Angreifer nicht möglich, ein altes, mitgehörtes Funkpaket erneut auszusenden.

Bei BidCos gibt es da "nur" den 1 Byte großen über- bzw. umlaufenden MessageCounter. Da wird nur geprüft, ob eine empfangene Nachricht denselben Counter hat, wie die zuletzt empfangene und dann verworfen. Alles andere geht durch.

[jmaus]

Ist auch eine geniale Design Entscheidung einen Zähler in 32bit und den anderen in 64bit anzulegen. Und das ganz ohne KI.

Naja, die Motivation dahinter ist/war sicherlich einfach erkennen zu können das der 32bit counter in den geräten übergelaufen ist. Da brauch man dann halt einen 64bit counter damit man merkt wenn das > 2^32 wird...

[jmaus]

was das ganze _ueberhaupt_ soll

Aus Architektur-Sicht könnte ich mir mindestens zwei sinnvolle Funktion vorstellen: Replay Schutz und Teil der Verschlüsselung.
Es ist dadurch einem Angreifer nicht möglich, ein altes, mitgehörtes Funkpaket erneut auszusenden.

Genau das ist die Motivation hinter dem Security Counter. Sonst kann jemand einfach lauschen und die verschlüsselten Pakete einfach erneut an die Geräte schicken und die würde nicht mitbekommen das die nicht von der eigentlichen CCU kommen...

[schneider.obw]

Wäre natürlich schön ein betroffener (wenn die kommunikation nicht geht) würde das mal mit "status" aufrufen und hier die Ausgabe zeigen ... und dann auch mal probieren mit "repair" deine ap datei korrigieren zu lassen.

Aus meinem letzten Update hatte ich ja noch 2 HMIP-Geräte im Comms-error.
Mittlerweile habe ich das Nightly-Build vom 3.10. eingespielt, und auf dieser Basis jetzt auch mal das Repair-Script von Jens angewandt.
Das Script erklärt sich mit seinen 3 Optionen von selbst und die erste Statusüberprüfung gab folgende Rückmeldung:

Code: Alles auswählen

root@HOMEMATIC:/tmp# checkHmIPsecurityCounter.sh
3014F711A0001F58A9A7171B.ap:
  firstConnect: 2016-05-05 17:24:08
  offset:       3409771262
  calculation:  4504970712 (sent as 210003416)
  state:        ERROR: security counter already wrapped.
                If HmIP devices are unreachable, power cycle them or run
                '/bin/checkHmIPsecurityCounter.sh repair' and reboot the system.
root@HOMEMATIC:/tmp#

Und nach einem Reboot senden die Geräte dann auch wieder Daten und der Comms-Errot taucht nicht mehr auf 8auch nach entsprechender Wartezeit.

Die Rückmeldung nach erneutem Aufruf des Scripts ergibt:

Code: Alles auswählen

root@HOMEMATIC:/tmp# checkHmIPsecurityCounter.sh
3014F711A0001F58A9A7171B.ap:
  firstConnect: 2016-05-05 17:24:08
  offset:       2324570859
  calculation:  3419772139 (79% of 2^32)
  state:        OK, 32 bit limit in ~8.3 years (2035-01-28)
root@HOMEMATIC:/tmp#

Wobei mir unklar ist, auf welcher Basis das angegebene Zeitlimit errechnet wird?
Ist es das HMIP-Gerät mit dem höchsten Counter?
Oder ist es einfach nur ein Counter in der CCU als Grundlage für die Berechnung.
(In einem anderen Test von Baxxy hier hatte ich ein Zeitlimit von fast 40 Jahren gesehen.)
Aber zugegebenermaßen habe ich das Konzept auch nicht vollständig verstanden.
Muss ich aber auch nicht; mir ist eine einfache und möglichst saubere Lösung wichtiger.

Und falls mein Test hier eine Hilfe sein kann, noch folgende Info:
Die beiden Geräte im Comms-Error waren ein Temperatursensor HmIP-STE2-PCB sowie ein Fensterkontakt HmIP-SWDO-I (benutzt als Briefkastenmelder), also alles Batteriegeräte, die ich mit dem Script nun ohne stromlos machen wieder in Kommunikation bringen konnte.
Fünf weitere HMIP-Geräte aus dem Reboot-Fehler hatte ich schon durch stromlos setzen vor ein paar Tagen wieder zurückgeholt.
Wobei nicht alle in den Comms-Error gegangen sind.

Schönen Feiertag wünsche ich.
schneider.obw

[joerg_rw]

Genau das ist die Motivation hinter dem Security Counter. Sonst kann jemand einfach lauschen und die verschlüsselten Pakete einfach erneut an die Geräte schicken und die würde nicht mitbekommen das die nicht von der eigentlichen CCU kommen...

Dann sollte man den SecurityCounter aber bei jedem ausgesendeten Paket auf den aktuellen Stand hochzaehlen.
Soweit ich das verstehe und von anderen Leuten als "in AskSinAnalyzer so gesehen" angedeutet wurde, wird der Counter aber wohl nie geaendert ausser beim Reboot.
Dann haette ein Angreifer monatelang Zeit fuer eine Replay Attacke.

Ist der SecurityCounter identisch mit dem "Telegrammzaehler" in diesem PowerPoint Bild? Obwohl der ja nur 8Bit zu sein scheint, wenn man annimmt dass da ueberhaupt Wert auf Genauigkeit bei solchen Details gelegt wurde.

bzw natuerlich fuer HmIP dann "Cyclic Counter" - auch gelb, auch 8Bit

[aus: © eQ-3, 2018 // Homematic & homematic IP // Timing der Funkprotokolle // Staffelung der Telegramme -- Grundlagen der Funkprotokolle verstehen und Erkenntnisse sinnvoll nutzen. /// Frank Graß,]
Waere zu schoen wenn ich ein Video des Vortrags finden koennte, oder was aehnliches. Die PP-slides sind nicht wirklich hinreichend um das ganze zu durchschauen. Hat jemand links fuer mich?

[zahnheinrich]

Ich habe eben meine 3 Installationen (alle mit aktueller fw 3.89.11.20260919) geprüft, 2 sind ok (VM auf Proxmox), die dritte auf einem raspberry zeigt das berüchtigte Problem:

Code: Alles auswählen

root@CUXccu2:~# sh /tmp/checkHmIPsecurityCounter.sh
3014F711A061A7D5698CED84.ap:
  firstConnect: 2014-07-01 00:00:00
  offset:       3895648509
  calculation:  5186129546 (sent as 891162250)
  state:        ERROR: security counter already wrapped.
                Repair requested, it is applied at the next system reboot.

Auch nach

Code: Alles auswählen

root@CUXccu2:~# sh /tmp/checkHmIPsecurityCounter.sh repair
Repair of the HmIP security counter requested. Please reboot the system to apply it.

ändert sich nach (wiederholtem) reboot nichts, die Fehleranzeige bleibt gleich.
Was kann ich versuchen?

VG Ulrich

[jmaus]

Ich habe eben meine 3 Installationen (alle mit aktueller fw 3.89.11.20260919) geprüft, 2 sind ok (VM auf Proxmox), die dritte auf einem raspberry zeigt das berüchtigte Problem:

[...]

Auch nach

Code: Alles auswählen

root@CUXccu2:~# sh /tmp/checkHmIPsecurityCounter.sh repair
Repair of the HmIP security counter requested. Please reboot the system to apply it.

ändert sich nach (wiederholtem) reboot nichts, die Fehleranzeige bleibt gleich.
Was kann ich versuchen?

Hast du denn überhaupt ein Problem mit der Kommunikation mit HmIP Geräten oder hast du den Skript einfach ausgeführt auch ohne das du praktische Kommunikationsprobleme mit HmIP Geräten hast?

[zahnheinrich]

Ich habe in der Tat seit längerem ein com Problem.
Betroffen sind ein HmIP-SWSD sowie ein HmIP-FDT.

Ulrich

[jmaus]

Ich habe in der Tat seit längerem ein com Problem.
Betroffen sind ein HmIP-SWSD sowie ein HmIP-FDT.

Hier geht es nicht um Kommunikationsprobleme zu EINZELNEN Geräten. Das hier diskutierte und teilweise gelöste Problem betrifft die gesamte HmIP Kommunikation. Also wenn andere HmIP Geräte bei dir/jemanden gehen und nur einzelne nicht hat es mit diesem Problem hier absolut nix zu tun.

[zahnheinrich]

Das habe ich verstanden.
Die beiden genannten sind die einzigen HMIP Geräte im HM Netz, alle andere "alte" Geräte (>15) laufen konstant ohne Störungen.