Adminiuga
commented
3 years ago the problem is not in how to use eraseKeyTableEntry ID: 0x0076 but "when" to use it. zha_custom btw uses it to delete the keys, if there's a key for the device but zigpy/bellows does not have that device in database.
I think you are on the very right track and it has to do with mismatching frame counters, because one side was reset, but not the NCP. Narrowing it down to be TC link key related helps, just need to think how to handle it best way possible.
MattWestb
Master @Adminiuga. First i need explaining the basis for my "request". I have large experience of communication / security systems and pretty novice in deep programing after trying BASIC in the school i was very disappointed and wos writing my code in assembler for MC6809 but was not working professional with it. Logic and analytic thinking have always being my strong side then working with technical things. And then cant finding the problem, then taking one step back and 2 to the side for seeing the problem from one other view. After reading the 13-0402-13 Base Device Behavior Specification Version 1.0 and trying applying it one the silabs AN1233: Zigbee Security and was thinking the problem was rejoining devices in the network. I have not finding any guide "how to implementing your custom EZSP coordinator" and i don't have your skills and experience of coding for NCPs. Have "reading" the UG100: EZSP Reference Guide and trying finding out how silabs have implanting the Base-Device-Behavior in the EZSP concept. After one nights sleep I was rethinking and turing the problem around and was finding that the problem is not rejoining of devices, then the devices not in the network (reseted and dont have network or trustcenter link key in its key table). Was finding 2 functions that catching my attention in the reference guide. CearKeyTable and eraseKeyTableEntry. It is not described how to using this on the host application side but its must being some logical behind them.
Back to our beloved bellows: I think bellows is working more than well as secure Zigbee 3 coordinator but i have not trying it out so much and not over longer time. I have finding that is failing some fundamental functions that is not implanted for making it working "autonome" then joining devices that was paired in one network and stored in the NCPs key table and was resetted / removed from the network. What i have see is that pairing devices then the NCP have its key table empty the NCP can adding new devices and its working well. The fundamental thing is that then removing the NCP from the network (deleting it in ZHA) its still having the "old key table" saved in the chip. Then adding it to ZHA the key table in the chip is not being reseted and ther for using the "old key table" and can't (and should NOT do!!) updating the keys then the devices is not rejoining the network (if they don't have the,same key token) the devices is doing one new joining (pairing) and the NCP suld making one new key in the key table. The logic is to erasing the key table then removing the NCP from the system. Then the NCP can adding new devices keys in the table then ZHA is adding new devices. For testing this function its needed implanting from "UG100: EZSP Reference Guide EmberZNet PRO Release 6.8.0", 10 Security Frames fuktion:
If pairing its working after key table is cleared its need being integrated in ZHA. Can being in "config" menu for the NCP and / or then deleting or adding the NCP in ZHA and also possible asking "delete the old key table in the NCP ?" can being good for keeping all paired devices security credentials then needed.
The next funktion is that ZHA its not deleting the key from one device in the NCPs table then deleting the device in ZHA. Then deleted devices don't doing a "rejoining" (its dont have one network key or trustcenter link in its key table then its reseted) its doing on new pairing and therefore the old key in the NCPs table is useless and blocking the device from doing one new paring (perhaps bad for the user but its the secure way). The logick is then deleting one device in ZHA also suld deleting the key in the NCPs table. For testing this function is needed implanting from "UG100: EZSP Reference Guide EmberZNet PRO Release 6.8.0", 10 Security Frames fuktion:
If pairing its working after the key is erased in the NCPs table then logic needs being integrated in ZHA for doing that automatic. The normal suld being that ZHA is doing it then deleting one device in the GUI but it can also being good having it under the device property as "delete device key in NCP" thats making it possible resetting the device and repairing it without deleting it and is configuration in ZHA.
One thing that also can being god in the NCP config is "cleaning unused device keys in NCP table" for getting rid of "trash" in the key table that is not stored in ZHAs database for eliminating problems with "hidden ghost key" in the NCP.
I hope you is understanding my (un)logical thinking but i think this is the key for getting bellows working in real zigbee 3 mode without braking the security completely (as some other system have done).
Pleas integrating theses 2 functions in ZHA_CUSTOM so its being possible testing how the EZSP is handling the key table and if its working OK getting it implanted in the multiversion bellows (Bellows2 ?). If you like opening for more advance testing and possible adding installation keys you can also inplanting:
One thing the "UG100: EZSP Reference Guide" i have looking in is "EmberZNet PRO Release 6.8.0" so it can being its not working with older versions without adapting the commands.
PS. I have not looking on the TI chips implanting but Z2M have problem with the new texas adapters and need reflashing them for getting them working agen = can being bad keys in the table that the host and/or the NCP is not taking care of.
Have one nice weekend !!
Regard MW