Merkwürdigkeit bei "get VersionClassAll" und SECURITY

[A.Harrenberg]

Hi Rudi,

ich habe gerade testweise bei dem Z-Uno mal Security eingeschaltet und der verhält sich dann etwas merkwürdig. Zum einen schaltet er pauschal für ALLE Klassen Security an, bietet die Klassen aber anscheinend weiterhin auch unverschlüsselt an... Das muss ich mal bei den Entwicklern anmeckern...

Die Merkwürdigkeit bei get VersionClassAll ist nun das NUR Association in vclasses eingetrgen wird, die anderen Klassen aber nur als Reading (mit Zahlen statt Klassennamen)angelegt werden...

Code Auswählen Erweitern

Internals:
   CFGFN
   DEF        e015dfed 20
   IODev      ZWDongle_0
   LASTInputDev ZWDongle_0
   MSGCNT     49
   NAME       ZWave_SWITCH_MULTILEVEL_20
   NR         163
   STATE      dim 9
   TYPE       ZWave
   ZWDongle_0_MSGCNT 49
   ZWDongle_0_RAWMSG 000400141898810857d4e18b0b87983f54a06f0a13226e7d49dbe6474d
   ZWDongle_0_TIME 2016-09-18 16:15:04
   ZWaveSubDevice no
   homeId     e015dfed
   isWakeUp
   lastMsgSent 1474208104.06152
   nodeIdHex  14
   secTime    1474208104.06146
   Readings:
     2016-09-18 16:06:37   SECURITY        ENABLED
     2016-09-18 16:06:42   mcCapability_01 SWITCH_MULTILEVEL
     2016-09-18 16:06:41   mcEndpoints     total 1, different
     2016-09-18 16:06:42   model           Z-Wave.Me Z-Uno
     2016-09-18 16:06:42   modelConfig     zwave.me/ZUno.xml
     2016-09-18 16:06:42   modelId         0115-0110-0001
     2016-09-18 16:11:06   reportedState   dim 9
     2016-09-18 16:11:06   state           dim 9
     2016-09-18 16:15:04   timeToAck       0.047
     2016-09-18 16:15:04   transmit        OK
     2016-09-18 16:15:04   versionClass_112 1
     2016-09-18 16:07:44   versionClass_114 2
     2016-09-18 16:07:45   versionClass_115 1
     2016-09-18 16:07:44   versionClass_122 3
     2016-09-18 16:07:46   versionClass_134 2
     2016-09-18 16:07:44   versionClass_142 3
     2016-09-18 16:07:45   versionClass_152 1
     2016-09-18 16:07:43   versionClass_32 1
     2016-09-18 16:07:45   versionClass_38 1
     2016-09-18 16:07:42   versionClass_89 1
     2016-09-18 16:07:43   versionClass_90 1
     2016-09-18 16:07:46   versionClass_94 2
     2016-09-18 16:07:44   versionClass_96 4
   secMsg:
Attributes:
   IODev      ZWDongle_0
   classes    ZWAVEPLUS_INFO BASIC SWITCH_MULTILEVEL CONFIGURATION ASSOCIATION MULTI_CHANNEL_ASSOCIATION MULTI_CHANNEL FIRMWARE_UPDATE_MD DEVICE_RESET_LOCALLY ASSOCIATION_GRP_INFO POWERLEVEL SECURITY VERSION MANUFACTURER_SPECIFIC
   room       ZWave
   secure_classes ZWAVEPLUS_INFO SWITCH_MULTILEVEL CONFIGURATION MULTI_CHANNEL_ASSOCIATION ASSOCIATION_GRP_INFO ASSOCIATION VERSION MANUFACTURER_SPECIFIC MULTI_CHANNEL
   vclasses   ASSOCIATION:2

Kann es sein das Du die Befehle für die Versionsabfrage "selbst" generierst und nicht über ZWave_get erzeugst? In dem Fall würdest Du mMn. unverschlüsselt senden, die verschlüsselte Antwort würdest Du aber nicht erwarten (ich habe ein paar parse_hooks in der Funktion gesehen), die würde dann "normal" decodiert werden und wahrscheinlich nicht mehr in Deiner Funktion ankommen.

