Incorrectly neighbor parse on ZDOCmd.Mgmt_Lqi_req (Z-Stack bug ?) #65
Comments
|
Hmm. Is this only when the ZDO request is being sent to the coordinator itself? |
|
I tried to query the valve, it seems the response is correct: |
|
I can confirme zigpy/zigpy#565 is related to this behavior. Once the end device is joined both wrong and right neighbor entries are added, after some time the right neighbor is disappeared and end device can no longer be commanded. Both neighbors can be read in It seems it's not just a bug of communication, but the values are wrong on z-stack. |
|
Does this happen for every end device? I glanced over the relevant pieces of Z-Stack and no immediate location jumped out at me for where the order of these fields in memory is swapped. My theory is that this is a pair of calls to I'm almost done parsing every table in NVRAM so while in theory this is something that can possibly be fixed in zigpy-znp, it should be reported to TI. |
Currently I only have 1 Danfoss Ally for testing. I did more test from zero with nvram erased. With @Koenkk 's firmware I can reproduce it easily, with TI's original version compiled by CCS I can't reproduce it after 24 hours test. I do |
|
I believe I just ran into this issue. I formed a test network with three devices on a freshly-erased zzh! stick running the latest build of Z-Stack. The following devices were joined to the coordinator:
When performing a network backup by parsing the NVRAM data structures, I noticed not three but five devices show up: {
"nwk_address": "765b",
"ieee_address": "00124b001c4b2159" // Sonoff temp/humidity
},
{
"nwk_address": "ae8e",
"ieee_address": "00124b001c4b6e8e" // Sonoff motion
},
{
"nwk_address": "fffe",
"ieee_address": "4b001c4b21591f13" // ???
},
{
"nwk_address": "0012",
"ieee_address": "4b001c4b2159d4fc" // ???
},
{
"nwk_address": "8e2f",
"ieee_address": "d0cf5efffece3af2", // Trådfri outlet
"link_key": {
"tx_counter": 0,
"rx_counter": 0,
"key": "d2b23cb634cda7031b7e0dc49a010ed8"
}
}Wireshark confirmed that the coordinator was indeed sending a parent announce message containing these two "devices": In Z-Stack 3, the address manager table in NVRAM is stored so that each entry has its own "item" that you directly read. I've backed up and restored numerous networks using this parsing code and assume it is correct: It definitely looks like some Z-Stack bug is causing these bogus devices to be written to NVRAM. I believe some code somewhere in Z-Stack is directly reading the members of a struct like this: uint8_t extAddr[8];
uint16_t nwkAddr;But in the wrong order: uint16_t nwkAddr;
uint8_t extAddr[8];If you concatenate the NWK and IEEE addresses of the second bogus device, you can see it forms the IEEE address of the Sonoff motion sensor: // Bogus NWK + IEEE
0x0012 4b:00:1c:4b:21:59:d4:fc
// Sonoff motion IEEE
00124b001c4b2159This doesn't explain what the two trailing bytes are in either of the two bogus devices' IEEE addresses but it perhaps is the incorrect parsing of some ZDO announcement packet sent by another router? I don't believe a topology scan was performed by zigpy yet so this looks like something triggered by device joining. |
|
If putting all "real devices" and comparing them with the "new" i getting little from all in the 2 new. Real ones: False ones: And found parts in the false ones: fffe The problem is the 4b001c4b part can coming from both the Sonoff sensors. My feeling is that the last part (1f13 and d4fc) is one hashed part of the real devices mwk: 765b ae8e and 8e2f. @puddly Can you deleting one of the Sonoff and putting in one with more different IEEE (if you is having one with IEEE: 0123456789ABCDEF its one high points device) than you can see witch part that is scrambled. I only saying INTERESTING !! And great findings done !!! |
|
If i was having one of those coordinators then i have patching 3 IKEA modules with custom IEEE (flashing custom token with IEEE). |
|
If I can find a way recreate it again, I will try with devices with less similar IEEE addresses (and hopefully capture the packet responsible for this). Unfortunately it did not happen again after three attempts 😞 |
I'm investigating this issue zigpy/zigpy#565 and found after a coordinator rset the neighbor table is wrong.
We can see IEEE is mixed with NWK.
Sometimes there are 2 items, the 2nd is correct
The text was updated successfully, but these errors were encountered: