Implementierung der ZWAVE Command Class SECURITY (0x98, AES Verschlüsselung)

Begonnen von A.Harrenberg, 27 Juni 2015, 21:25:37

Vorheriges Thema - Nächstes Thema

krikan

Zitat von: rudolfkoenig am 26 Oktober 2015, 11:45:47
Kann mir jemand einen Aktor empfehlen, was SECURITY kann? Muss nicht superteuer sein.
Probiere vielleicht mal, ob AEOTEC Dich mit Mustern versorgt: http://aeotec.com/z-wave-gateways (unter Z-Wave gateway program).
Openzwave bekommt die wohl und warum dann nicht auch wir. Nennung von Fhem auf der Seite wäre auch OK. Selbst openhab wird schon gelistet und die können mMn noch überhaupt kein SECURITY...

A.Harrenberg

Hi Rudi
Zitat von: rudolfkoenig am 26 Oktober 2015, 11:45:47
@Andreas: keine Hektik. Deine CANs sind in meinen Augen noch kein Beweis, evtl. haengt das auch mit deinem USB-Stick zusammen.
ich will da auch keine Hektik machen. Mag sein das es mit dem Stick zusammenhängt, ich sehe es aber eher als eine Grundeigenschaft der Gerätekommunikation. Es kann mMn immer nur EINE aktive Kommunikation geben. Ich muss mir den Pätz da noch mal ansehen, ich denke das er das auch irgendwo so beschrieben hatte.

Wie dem auch sei, das unkoordinierte Senden ist auf jeden Fall mindestens "unschön" und sollte vermieden werden.

Zitat von: rudolfkoenig am 26 Oktober 2015, 11:45:47
Ich glaube das musst du mir ganz detailliert aufmalen. Nach meinem Verstaendnis kollidiert das naemlich mit deiner CAN Theorie: zwei Nachrichten in parallel kann (dein? / der) Kontroller nicht ab, ID hin oder her.
Das  kollidiert nicht mit meiner Theorie, zumindest nicht in meinem Kopf ,-)
Fallbeispiel:
Get-Befehl auf Sensor:
1. GET-Nonce wird gesendet
2. Gerät antworten mit NONCE-REPORT
3. verschlüsselter Get-Befehl wird gesendet
4. Gerät schickt GET-NONCE
5. NONCE-REPORT wird verschickt
6. Gerät verschickt verschlüsselten Report

Falls nun während der Kommunikation z.B. ein Bewegungsmelder eine Bewegung meldet, muss dazu als erstes eine Nonce angefordert werden -> Gerät schickt GET-NONCE.
Falls das nun (zufällig) zwischen Schritt 3. und Schritt 4. passiert ist nicht klar ob der GET-NONCE Befehl zu der laufenden Kommunikation gehört oder eine neue Anfrage ist.

Das wird sicherlich nicht sehr oft vorkommen würde aber nach meinem momentanen Verständnis dazu führen das die laufende Kommunikation verloren geht.

Zitat von: rudolfkoenig am 26 Oktober 2015, 11:45:47
Kann mir jemand einen Aktor empfehlen, was SECURITY kann? Muss nicht superteuer sein.
Ich habe da leider auch nur die Sirene, und die ist nur bedingt zum "Ausprobieren" geeignet... Ansonsten habe ich diesen 6fach Sensor von AEOTEC, ist aber eben kein Aktor.

Ich würde insgesamt aber vorschlagen das ich mir die potenziell möglichen Abläufe mal in Ruhe aufmale und dann schaue was sich da als Steuerung für den Stack realisieren lässt. Ich denke schon das sich da eine Lösung finden lässt.

Gruß,
Andreas.
FB 7360, Homematic und ZWave
Support for ZWave-SECURITY

rudolfkoenig

ZitatProbiere vielleicht mal, ob AEOTEC Dich mit Mustern versorgt:
Habs probiert, warten wir mal ab.

@Andreas: ja, das habe ich auch so verstanden. Allerdings wuerde mich wundern, wenn das, was du beschreibst, funktioniert, aber eine nur leicht andersartige parallele Kommmunikation (wg. CAN) nicht.
Oder auch: wo ist das Unterschied zwischen Antwort auf Frage vs. freiwillige Meldung von Daten.