Logfile kann ich zur Verfügung stellen falls nötig, ich schau mir das aber auch noch mal an ob meine erste Vermutung überhaupt sein kann...

Gruß,
Andreas.

[A.Harrenberg]

Hallo Rudi,

also ich begreife nicht was da passiert. Ich begreife aber auch nicht wie das ohne SECURITY funktionieren kann...

In ZWave_versionClassAllGet wird in einer Schleife für alle Einträge im Attribut classes mittels ZWave_Get ein "get versionClass" ausgelöst und erst DANACH der Hook gesetzt.

Interessanterweise wird in ZWave_versionClassGet dieser Hook als erstes wieder gelöscht...

Ich würde nun erwarten das der erste Befehl aus der Schleife nun den Hook löscht und die nachfolgenden Antworten dann alle normal geparst werden und in den Readings landen, solange bis die Schleife abgearbeitet ist und dann der Hook wieder einmal gesetzt wird.
Das entspricht dann so ungefähr dem was bei mir gerade mit SECURITY passiert.

Meiner Meinung nach müsste das aber auch genauso immer passieren, ich sehe da nicht wieso es einen Unterschied macht wenn die Klasse verschlüsselt aufgerufen wird. Die entschlüsselte Antwort auf die Versionsabfrage schicke ich per "ZWave_Parse($iodev, $decryptedCmd, undef)" wieder los, d.h. das durchläuft auch die Stelle an der der parseHook greifen sollte, aber irgendwie geht der Hook verloren...

Verwirrte Grüße,
Andreas.

[A.Harrenberg]

Hallo Rudi,

kann es sein das es nur funktioniert wenn alle Einträge per ZWave_get geschrieben wurden und der Hook gesetzt wurde BEVOR die erste Antwort eintrifft?

Hier dauert das ZWave_get bei Security ja etwas länger und der normale Stack wird beim ersten Befehl ja schon angehalten (secInProgress....), was den Ablauf leicht verändert.

Immer noch verwirrt,
Andreas.

[A.Harrenberg]

Hallo Rudi,

ich habe mir das jetzt noch mal "non-secure" angesehen und das läuft anscheinend wirklich so das alle get auf dem Stack landen, der erste Befehl "unterwegs" ist und dann der Hook gesetzt wird und sich dann ab da immer wieder setzt. Irgendwie unschön...

Ich bräuchte jetzt mal wieder einen kleinen Schubs in die richtige Richtung. Wie kann ich denn z.B. bei "versionClass" feststellen ob ich normal aus dem Menü aufgerufen wurde oder intern über ZWave_Get()?

Meine Versuche hier mit optionalen Parametern zu arbeiten sind bisher leider grandios gescheitert, ich schaffe es nicht beim "ZWave_Get($hash, $name, "versionClass", $c);" irgendwas anzugeben was ich nachher in der Funktion ZWave_versionClassGet($$) ankommt und ausgewertet werden kann um dort das "delete $zwave_parseHook{"$hash->{nodeIdHex}:..8614"};" zu unterdrücken...

Gruß,
Andreas.

[rudolfkoenig]

Sorry, dass ich dich so lange warten liess, ich tendiere dazu, (gefuehlt) komplexe Aufgaben auf die lange Bank zu schieben.

Ich verstehe (nach etwas Code-Durchsicht) z.Zt. weder das Problem (das Verfahren sollte auch bei SECURITY greifen), noch deinen Loesungsvorschlag.

- versionClassAllGet setzt eine Liste von get version ab, und anschliessend den parseHook. Irgendwann spaeter kommen die Antworten (get ist ja nicht blockierend), und egal ob verschluesselt oder nicht, werden sie durch ZWave_Parse analysiert (ZWave_secDecrypt ruft ja auch ZWave_Parse auf), und sollten mit dem parseHook erwischt werden, der das Attribut setzt. Habe ich was uebersehen? Ist Secure-Get noch blockierend?

- Alle Fhem-Befehle kriegen ein $cl Parameter, womit man das Eingabekanal (z.Zt. nur telnet/FHEMWEB/keins) identifizieren kann. Leider gibt Command_Set/Get das an SetFn/GetFn nicht als Parameter weiter. Um die API nicht zu aendern, wird seit ca 6Monaten $hash->{CL} gesetzt fuer die SetFn/GetFn aufrufe. D.h. wenn du in $hash ein CL vorfindest, dann hat man die Funktion interaktiv aufgerufen. Im ZWave_Cmd wird in so einem Fall fall bei get $asyncGet gesetzt, und falls die Antwort eintrifft, via asyncOutput der Aufrufer benachrichtigt. Ich meine, dass diese Behandlung bei diesem Problem nicht notwendig ist.

[A.Harrenberg]

Hallo Rudi,

puh, das waren jetzt eine Menge Informationen die ich erst mal nachvollziehen muss.

Ob secure-get blockierend ist kann ich so nicht sagen, der Ablauf deutlich anders ist wäre das zumindest möglich. Ich schau mir die von Dir genannten Sachen mal an und versuche nachzuvollziehen was hier anders ist.

Gruß,
Andreas.

P.S.: Und das mit dem verschieben von Aufgaben kenne ich aus eigener Praxis ,-)

[A.Harrenberg]

Hi Rudi,

das mit $cl / $hash->{CL} habe ich mir jetzt noch nicht angesehen aber was passiert ist ja anscheind folgendes:

Im Fall non-secure werden alle "get" Befehle (die ja intern den Hook löschen) nacheinander geparst und auf den Sendstack gelegt. Dann erst kommt wird der parseHook gesetzt und alles ist schön... ,-)

Im Fall secure gibt es aber das "secInProgress"... Hier wird jetzt der erste get geparst, dann "abgefangen" und auf meinen security stack gelegt bis die angeforderte Nonce ankommt. Bis die Nonce ankommt ist jetzt secInProgress aktiv und die weiteren "get versionClass" werden ungeparst auf den $hash->{secStack} gelegt. In der Zwischenzeit wird dann einmalig der ParseHook gesetzt.

Das Problem ist das nun nachdem die erste Antwort eingetroffen ist der nächste "get versionClass" geparst wird -> Der Hook wird gelöscht und ab da werden die Antworten als Reading eingetragen und nicht mehr in das Attribut vclasses.

Unterschied hier ist also das im ersten Fall alle get Befehle geparst sind (und damit alle "Hook löschen") und dann der parseHook gesetzt wird. Im Fall von security wird aber das Parsen der folgenden get versionClass verzögert, wodurch sich der Ablauf ändert und der Hook verlorengeht.

Ich hoffe jetzt ist zumindest das Problem klar...

Über den Lösungsansatz muss ich mir jetzt auch noch mal Gedanken machen, dazu muss ich mir aber das mit dem $cl bzw. $hash->{CL} mal ansehen.

Gruß,
Andreas.

[A.Harrenberg]

Hi Rudi,

- Alle Fhem-Befehle kriegen ein $cl Parameter, womit man das Eingabekanal (z.Zt. nur telnet/FHEMWEB/keins) identifizieren kann. Leider gibt Command_Set/Get das an SetFn/GetFn nicht als Parameter weiter. Um die API nicht zu aendern, wird seit ca 6Monaten $hash->{CL} gesetzt fuer die SetFn/GetFn aufrufe. D.h. wenn du in $hash ein CL vorfindest, dann hat man die Funktion interaktiv aufgerufen. Im ZWave_Cmd wird in so einem Fall fall bei get $asyncGet gesetzt, und falls die Antwort eintrifft, via asyncOutput der Aufrufer benachrichtigt. Ich meine, dass diese Behandlung bei diesem Problem nicht notwendig ist.

mir scheint dies aber als einzige Möglichkeit überzubleiben...

Ich habe mal einen Patch erstellt der auf Vorhandensein $hash->{CL} abfragt und den Hook nur löscht wenn es vorhanden ist. Damit wird bei mir wieder das Attribut vclasses gefüllt und bei non-secure funktioniert es auch noch...

Patch packe ich in den "Sammelthread"...

Gruß,
Andreas.