• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 56 subscribers
  • Views 728 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Original question:

CC2530: Device Announcement, but not added to the Device List - ZIGBEE-LINUX-SENSOR-TO-CLOUD_1.0.1

CC2530: All devices with Device Announcement, but only 3 added to the Device List - ZIGBEE-LINUX-SENSOR-TO-CLOUD_1.0.1

Mario DW
Genius 3145 points
Part Number: CC2530
Other Parts Discussed in Thread: Z-STACK,

This is another case for hat appears to be the same issue as the parent thread/Question.

This question is abou tthe difficulty of having Associated Devices appear in the Device List.

The devices that were associated effectivement is limited to this list of three, while I trie to associate 3 more.
No (potential) router objects are active, so the coordinator is the parent.
In a previous session I had 6 associated devices.

00:15:8D:00:04:7B:83:69 , 0xE060 , 0x00, 0x1037 , 1, 00:12:4B:00:10:22:82:77, 0xBE
70:B3:D5:B1:30:01:01:1E , 0xFEC7 , 0x01, 0x1234 , 1, 00:12:4B:00:10:22:82:77, 0x0C
00:12:4B:00:07:60:BB:0A , 0xD313 , 0x01, 0x0000 , 1, 00:12:4B:00:10:22:82:77, 0x00

Most Device Announcements were seen by the NWK_MGR. When seen, the same message appears twice :

**** Succeeded:
[2020-11-21 20:19:05.706891] [NWK_MGR/HNDL] MISC1 : NwkMgr processZdoDeviceAnnounce: ieeeaddr 00158D00047B8369, nwkaddr E060, capInfo 00
[2020-11-21 20:19:05.807084] [NWK_MGR/HNDL] MISC1 : NwkMgr processZdoDeviceAnnounce: ieeeaddr 00158D00047B8369, nwkaddr E060, capInfo 00
**** Failed
[2020-11-21 20:20:31.994302] [NWK_MGR/HNDL] MISC1 : NwkMgr processZdoDeviceAnnounce: ieeeaddr 000D6F000E8A756F, nwkaddr 7869, capInfo 00
[2020-11-21 20:20:32.016209] [NWK_MGR/HNDL] MISC1 : NwkMgr processZdoDeviceAnnounce: ieeeaddr 000D6F000E8A756F, nwkaddr 7869, capInfo 00
[2020-11-21 20:20:32.074101] [NWK_MGR/HNDL] MISC1 : NwkMgr processZdoDeviceAnnounce: ieeeaddr 000D6F000E8A756F, nwkaddr 7869, capInfo 00
[2020-11-21 20:20:32.075225] [NWK_MGR/HNDL] MISC1 : NwkMgr processZdoDeviceAnnounce: ieeeaddr 000D6F000E8A756F, nwkaddr 7869, capInfo 00
**** Succeeded:
[2020-11-21 20:22:52.958338] [NWK_MGR/HNDL] MISC1 : NwkMgr processZdoDeviceAnnounce: ieeeaddr 70B3D5B13001011E, nwkaddr FEC7, capInfo 0C
[2020-11-21 20:22:53.016499] [NWK_MGR/HNDL] MISC1 : NwkMgr processZdoDeviceAnnounce: ieeeaddr 70B3D5B13001011E, nwkaddr FEC7, capInfo 0C
**** Failed
[2020-11-21 20:24:02.542342] [NWK_MGR/HNDL] MISC1 : NwkMgr processZdoDeviceAnnounce: ieeeaddr 000D6F0012199E48, nwkaddr FAD0, capInfo 00
[2020-11-21 20:24:02.612740] [NWK_MGR/HNDL] MISC1 : NwkMgr processZdoDeviceAnnounce: ieeeaddr 000D6F0012199E48, nwkaddr FAD0, capInfo 00
**** Succeeded:
[2020-11-21 20:24:34.893677] [NWK_MGR/HNDL] MISC1 : NwkMgr processZdoDeviceAnnounce: ieeeaddr 00124B000760BB0A, nwkaddr D313, capInfo 00
[2020-11-21 20:24:34.950063] [NWK_MGR/HNDL] MISC1 : NwkMgr processZdoDeviceAnnounce: ieeeaddr 00124B000760BB0A, nwkaddr D313, capInfo 00
**** Failed
[2020-11-21 20:26:27.866167] [NWK_MGR/HNDL] MISC1 : NwkMgr processZdoDeviceAnnounce: ieeeaddr CCCCCCFFFE3A2F33, nwkaddr

 E1B7, capInfo 00

[2020-11-21 20:26:27.898286] [NWK_MGR/HNDL] MISC1 : NwkMgr processZdoDeviceAnnounce: ieeeaddr CCCCCCFFFE3A2F33, nwkaddr E1B7, capInfo 00

Thes announcements did not seem to result in a processZdoDeviceAnnounce message from the NWK_MGR :

[2020-11-21 20:26:40.239374] > [ZDO/AREQ] **END_DEVICE_ANNCE_IND** <418B-000d6f0012199e48> Src:418B (SYS:5/TYPE:40/CMD:C1) (156)::fe0d45c18b418b41489e1912006f0d0080b6
[2020-11-21 20:27:34.653963] > [ZDO/AREQ] **END_DEVICE_ANNCE_IND** <6F23-000d6f0012a0ccf8> Src:6F23 (SYS:5/TYPE:40/CMD:C1) ( 86)::fe0d45c1236f236ff8cca012006f0d0080ed
[2020-11-21 20:27:34.685458] > [ZDO/AREQ] **END_DEVICE_ANNCE_IND** <6F23-000d6f0012a0ccf8> Src:6F23 (SYS:5/TYPE:40/CMD:C1) ( 68)::fe0d45c1236f236ff8cca012006f0d0080ed


In te log we can also notice several messages like this:

[2020-11-21 20:26:26.132895] [NWK_MGR/LSTN] MISC1 : SRVR_GET_SHORT_ADDRESS_REQ: ieeeAddr: 0000000000000000
[2020-11-21 20:31:42.869124] [GATEWAY/HNDL] MISC1 : SrcAddr 0000000000000000, zclTransId 190, clusterId 2820, payloadlen 3

I tried to make a start as clean as possible here:

[2020-11-21 16:42:46.550375] > [ZDO/SRSP] **EXT_NWK_INFO** DEV_COORD_STARTING <0000> PANID:EC5C COORD:0000 EXTPAN:00124b0010228277 EXTCOORD:0000000000000000 Chan:0 ZSuccess (SYS:5/TYPE:60/CMD:50) ( 35)::fe1865500000085cec000077822210004b12000000000000000000000b

## First Association, observations

The examinition of the successful association shows that there are few things that I think can be improved, and that probably hinder the association process at other occassions.

The first Association (that succeeds) is done at the following time:

[2020-11-21 20:19:04.103775] 17467 00:15:8d:00:04:7b:83:69 â<86><92> 0x0000 IEEE 802.15.4 21 Association Request, RFD


The gateway should be improved to return the valid IEEE Address as soon as it possibly can. For the first associated devices, the first attributes report is associated with address 00:*

**** The NWK MGR gets the information
[2020-11-21 20:19:05.553055] > [ZDO/AREQ] **TC_DEVICE_IND** <E060-00158d00047b8369> Parent:0000 (SYS:5/TYPE:40/CMD:CA) ( 17)::fe 0c 45 ca 60 e0 69 83 7b 04 00 8d 15 00 00 00 0e
[2020-11-21 20:19:05.557042] [Z_STACK/HNDL] INFO : zstackpb Sending TC Device Ind: nwkAddr:0xE060, extAddr:0x00158D00047B8369, parentAddr:0x0000
[2020-11-21 20:19:05.562772] [NWK_MGR/HNDL] MISC1 : Processing ZDO TC Device Ind: 00158D00047B8369
[2020-11-21 20:19:05.562890] [NWK_MGR/HNDL] INFO : NwkMgr AddDevice State Machine Started on 0x00158d00047b8369
[2020-11-21 20:19:05.562988] [NWK_MGR/HNDL] INFO : nwkAddr E060, parent 0000
[2020-11-21 20:19:05.695392] > [ZDO/AREQ] **END_DEVICE_ANNCE_IND** <E060-00158d00047b8369> Src:E060 (SYS:5/TYPE:40/CMD:C1) ( 18)::fe 0d 45 c1 60 e0 60 e0 69 83 7b 04 00 8d 15 00 80 04
[2020-11-21 20:19:05.706891] [NWK_MGR/HNDL] MISC1 : NwkMgr processZdoDeviceAnnounce: ieeeaddr 00158D00047B8369, nwkaddr E060, capInfo 00

**** But does not report it back!
[2020-11-21 20:19:05.746175] [NWK_MGR/LSTN] MISC1 : SRVR_GET_IEEE_ADDRESS_REQ: shortAddr: E060
[2020-11-21 20:19:05.746588] [NWK_MGR/LSTN] PKT_HEX: [ NWK_MGR>>GATEWAY ] [ucst] 0D:00:79:01:08:01:10:01:19:00:00:00:00:00:00:00:00
[2020-11-21 20:19:05.746769] [NWK_MGR/LSTN] PKTTYPE: [ NWK_MGR>>GATEWAY ] SrvrGetIeeeAddressCnf
[2020-11-21 20:19:05.746917] [NWK_MGR/LSTN] PKTBODY: cmdId = SRVR_GET_IEEE_ADDRESS_CNF
[2020-11-21 20:19:05.747041] [NWK_MGR/LSTN] PKTBODY: status = STATUS_FAILURE
[2020-11-21 20:19:05.747177] [NWK_MGR/LSTN] PKTBODY: ieeeAddress = 00:00:00:00:00:00:00:00


I think that this is inefficient too, but I did not examine in detail what would be a better solution.
Note: the state is reported as "GET_PARENT" and we can see that this is done in ProcessDeviceAnnounce. The parent is known, why does i tneed to be requested?

[2020-11-21 20:19:05.707008] [NWK_MGR/HNDL] DEBUG : Lock PSTATE 0 (zNwkSrv_AD_UpdateCapInfo)
[2020-11-21 20:19:05.707160] [NWK_MGR/HNDL] DEBUG : Unlock PSTATE 0 (zNwkSrv_AD_UpdateCapInfo)
[2020-11-21 20:19:05.707256] [NWK_MGR/HNDL] DEBUG : Lock PSTATE 0 (zNwkSrv_AD_ProcessDeviceAnnounce)
[2020-11-21 20:19:05.707351] [NWK_MGR/HNDL] INFO : AddDevice: Retrying state 1, remaining tries: 4
[2020-11-21 20:19:05.707474] [NWK_MGR/HNDL] INFO : PSTATE B4C009D0 -> GET_PARENT


I do not think that it is usefull that the NWK_MGR request the IEEE_ADDRESS of the coordinator by calling the ZSTACK/ZDO/etc each time. It adds unneccessary overhead and delay IMHO. I would expect that its internal data is "up to date". What does "TI" think:

[2020-11-21 20:20:04.238118] [NWK_MGR/MAIN] MISC1 : NwkMgr sendZdoIeeeAddrReq: ieeeaddr 0000
[2020-11-21 20:20:04.238261] [NWK_MGR/MAIN] INFO : preparing to send 8 bytes, subSys 0x11, cmdId 0x31 (ZDO_IEEE_ADDR_REQ), pData:
[2020-11-21 20:20:04.238369] [NWK_MGR/MAIN] INFO : [MUTEX] Lock SRSP Transaction Mutex
[2020-11-21 20:20:04.238617] [NWK_MGR/MAIN] PKT_HEX: [ Z_STACK<<NWK_MGR ] [SREQ] 08:00:31:31:08:31:10:00:18:00:20:00
[2020-11-21 20:20:04.238783] [NWK_MGR/MAIN] PKTTYPE: [ Z_STACK<<NWK_MGR ] zdoIeeeAddrReq
[2020-11-21 20:20:04.238935] [NWK_MGR/MAIN] PKTBODY: cmdID = ZDO_IEEE_ADDR_REQ
[2020-11-21 20:20:04.239062] [NWK_MGR/MAIN] PKTBODY: nwkAddr = 0x00000000 (0)
[2020-11-21 20:20:04.239178] [NWK_MGR/MAIN] PKTBODY: type = SINGLE_DEVICE
[2020-11-21 20:20:04.239295] [NWK_MGR/MAIN] PKTBODY: startIndex = 0x00000000 (0)
[2020-11-21 20:20:04.267541] > [ZDO/AREQ] **IEEE_ADDR_RSP** (SYS:5/TYPE:40/CMD:81) ( 18)::fe 0d 45 81 00 77 82 22 10 00 4b 12 00 00 00 c0 00 97


### Failed association "000D6F000E8A756F" (i.e., Zigbee association succeeds, but does not show up in the gateway)

Note, "(Un)lock PSTATE 0 (function)" indicates that the state machine with indx 0 has been (un)locked by "function". The function reported by the "Unlock" message is the function that called the first function to get a lock. (That is the improvement I made in the gateway to no longer have invalid memory accesses to the device info).

[2020-11-21 20:19:59.443680] 18295 00:0d:6f:00:0e:8a:75:6f â<86><92> 0x0000 IEEE 802.15.4 21 Association Request, RFD^M
[2020-11-21 20:19:59.641028] 18303 00:12:4b:00:10:22:82:77 â<86><92> 00:0d:6f:00:0e:8a:75:6f IEEE 802.15.4 27 Association Response, PAN: 0xec5c Addr: 0x7869^M
[2020-11-21 20:20:00.791439] > [ZDO/AREQ] **TC_DEVICE_IND** <7869-000d6f000e8a756f> Parent:0000 (SYS:5/TYPE:40/CMD:CA) ( 17)::fe 0c 45 ca 69 78 6f 75 8a 0e 00 6f 0d 00 00 00 6e
[2020-11-21 20:20:00.799888] [NWK_MGR/HNDL] INFO : NwkMgr AddDevice State Machine Started on 0x000d6f000e8a756f
[2020-11-21 20:20:00.799986] [NWK_MGR/HNDL] INFO : nwkAddr 7869, parent 0000
[2020-11-21 20:20:00.800086] [NWK_MGR/HNDL] DEBUG : Lock PSTATE 0 (zNwkSrv_AD_GetStateMachineAndLock)
[2020-11-21 20:20:00.800179] [NWK_MGR/HNDL] INFO : AddDevice: Initiated new state machine
[2020-11-21 20:20:00.800282] [NWK_MGR/HNDL] INFO : PSTATE B4C009D0 -> WAITING
[2020-11-21 20:20:00.800373] [NWK_MGR/HNDL] DEBUG : Unlock PSTATE 0 (zNwkSrv_AddDevice)

The device initiates the association again, but the information sent by the ZNP is an incoming message - apparently there is nothing with regards to the Device Announcement , etc:

[2020-11-21 20:20:31.544733] [GATEWAY/READ] INFO : Client Read: (len 8):
[2020-11-21 20:20:31.545196] [GATEWAY/MAIN] INFO : [MUTEX] Unlock SRSP Mutex
[2020-11-21 20:20:31.651265] 18364 00:0d:6f:00:0e:8a:75:6f â<86><92> 0x0000 IEEE 802.15.4 21 Association Request, RFD^M
[2020-11-21 20:20:31.651766] 18365 â<86><92> IEEE 802.15.4 5 Ack^M
[2020-11-21 20:20:31.847143] 18366 00:0d:6f:00:0e:8a:75:6f â<86><92> 0x0000 IEEE 802.15.4 18 Data Request^M
[2020-11-21 20:20:31.847636] 18367 â<86><92> IEEE 802.15.4 5 Ack^M
[2020-11-21 20:20:31.850588] 18368 00:12:4b:00:10:22:82:77 â<86><92> 00:0d:6f:00:0e:8a:75:6f IEEE 802.15.4 27 Association Response, PAN: 0xec5c Addr: 0x7869^M
[2020-11-21 20:20:31.851004] 18369 â<86><92> IEEE 802.15.4 5 Ack^M
[2020-11-21 20:20:31.857767] 18370 0x7869 â<86><92> 0x0000 IEEE 802.15.4 12 Data Request^M
[2020-11-21 20:20:31.858253] 18371 â<86><92> IEEE 802.15.4 5 Ack^M
[2020-11-21 20:20:31.866274] 18372 0x0000 â<86><92> 0x7869 ZigBee 73 Transport Key^M
[2020-11-21 20:20:31.866400] 18373 â<86><92> IEEE 802.15.4 5 Ack^M
[2020-11-21 20:20:31.881769] 18374 0x7869 â<86><92> 0x0000 ZigBee ZDP 54 Match Descriptor Request, Nwk Addr: 0x0000, Profile: 0x0104^M
[2020-11-21 20:20:31.882256] 18375 â<86><92> IEEE 802.15.4 5 Ack^M
[2020-11-21 20:20:31.886514] 18376 0x7869 â<86><92> Broadcast ZigBee ZDP 65 Device Announcement, Nwk Addr: 0x7869, Ext Addr: Ember_00:0e:8a:75:6f^M
[2020-11-21 20:20:31.886576] 18377 â<86><92> IEEE 802.15.4 5 Ack^M
[2020-11-21 20:20:31.890762] 18378 0x7869 â<86><92> Broadcast ZigBee ZDP 65 Device Announcement, Nwk Addr: 0x7869, Ext Addr: Ember_00:0e:8a:75:6f^M
[2020-11-21 20:20:31.891239] 18379 â<86><92> IEEE 802.15.4 5 Ack^M
[2020-11-21 20:20:31.896746] 18380 0x7869 â<86><92> 0x0000 ZigBee HA 62 ZCL IAS Zone: Zone Status Change Notification, Seq: 28^M
[2020-11-21 20:20:31.896809] 18381 â<86><92> IEEE 802.15.4 5 Ack^M
[2020-11-21 20:20:31.900996] 18382 0x7869 â<86><92> 0x0000 ZigBee HA 64 ZCL: Report Attributes, Seq: 29^M
[2020-11-21 20:20:31.901394] 18383 â<86><92> IEEE 802.15.4 5 Ack^M
[2020-11-21 20:20:31.905622] 18384 0x7869 â<86><92> 0x0000 ZigBee HA 60 ZCL: Report Attributes, Seq: 30^M
[2020-11-21 20:20:31.905686] 18385 â<86><92> IEEE 802.15.4 5 Ack^M
[2020-11-21 20:20:31.909868] 18386 0x7869 â<86><92> 0x0000 ZigBee HA 60 ZCL: Report Attributes, Seq: 31^M
[2020-11-21 20:20:31.910238] 18387 â<86><92> IEEE 802.15.4 5 Ack^M
[2020-11-21 20:20:31.960442] > [AF/AREQ] **INCOMING_MSG** <7869/GRP:0000/CLSTR:0500/EP:01> Seq:0 DstEP:01 SrcMAC:1C19 LQI:47 SECURE:0 TIMSTMP:12029930 DATALEN:9 RADIUS:25 (SYS:4/TYPE:40/CMD:81) ( 34)::fe 1d 44 81 00 00 00 05 69 78 01 01 00 2f 00 ea 8f b7 00 00 09 19 1c 00 24 00 00 ff 00 00 69 78 1d ea
[...]
[2020-11-21 20:20:31.971055] [NWK_MGR/LSTN] MISC1 : SRVR_GET_IEEE_ADDRESS_REQ: shortAddr: 7869
[2020-11-21 20:20:31.974556] [GATEWAY/HNDL] MISC1 : P2P: Get IEEE Address Failed, status: 1
[2020-11-21 20:20:31.974621] [GATEWAY/HNDL] MISC1 : Processing IAS Zone Status Change Indication, TransId: 28

[2020-11-21 20:20:31.977445] > [AF/AREQ] **INCOMING_MSG** <7869/GRP:0000/CLSTR:0001/EP:01> Seq:0 DstEP:01 SrcMAC:1D18 LQI:47 SECURE:0 TIMSTMP:12029944 DATALEN:11 RADIUS:24 (SYS:4/TYPE:40/CMD:81) (136)::fe1f44810000010069780101002f00f88fb700000b181d0a2000201c2100209669781da6
[2020-11-21 20:20:31.977445] > [AF/AREQ] **INCOMING_MSG** <7869/GRP:0000/CLSTR:0001/EP:01> Seq:0 DstEP:01 SrcMAC:1E18 LQI:47 SECURE:0 TIMSTMP:12029958 DATALEN:7 RADIUS:24 (SYS:4/TYPE:40/CMD:81) (136)::fe1b44810000010069780101002f000690b7000007181e0a2100209669781d50
[2020-11-21 20:20:31.977445] > [AF/AREQ] **INCOMING_MSG** <7869/GRP:0000/CLSTR:0001/EP:01> Seq:0 DstEP:01 SrcMAC:1F18 LQI:47 SECURE:0 TIMSTMP:12029973 DATALEN:7 RADIUS:24 (SYS:4/TYPE:40/CMD:81) (136)::fe1b44810000010069780101002f001590b7000007181f0a2000201c69781dc9
[2020-11-21 20:20:31.977445] > [ZDO/AREQ] **END_DEVICE_ANNCE_IND** <7869-000d6f000e8a756f> Src:7869 (SYS:5/TYPE:40/CMD:C1) (136)::fe0d45c1697869786f758a0e006f0d0080f5

The DeviceAnnounce is handled two times, because it airs two times, with different sequence numbers (48 & 49):

[2020-11-21 20:20:31.886514] 18376 0x7869 â<86><92> Broadcast ZigBee ZDP 65 Device Announcement, Nwk Addr: 0x7869, Ext Addr: Ember_00:0e:8a:75:6f^M
[2020-11-21 20:20:31.886576] 18377 â<86><92> IEEE 802.15.4 5 Ack^M
[2020-11-21 20:20:31.890762] 18378 0x7869 â<86><92> Broadcast ZigBee ZDP 65 Device Announcement, Nwk Addr: 0x7869, Ext Addr: Ember_00:0e:8a:75:6f^M
[2020-11-21 20:20:31.891239] 18379 â<86><92> IEEE 802.15.4 5 Ack^M


[2020-11-21 20:20:31.993298] [NWK_MGR/READ] INFO : Received 31 bytes, subSys 0x51, cmdId 0x48
[2020-11-21 20:20:31.993527] [NWK_MGR/READ] INFO : RPC_CMD_AREQ cmdId: 0x48
[2020-11-21 20:20:31.993622] [NWK_MGR/READ] INFO : [DBG] Allocated @ 0xB5003F50 (received 21 messages)...
[2020-11-21 20:20:31.993773] [NWK_MGR/READ] INFO : Filling new message (@ 0xB5003F50)...
[2020-11-21 20:20:31.993910] [NWK_MGR/HNDL] INFO : [MUTEX] Mutex for AREQ unlocked
[2020-11-21 20:20:31.994019] [NWK_MGR/HNDL] INFO : [DBG] Processing @ 0xB5003F50
[2020-11-21 20:20:31.994172] [NWK_MGR/HNDL] INFO : [DBG] asyncCB: subSys:0x00000011, cmdId:0x00000048, len:0x0000001F, pData:0xB5003F58
[2020-11-21 20:20:31.994302] [NWK_MGR/HNDL] MISC1 : NwkMgr processZdoDeviceAnnounce: ieeeaddr 000D6F000E8A756F, nwkaddr 7869, capInfo 00
[2020-11-21 20:20:31.994405] [NWK_MGR/HNDL] DEBUG : Lock PSTATE 0 (zNwkSrv_AD_UpdateCapInfo)
[2020-11-21 20:20:31.994490] [NWK_MGR/HNDL] DEBUG : Unlock PSTATE 0 (zNwkSrv_AD_UpdateCapInfo)
[2020-11-21 20:20:31.994691] [NWK_MGR/HNDL] DEBUG : Lock PSTATE 0 (zNwkSrv_AD_ProcessDeviceAnnounce)
[2020-11-21 20:20:31.994978] [NWK_MGR/HNDL] DEBUG : Unlock PSTATE 0 (zNwkSrv_AD_ProcessDeviceAnnounce)


[2020-11-21 20:20:32.015284] [NWK_MGR/READ] INFO : Received 31 bytes, subSys 0x51, cmdId 0x48
[2020-11-21 20:20:32.015501] [NWK_MGR/READ] INFO : RPC_CMD_AREQ cmdId: 0x48
[2020-11-21 20:20:32.015597] [NWK_MGR/READ] INFO : [DBG] Allocated @ 0xB5003F10 (received 22 messages)...
[2020-11-21 20:20:32.015677] [NWK_MGR/READ] INFO : Filling new message (@ 0xB5003F10)...
[2020-11-21 20:20:32.015819] [NWK_MGR/HNDL] INFO : [MUTEX] Mutex for AREQ unlocked
[2020-11-21 20:20:32.015926] [NWK_MGR/HNDL] INFO : [DBG] Processing @ 0xB5003F10
[2020-11-21 20:20:32.016081] [NWK_MGR/HNDL] INFO : [DBG] asyncCB: subSys:0x00000011, cmdId:0x00000048, len:0x0000001F, pData:0xB5003F18
[2020-11-21 20:20:32.016331] [NWK_MGR/HNDL] DEBUG : Lock PSTATE 0 (zNwkSrv_AD_UpdateCapInfo)
[2020-11-21 20:20:32.016417] [NWK_MGR/HNDL] DEBUG : Unlock PSTATE 0 (zNwkSrv_AD_UpdateCapInfo)
[2020-11-21 20:20:32.016611] [NWK_MGR/HNDL] DEBUG : Lock PSTATE 0 (zNwkSrv_AD_ProcessDeviceAnnounce)
[2020-11-21 20:20:32.016705] [NWK_MGR/HNDL] DEBUG : Unlock PSTATE 0 (zNwkSrv_AD_ProcessDeviceAnnounce)


This has to be further examined to understand why the device is not accepted in the Device List.


### Device CCCCCCFFFE3A2F33

I am not going into the details of CCCCCCFFFE3A2F33, but the LCD display of that device indicates that it is associated according to that device. It receives ACKS from the ZNP and it reports attributes. It "just" does not show up in the Device List

[2020-11-21 20:26:27.866167] [NWK_MGR/HNDL] MISC1 : NwkMgr processZdoDeviceAnnounce: ieeeaddr CCCCCCFFFE3A2F33, nwkaddr E1B7, capInfo 00
[2020-11-21 23:28:10.480904] 11485 â<86><92> IEEE 802.15.4 5 Ack^M
[2020-11-21 23:28:11.336462] 11486 0xe1b7 â<86><92> 0x0000 IEEE 802.15.4 12 Data Request^M
[2020-11-21 23:28:11.336953] 11487 â<86><92> IEEE 802.15.4 5 Ack^M
[2020-11-21 23:28:11.404832] 11488 0xe1b7 â<86><92> 0x0000 ZigBee HA 54 ZCL: Report Attributes, Seq: 77^M
[2020-11-21 23:28:11.405330] 11489 â<86><92> IEEE 802.15.4 5 Ack^M

For further information, later
1. I restarted the gateway with an& updated version (added a stackstraice for processZdoDeviceAnnounce)
2. I proceeded with the physical procedure to factory reset the CCCCCCFFFE3A2F33 ZED.
3. I restarted the gateway because I couldn't start the joining procedure from the APP UI.

[2020-11-21T23:37:40] sent to GATEWAY: len=24, cmd_id=20, subsystem=19
[2020-11-21T23:37:40] Raw=18:00:13:14:08:14:12:0D:08:00:11:0A:BB:60:07:00:4B:12:00:28:01:18:80:0A:20:11:28:00
[2020-11-21T23:37:40] Queued command successfully; CBARG = 0
[2020-11-21T23:37:41] comm_send_permit_join: Sending NWK_SET_PERMIT_JOIN_REQ with Join Time 0x3c

Then the device CCCCCCFFFE3A2F33 announced itself successfully again, but still does not end up in the Device List.


The attached log also merges with the application log (no microsecond precision).

The question is: how must the code evolve to ensure that all these devices en up in the Gateway's Device List?

PartialSuccessWithAssociations.zip

  • 0
    Genius 3145 points

    A partial response to this issue would be that the NWK_MGR checks the ZNP for information about registered devices using UTIL_GET_DEVICE_INFO (which only returns the LocalDevices according to the latest Z-Stack MT API documentation), and/or UTIL_ASSOC_COUNT and UTIL_ASSOC_FIND_DEVICE or whatever function(s) allow to get the state of the network as it is known by the ZNP (Coordinator). 

    IMHO the current implementation does not rely enough on the ZNP and gets easily out of sync.  The ZNP already has certain information, while the Gateway requests it again, generating unneccessary traffic (and power consumption).

    I think a lot of the issues that I observe are related to the Gateay ant the ZNP not being in sync.

  • 0
    Guru 735685 points

    Your sniffer log is large so can you specify which packet numbers or lines to check this issue? If you can elaborate you issue on your sniffer log, that will be better.

  • 0 in reply to YiKai Chen
    Genius 3145 points

    Hi YiKai

    The principle is the same as for the other question.

    I showed:

    [2020-11-21 20:20:31.886514] 18376 0x7869 â<86><92> Broadcast ZigBee ZDP 65 Device Announcement, Nwk Addr: 0x7869, Ext Addr: Ember_00:0e:8a:75:6f^M
[2020-11-21 20:20:31.886576] 18377 â<86><92> IEEE 802.15.4 5 Ack
[2020-11-21 20:20:31.890762] 18378 0x7869 â<86><92> Broadcast ZigBee ZDP 65 Device Announcement, Nwk Addr: 0x7869, Ext Addr: Ember_00:0e:8a:75:6f^M
[2020-11-21 20:20:31.891239] 18379 â<86><92> IEEE 802.15.4 5 Ack

    So the position in the sniffer log is 18376, and the time is in UTC .

    My technique is to decode the entire pcap file using tshark, convert the log so that the date matches the other logs.  Then I merge the logs ("cat") and sort them.  This way I can relate the gateway log to the sniffer log.

    Most of the time if I need more detail, I also decode the sniffer log using "-V" to get the full report for each packet.  I then findn the packet either by date or by packet index.  To find the packet by its index, in the complete log (-V), one can look for "18376:" for example (the packet number followed by the semicolumn).  From there the details can be easily found.

    Of course you may be acustomed to other tools, but I prefers textual tools.

  • 0 in reply to Mario DW
    TI__Guru**** 218927 points

    Hi Mario,

    Thank you for providing this information, I will need more time to look through your post before giving a formal response.

    Regards,
    Ryan

  • 0
    TI__Guru**** 218927 points

    Hi Mario,

    Can you please explain the changes which have been made to nwkmgrsrv.c and nwkmgrservices.c up to this point?  The default code adds devices to the list upon reception of a TC Device Indication, not a Device Announce:

    static void processZdoTcDeviceInd( ZdoTcDeviceInd *pInMsg )
{
  uiPrintf("Processing ZDO TC Device Ind: %016llX\n", pInMsg->extendedaddr );

  zNwkSrv_AddDevice( pInMsg->extendedaddr, pInMsg, 0, nwkSrvAddDeviceTcInfoCB );
}

    Therefore, as designed only Zigbee 3.0 devices which request a TCLK update will be added to the device list, it does not depend on the Device Announcement.  You could modify the solution to check the device database with nwkMgrDb_GetDeviceInfo upon reception of a device announce in processZdoDeviceAnnounce, and attempt to call zNwkSrv_AddDevice if no entry is found (would have to be modified due to tcInfo).  Devices are added to the database with nwkMgrDb_AddDevice in nwkSrvAddDeviceTcInfoCB after zNwkSrv_AddDevice.  You could also make changes to ignore IEEE Address Requests to the ZC (short address 0x0000).

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Genius 3145 points

    The changes to the nwkmgr are essentiallly related to software structures, not to the algorithm itself.

    For instance, I improved the state machine management by protecting access with mutexes, and by no longer copying the contents when extending the list, but only copying the pointers to the state machines from one structure to another.
    Also , state machines are referenced by their index (not address) before they are locked and the address is passed on to the original functions only after the state machine is locked (mutex).

    When a state machine is "deleted", it is staged for deletion and "deleted" carefully during the unlocking algorithm.

    That has suppressed the invalid memory accesses.

    Some corrections have been made to building packets, in particular the osal_nv_write method.

    The thing is that sometimes it works, sometimes it doesn't.  In the test case that led up to the bufferoverflow issue, I associated 4 devices in a row.  As I am at the same time debugging the gateway on an x86 virtual machine, I do not have the logs available for the gateway itself (the servers were manually started, the NWKMGR is running under qtcreator for debugging) - the serial log and sniffer log has been provided with the bufferoverflow issue.

  • 0 in reply to Mario DW
    Genius 3145 points

    Regarding the gateway you're indicating that it is up to me to do the modifications - IHMO TI does not live up to the promise that The Z-Stack 3.0 Linux Gateway delivers components that enable engineers to develop applications  - there's too much work and rework involved to make it production ready to call it some that that "enables engineers".

    Anyway, the logs for the given period show a TC Device Ind for 5 devices and the gateway only reported 3 devices anyway.

    [2020-11-21 20:19:05.557042] [Z_STACK/HNDL] INFO   : zstackpb Sending TC Device Ind: nwkAddr:0xE060, extAddr:0x00158D00047B8369, parentAddr:0x0000
[2020-11-21 20:19:05.562772] [NWK_MGR/HNDL] MISC1  : Processing ZDO TC Device Ind: 00158D00047B8369
[2020-11-21 20:20:00.795857] [Z_STACK/HNDL] INFO   : zstackpb Sending TC Device Ind: nwkAddr:0x7869, extAddr:0x000D6F000E8A756F, parentAddr:0x0000
[2020-11-21 20:20:00.799772] [NWK_MGR/HNDL] MISC1  : Processing ZDO TC Device Ind: 000D6F000E8A756F
[2020-11-21 20:20:32.873798] [Z_STACK/HNDL] INFO   : zstackpb Sending TC Device Ind: nwkAddr:0x7869, extAddr:0x000D6F000E8A756F, parentAddr:0x0000
[2020-11-21 20:20:32.879148] [NWK_MGR/HNDL] MISC1  : Processing ZDO TC Device Ind: 000D6F000E8A756F
[2020-11-21 20:22:52.927697] [Z_STACK/HNDL] INFO   : zstackpb Sending TC Device Ind: nwkAddr:0xFEC7, extAddr:0x70B3D5B13001011E, parentAddr:0x0000
[2020-11-21 20:22:52.933255] [NWK_MGR/HNDL] MISC1  : Processing ZDO TC Device Ind: 70B3D5B13001011E
[2020-11-21 20:24:02.181885] [Z_STACK/HNDL] INFO   : zstackpb Sending TC Device Ind: nwkAddr:0xFAD0, extAddr:0x000D6F0012199E48, parentAddr:0x0000
[2020-11-21 20:24:02.184726] [NWK_MGR/HNDL] MISC1  : Processing ZDO TC Device Ind: 000D6F0012199E48
[2020-11-21 20:24:34.533403] [Z_STACK/HNDL] INFO   : zstackpb Sending TC Device Ind: nwkAddr:0xD313, extAddr:0x00124B000760BB0A, parentAddr:0x0000
[2020-11-21 20:24:34.537988] [NWK_MGR/HNDL] MISC1  : Processing ZDO TC Device Ind: 00124B000760BB0A
[2020-11-21 20:26:27.626206] [Z_STACK/HNDL] INFO   : zstackpb Sending TC Device Ind: nwkAddr:0xE1B7, extAddr:0xCCCCCCFFFE3A2F33, parentAddr:0x0000
[2020-11-21 20:26:27.631485] [NWK_MGR/HNDL] MISC1  : Processing ZDO TC Device Ind: CCCCCCFFFE3A2F33
[2020-11-21 20:26:40.103797] [Z_STACK/HNDL] INFO   : zstackpb Sending TC Device Ind: nwkAddr:0x418B, extAddr:0x000D6F0012199E48, parentAddr:0x0000
[2020-11-21 20:27:34.383088] [Z_STACK/HNDL] INFO   : zstackpb Sending TC Device Ind: nwkAddr:0x6F23, extAddr:0x000D6F0012A0CCF8, parentAddr:0x0000

    After restarting the ZNP that was held on hold in the debugger for the buffer overrun, and restarting the gateway, the UI reported an empty network.  Before restarting the application I had 4 devices shown.

    Then a first one appeared and a second one without reopening the network, so these devices rejoined.

    Actually when looking at the sniffer logs, more than 2 devices has a positive association response, but only to appeared in the UI:

    1671 2020-11-24 16:22:14.183310 00:15:8d:00:04:7b:83:69 → 0x0000       IEEE 802.15.4 21 Association Request, RFD
 1675 2020-11-24 16:22:14.679993 00:12:4b:00:10:22:82:77 → 00:15:8d:00:04:7b:83:69 IEEE 802.15.4 27 Association Response, PAN: 0xec5c Addr: 0x2ed0
 1909 2020-11-24 16:23:14.705314 00:12:4b:00:07:60:bb:0a → 0x0000       IEEE 802.15.4 21 Association Request, RFD
 1913 2020-11-24 16:23:15.149671 00:12:4b:00:10:22:82:77 → 00:12:4b:00:07:60:bb:0a IEEE 802.15.4 27 Association Response, PAN: 0xec5c Addr: 0xeb68
 2075 2020-11-24 16:23:38.037008 cc:cc:cc:ff:fe:3a:2f:33 → 0x0000       IEEE 802.15.4 21 Association Request, RFD
 2079 2020-11-24 16:23:38.243700 00:12:4b:00:10:22:82:77 → cc:cc:cc:ff:fe:3a:2f:33 IEEE 802.15.4 27 Association Response, PAN: 0xec5c Addr: 0xc9a3
 2173 2020-11-24 16:23:50.437026 cc:cc:cc:ff:fe:3a:2f:33 → 0x0000       IEEE 802.15.4 21 Association Request, RFD
 2177 2020-11-24 16:23:50.641297 00:12:4b:00:10:22:82:77 → cc:cc:cc:ff:fe:3a:2f:33 IEEE 802.15.4 27 Association Response, PAN: 0xec5c Addr: 0xc9a3
 2225 2020-11-24 16:23:54.665769 cc:cc:cc:ff:fe:3a:2f:33 → 0x0000       IEEE 802.15.4 21 Association Request, RFD
 2233 2020-11-24 16:23:54.870300 00:12:4b:00:10:22:82:77 → cc:cc:cc:ff:fe:3a:2f:33 IEEE 802.15.4 27 Association Response, PAN: 0xec5c Addr: 0xc9a3
 2465 2020-11-24 16:24:29.431406 70:b3:d5:b1:30:01:01:1e → 0x0000       IEEE 802.15.4 21 Association Request, RFD
 2473 2020-11-24 16:24:29.931420 00:12:4b:00:10:22:82:77 → 70:b3:d5:b1:30:01:01:1e IEEE 802.15.4 27 Association Response, PAN: 0xec5c Addr: 0xfec7
 3013 2020-11-24 16:26:25.583662 00:0d:6f:00:12:a0:cc:f8 → 0x0000       IEEE 802.15.4 21 Association Request, RFD
 3017 2020-11-24 16:26:25.783924 00:12:4b:00:10:22:82:77 → 00:0d:6f:00:12:a0:cc:f8 IEEE 802.15.4 27 Association Response, PAN: 0xec5c Addr: 0xaa9e
 3183 2020-11-24 16:27:45.687831 00:0d:6f:00:0e:8a:75:6f → 0x0000       IEEE 802.15.4 21 Association Request, RFD
 3187 2020-11-24 16:27:45.886980 00:12:4b:00:10:22:82:77 → 00:0d:6f:00:0e:8a:75:6f IEEE 802.15.4 27 Association Response, PAN: 0xec5c Addr: 0x132f

    As the association response nor the Device announcement are sufficient for the gateway, here are the network management packets for this period:

    5348 2020-11-25 12:51:29.647207       0x132f → 0x0000       ZigBee 47 Rejoin Request, Device: 0x132f
 5352 2020-11-25 12:51:29.852595       0x0000 → 0x132f       ZigBee 57 Rejoin Response, New Address: 0x132f
 5354 2020-11-25 12:51:29.888082       0x132f → 0x0000       ZigBee ZDP 54 Match Descriptor Request, Nwk Addr: 0x0000, Profile: 0x0104
 5356 2020-11-25 12:51:29.892819       0x132f → Broadcast    ZigBee ZDP 65 Device Announcement, Nwk Addr: Ember_00:0e:8a:75:6f
 5362 2020-11-25 12:51:29.925086       0x132f → Broadcast    ZigBee ZDP 65 Device Announcement, Nwk Addr: Ember_00:0e:8a:75:6f
 5384 2020-11-25 12:51:33.890553       0x0000 → 0x132f       ZigBee ZDP 51 Match Descriptor Response, Nwk Addr: 0x0000, Status: Success
 5447 2020-11-25 12:52:45.435893       0x0000 → Broadcast    IEEE 802.15.4 51 Data, Dst: Broadcast, Src: 0x0000, Bad FCS
 5453 2020-11-25 12:53:57.488331       0xaa9e → 0x0000       ZigBee 47 Rejoin Request, Device: 0xaa9e
 5457 2020-11-25 12:53:57.692698       0x0000 → 0xaa9e       ZigBee 57 Rejoin Response, New Address: 0xaa9e
 5459 2020-11-25 12:53:57.702333       0xaa9e → 0x0000       ZigBee ZDP 54 Match Descriptor Request, Nwk Addr: 0x0000, Profile: 0x0104
 5461 2020-11-25 12:53:57.707077       0xaa9e → Broadcast    ZigBee ZDP 65 Device Announcement, Nwk Addr: Ember_00:12:a0:cc:f8
 5465 2020-11-25 12:53:57.735688       0xaa9e → Broadcast    ZigBee ZDP 65 Device Announcement, Nwk Addr: Ember_00:12:a0:cc:f8
 5476 2020-11-25 12:54:00.716130       0x0000 → 0xaa9e       ZigBee ZDP 51 Match Descriptor Response, Nwk Addr: 0x0000, Status: Success
 5520 2020-11-25 12:56:45.682258       0x0000 → 0x132f       ZigBee ZDP 48 Node Descriptor Request, Nwk Addr: 0x132f
 5522 2020-11-25 12:56:45.688257       0x132f → 0x0000       ZigBee ZDP 62 Node Descriptor Response, Nwk Addr: 0x132f, Status: Success
 5526 2020-11-25 12:56:46.699709       0x0000 → 0x132f       ZigBee ZDP 48 Node Descriptor Request, Nwk Addr: 0x132f
 5528 2020-11-25 12:56:46.705585       0x132f → 0x0000       ZigBee ZDP 62 Node Descriptor Response, Nwk Addr: 0x132f, Status: Success
 5532 2020-11-25 12:56:47.706954       0x0000 → 0x132f       ZigBee ZDP 48 Node Descriptor Request, Nwk Addr: 0x132f
 5534 2020-11-25 12:56:47.714203       0x132f → 0x0000       ZigBee ZDP 62 Node Descriptor Response, Nwk Addr: 0x132f, Status: Success
 5538 2020-11-25 12:57:45.573446       0x0000 → Broadcast    IEEE 802.15.4 47 Data, Dst: Broadcast, Src: 0x0000, Bad FCS
 5545 2020-11-25 12:59:07.582544       0x0000 → 0xaa9e       ZigBee ZDP 48 Node Descriptor Request, Nwk Addr: 0xaa9e
 5549 2020-11-25 12:59:07.592786       0xaa9e → 0x0000       ZigBee ZDP 62 Node Descriptor Response, Nwk Addr: 0xaa9e, Status: Success
 5553 2020-11-25 12:59:08.597893       0x0000 → 0xaa9e       ZigBee ZDP 48 Node Descriptor Request, Nwk Addr: 0xaa9e
 5555 2020-11-25 12:59:08.603874       0xaa9e → 0x0000       ZigBee ZDP 62 Node Descriptor Response, Nwk Addr: 0xaa9e, Status: Success
 5559 2020-11-25 12:59:09.588234       0x0000 → 0xaa9e       ZigBee ZDP 48 Node Descriptor Request, Nwk Addr: 0xaa9e
 5561 2020-11-25 12:59:09.594224       0xaa9e → 0x0000       ZigBee ZDP 62 Node Descriptor Response, Nwk Addr: 0xaa9e, Status: Success
 5572 2020-11-25 13:00:05.071191       0xc9a3 → 0x0000       ZigBee 47 Rejoin Request, Device: 0xc9a3
 5576 2020-11-25 13:00:05.283053       0x0000 → 0xc9a3       ZigBee 57 Rejoin Response, New Address: 0xc9a3
 5578 2020-11-25 13:00:05.292418       0xc9a3 → Broadcast    ZigBee ZDP 65 Device Announcement, Nwk Addr: cc:cc:cc:ff:fe:3a:2f:33
 5580 2020-11-25 13:00:05.301800       0xc9a3 → 0x0000       ZigBee 56 End Device Timeout Request
 5584 2020-11-25 13:00:05.308356       0xc9a3 → Broadcast    ZigBee ZDP 65 Device Announcement, Nwk Addr: cc:cc:cc:ff:fe:3a:2f:33
 5597 2020-11-25 13:00:15.882098       0xc9a3 → 0x0000       ZigBee ZDP 48 Node Descriptor Request, Nwk Addr: 0x0000
 5605 2020-11-25 13:00:16.916103       0x0000 → 0xc9a3       ZigBee ZDP 62 Node Descriptor Response, Nwk Addr: 0x0000, Status: Success
 5611 2020-11-25 13:00:24.474519       0x0000 → 0xc9a3       ZigBee ZDP 48 Node Descriptor Request, Nwk Addr: 0xc9a3
 5613 2020-11-25 13:00:24.479258       0xc9a3 → 0x0000       ZigBee ZDP 62 Node Descriptor Response, Rev: 22, Nwk Addr: 0xc9a3, Status: Success
 5617 2020-11-25 13:00:24.992997       0x0000 → 0xc9a3       ZigBee ZDP 48 Active Endpoint Request, Nwk Addr: 0xc9a3
 5619 2020-11-25 13:00:24.998877       0xc9a3 → 0x0000       ZigBee ZDP 51 Active Endpoint Response, Nwk Addr: 0xc9a3, Status: Success
 5623 2020-11-25 13:00:25.496598       0x0000 → 0xc9a3       ZigBee ZDP 49 Simple Descriptor Request, Nwk Addr: 0xc9a3, Endpoint: 1
 5625 2020-11-25 13:00:25.503896       0xc9a3 → 0x0000       ZigBee ZDP 78 Simple Descriptor Response, Nwk Addr: 0xc9a3, Status: Success
 5704 2020-11-25 13:04:11.452390       0xaa9e → 0x0000       IEEE 802.15.4 60 Data, Dst: 0x0000, Src: 0xaa9e, Bad FCS
 5762 2020-11-25 13:06:23.193466       0xeb68 → 0x0000       ZigBee 47 Rejoin Request, Device: 0xeb68
 5767 2020-11-25 13:06:23.630705       0x0000 → 0xeb68       ZigBee 57 Rejoin Response, New Address: 0xeb68
 5769 2020-11-25 13:06:23.633587       0x0000 → 0xeb68       IEEE 802.15.4 11 Data, Dst: 0xeb68, Src: 0x0000
 5771 2020-11-25 13:06:23.654329       0xeb68 → Broadcast    ZigBee ZDP 57 Device Announcement, Nwk Addr: TexasIns_00:07:60:bb:0a
 5773 2020-11-25 13:06:23.667853       0xeb68 → Broadcast    ZigBee ZDP 57 Device Announcement, Nwk Addr: TexasIns_00:07:60:bb:0a
 5788 2020-11-25 13:06:48.083790       0x0000 → 0xeb68       ZigBee ZDP 48 Node Descriptor Request, Nwk Addr: 0xeb68
 5790 2020-11-25 13:06:48.101007       0xeb68 → 0x0000       ZigBee ZDP 62 Node Descriptor Response, Nwk Addr: 0xeb68, Status: Success
 5798 2020-11-25 13:06:48.331782       0x0000 → 0xeb68       ZigBee ZDP 48 Active Endpoint Request, Nwk Addr: 0xeb68
 5800 2020-11-25 13:06:48.348900       0xeb68 → 0x0000       ZigBee ZDP 51 Active Endpoint Response, Nwk Addr: 0xeb68, Status: Success
 5804 2020-11-25 13:06:48.463028       0x0000 → 0xeb68       ZigBee ZDP 49 Simple Descriptor Request, Nwk Addr: 0xeb68, Endpoint: 1
 5806 2020-11-25 13:06:48.480272       0xeb68 → 0x0000       ZigBee ZDP 66 Simple Descriptor Response, Nwk Addr: 0xeb68, Status: Success
 5881 2020-11-25 13:08:24.687272       0x0000 → 0xeb68       IEEE 802.15.4 45 Data, Dst: 0xeb68, Src: 0x0000, Bad FCS
 5892 2020-11-25 13:08:45.446781       0x0000 → Broadcast    IEEE 802.15.4 51 Data, Dst: Broadcast, Src: 0x0000, Bad FCS
 5962 2020-11-25 13:10:09.300402       0xc9a3 → Broadcast    ZigBee ZDP 54 Match Descriptor Request, Nwk Addr: 0xfffd, Profile: 0x0104
 5964 2020-11-25 13:10:09.312540       0xc9a3 → Broadcast    ZigBee ZDP 54 Match Descriptor Request, Nwk Addr: 0xfffd, Profile: 0x0104

    This is what I have in the UI

    00:12:4B:00:10:22:82:77 0000 01 0007(HA) | F2 0061(A1E0)                                                              
CC:CC:CC:FF:FE:3A:2F:33 C9A3 01 0301(HA)                                                                              
00:12:4B:00:07:60:BB:0A EB68 01 IAS ZONE/MOTION_SENSOR, [other status bits: 0001]

    There's not much sense in me reporting any of these gateway difficulties anymore.  I'll have to reverse engineer the gateway, document the inner workings for which there is no documentation as far as I know (the API is documented, but not the state machines, etc), match that to the Zigbee specification, define how to adapt the state machines, add other onces, etc   Or decide on another way to have the device work as a coordinator.  My customor has produced 1000 coordinators with the AM335x/CC2530 on it and they are keen on not throwing them away!

    Note: Marking this as resolved in order to no longer follow it up in the backlog of questions.  I am intensively debugging the gateway.