Aber ich sehe ein, das wir in diesem Fall eine bessere CallbackId-Vergabe brauchen wuerden :)

A.Harrenberg

Hi Rudi,
Zitat von: rudolfkoenig am 26 Oktober 2015, 13:32:29
@Andreas: ja, das habe ich auch so verstanden. Allerdings wuerde mich wundern, wenn das, was du beschreibst, funktioniert, aber eine nur leicht andersartige parallele Kommmunikation (wg. CAN) nicht.
Oder auch: wo ist das Unterschied zwischen Antwort auf Frage vs. freiwillige Meldung von Daten.
Das würde auch nicht funktionieren, eigentlich müsste da ja dann von FHEM ein CAN erzeugt werden... (oder die Kommunikation müsste noch mal gestartet werden)
Aber das ist erst mal recht unwahrscheinlich, daher würde ich das auch erst mal außen vor lassen.

Unterschied zwischen Frage-Antwort und Meldung von Daten gibt es eigentlich nicht, außer das Gerät meint genau zwischen Frage-Antwort lieber eine Meldung statt der ausstehenden Antwort zu schicken. Was ja durchaus eine Frage der Priorität ist und daher gerechtfertigt sein kann. Ich meine das damals in Logfiles von Krikan gesehen zu haben. Damals gingen die Nachrichten aber noch mehr durcheinander...

Gruß,
Andreas.

FB 7360, Homematic und ZWave
Support for ZWave-SECURITY

rudolfkoenig

@Christian: Aeon Labs wollen mir einen Zwischenstecker schicken, und der Zustaendige wollte wissen, wo man sich bei Pepper beschwert, weil deren Angaben ueber die Security-Klassen falsch sind. Hast du eine Idee?

Btw. auch die openzwave config Eintraege (aeon/ss6.xml) sind laut den Produkt-Beiblatt falsch, aber das korriegiere ich erst, wenn ich das verifizieren kann.

krikan

Zitatund der Zustaendige wollte wissen, wo man sich bei Pepper beschwert, weil deren Angaben ueber die Security-Klassen falsch sind. Hast du eine Idee?
Nicht wirklich, nur Standard(not)lösung: http://www.pepper1.net/en/contact .

Submitter des Eintrages bei pepper1 ist mWn Dr. Christian Paetz himself und die Einträge bei ozw (aeon/ss6.xml) sind vom ozw-Hauptentwickler Justin Hammond , der von AEOTEC auch u.a. den Zwischenstecker bekommen hat. Sind die Abweichungen evtl. gleich und AEOTEC hat nur einen neue Version herausgebracht?

rudolfkoenig

Unwahrscheinlich:
- in pepper sind in der security Spalte die Klassen aufgefuehrt, die bei secure inclusion ohne security nutzbar sind
- in deviceconfig ist einmal hex mit dezimal verwechselt (14 vs 20), und bei der Farbkonfiguration sind 4 Items definiert mit den Werten 1-4 fuer none/red/green/blue, richtig waere mAn ein long, mit byte2=red, byte3=green, byte4=blue. Die anderen habe ich nicht geprueft.

krikan

Zitat von: rudolfkoenig am 29 Oktober 2015, 15:01:17
- in deviceconfig ist einmal hex mit dezimal verwechselt (14 vs 20), und bei der Farbkonfiguration sind 4 Items definiert mit den Werten 1-4 fuer none/red/green/blue, richtig waere mAn ein long, mit byte2=red, byte3=green, byte4=blue. Die anderen habe ich nicht geprueft.
Dann sollte ich mal schauen, dass ich endlich mal Korrekturen an ozw liefern kann...

@Andreas: Logs kommen noch; hoffe ich schaffe es heute.

A.Harrenberg

Hi Krikan,

keine Panik mit den Logs, habe gerade 4 Tage full-time Kundenmeeting hinter mir, mein Firmenlaptop ist abgeraucht und meine DSL-Leitung zu Hause hat(te) sich verabschiedet... Seit heute mittag läuft die zwar wieder, allerdings nur mit 6Mbit...

Ich hab' also eh frühestens am Sonntag Zeit dazu.

Gruß,
Andreas.
FB 7360, Homematic und ZWave
Support for ZWave-SECURITY

A.Harrenberg

Hi Rudi,

in den Funktionen für ConfigRequestAll und AssociationRequest wurden bislang noch ZWave_CMD ("set", ...) Aufrufe verwendet, mMn müssten dort auch ZWave_Set verwendet werden, da die Befehle ansonsten an dem neuen Stack vorbei laufen...
Kleinen Patch habe ich angehängt.

Auch mit dieser Änderungen gehen bei dem 6fach Sensor immer noch 4 config-Requests wegen CAN + Timeout verloren. Ohne die Änderungen waren es sogar noch mehr...

Ablauf schaue ich mir jetzt auch noch mal genauer an.

Gruß,
Andreas.
FB 7360, Homematic und ZWave
Support for ZWave-SECURITY

rudolfkoenig


A.Harrenberg

Hi Rudi,
Zitat von: rudolfkoenig am 31 Oktober 2015, 14:58:37
Habs eingecheckt.
danke, ich habe noch einen kleinen Patch angehängt. Der sorgt normalerweise dafür das bei GET-Befehlen secEND nicht vorzeitig aufgerufen wird.

Hier habe ich allerdings eine Frage/Problem:
Ist es zwingend nötig die Befehle aus "ConfigRequestAll" als SET-Befehle zu senden? Das führt nämlich dazu das hier das secEnd zu früh ausgelöst wird und dann die Befehle doch durcheinander geraten.

Ich habe die Struktur, wie diese Befehle erzeugt werden, noch nicht so ganz durchschaut, bevor ich daran rumschraube wollte ich lieber mal erst mal fragen ob das einen "guten" Grund hat.

Damit das mit der Steuerung für Security funktionieren kann, muss die Zuordnung der Befehle zu  SET bzw. GET stimmen...

Gruß,
Andreas.
FB 7360, Homematic und ZWave
Support for ZWave-SECURITY

A.Harrenberg

Hallo Rudi,

wenn ich zu Testzwcken einfach mal ganz stumpf den "type" auf get ändere falls $cfgReq gesetzt ist, dann läuft die Kommunikation störungsfrei durch. Ich kann dann bei dem Multisensor6 ein ConfigRequestAll durchlaufen lassen ohne das es zu Datenverlust, CAN oder Time-Out kommt.

Ich werde das nachher auch noch mal als WakeUp probieren, sehe da aber keinen prinzipiellen Unterschied.

  # Collect the commands from the distinct classes
  my %cmdList;
  my $classes = AttrVal($name, "classes", "");
  my $cfgReq = ($type eq "set" && $cmd =~ m/^config/ && @a && $a[0] eq "request");
  shift(@a) if($cfgReq);
  foreach my $cl (split(" ", $classes)) {
    my $ptr = ZWave_getHash($hash, $cl, $cfgReq ? "get" : $type);
    next if(!$ptr);

    foreach my $k (keys %{$ptr}) {
      if(!$cmdList{$k}) {
        $cmdList{$k}{fmt} = $ptr->{$k};
        $cmdList{$k}{id}  = $zwave_class{$cl}{id};
      }
    }
  }
  my $c=$cfgReq ? "1" : "0";
  Log3 $name, 5, "$name: cfgReq=$c type=$type";
  Log3 $name, 5, "$name: cmd=$cmd";
  if ($cfgReq) {
    $type="get";
  }


Gruß,
Andreas.
FB 7360, Homematic und ZWave
Support for ZWave-SECURITY

A.Harrenberg

Hi,
Zitat von: A.Harrenberg am 01 November 2015, 11:11:42
Ich werde das nachher auch noch mal als WakeUp probieren, sehe da aber keinen prinzipiellen Unterschied.
den Kommentar muss ich leider zurücknehmen. Das System verklemmt sich irgendwie und es wird nur der erste (oder die ersten beiden?) Befehle abgearbeitet. Danach passiert erst mal gar nichts mehr ,-(

Da muss ich wohl etwas genauer analysieren...

Gruß,
Andreas.
FB 7360, Homematic und ZWave
Support for ZWave-SECURITY

rudolfkoenig