zigbeer/zigbee-shepherd

Are all AREQ's transaction safe?

splitice opened this issue · 2 comments

I think I have found what appears to be a bug. If the simple description is requested multiple times in parallel the request only one request is returned twice (two responses for the same device).

  cc-znp:SREQ --> ZDO:nodeDescReq, { dstaddr: 43688, nwkaddrofinterest: 43688 } +2ms
  serialport write 9 bytes of data +2ms
  zigbee-shepherd:request REQ --> ZDO:nodeDescReq +4ms
  zigbee-shepherd:request REQ --> ZDO:mgmtLqiReq +7ms
  cc-znp:SRSP <-- ZDO:nodeDescReq, { status: 0 } +12ms
  cc-znp:SREQ --> ZDO:nodeDescReq, { dstaddr: 39797, nwkaddrofinterest: 39797 } +2ms
  serialport write 9 bytes of data +4ms
  cc-znp:SRSP <-- ZDO:nodeDescReq, { status: 0 } +19ms
  cc-znp:SREQ --> ZDO:mgmtLqiReq, { dstaddr: 39797, scanchannels: undefined, scanduration: undefined, startindex: 0 } +3ms
  serialport write 8 bytes of data +4ms
  cc-znp:SRSP <-- ZDO:mgmtLqiReq, { status: 0 } +26ms
  cc-znp:AREQ <-- ZDO:nodeDescRsp, { srcaddr: 39797, status: 0, nwkaddr: 39797, logicaltype_cmplxdescavai_userdescavai: 2, apsflags_freqband: 64, maccapflags: 132, manufacturercode: 48042, maxbuffersize: 64, maxintransfersize: 0, servermask: 0, maxouttransfersize: 0, descriptorcap: 3 } +2s
  zigbee-shepherd:msgHdlr IND <-- ZDO:nodeDescRsp +5ms
  cc-znp:AREQ <-- ZDO:nodeDescRsp, { srcaddr: 39797, status: 0, nwkaddr: 39797, logicaltype_cmplxdescavai_userdescavai: 2, apsflags_freqband: 64, maccapflags: 132, manufacturercode: 48042, maxbuffersize: 64, maxintransfersize: 0, servermask: 0, maxouttransfersize: 0, descriptorcap: 3 } +13ms
  zigbee-shepherd:msgHdlr IND <-- ZDO:nodeDescRsp +2ms

Note the ZDO:nodeDescReq, and their ZDO:nodeDescRsp pairs

I think this should be no problem. ZS received the first nodeDescRsp AREQ message will resolve the promise. And the second nodeDescRsp message will be ignored.

https://github.com/zigbeer/zigbee-shepherd/blob/master/lib/components/zdo.js#L61-L64

It was not clear to me if this was the nodeDescRsp being duplicated and the second one not responding. Or the nodeDescRsp not being transaction safe.

If you think it's the first and not a problem, all good I'll keep debugging that problematic device.