CC1352P: routing devices are "spamming" coordinator with Match Descriptor Requests

Hi Peter,

The CC2530s include an OTA client application and thus are looking for an OTA server to bind with.  They may be demanding that an OTA server exist since it recognizes the TI OUI on the coordinator's MAC address.  If you cannot disable or remove this feature from the relay switches then the best solution may be to add OTA server functionality to your coordinator such that it responds to the Match Descriptor Requests, thus preventing the devices from further spamming the network. Or you could try creating a custom Extended PAN ID in SysConfig which may prevent the relay switches from initiating the OTA procedure.

Regards,
Ryan

Hi Ryan,

We have now tested the same on another system. Both systems have identical ZNP firmware versions and Linux server configuration is identical as well. BUT:

Now there actually is an automated answer to that request.

Probably, a hard reset of the module and a restore of the configuration will resolve the issue at this point, but do you have any idea WHY this may happen?

Attached also a log of the Linux server.

Regards
Peter

0451.zigbee.log

Maybe try to request two system to see if one of them support OTA cluster and another doesn't.

So after hard reset and configuration restore, the system is now sending responses to all connected devices. But the routing devices appear not to be happy as they are continuing with the requests. This is a filtered view on one of them:

Here the MD Response is sent to 0xDB79 through 0x1357. The message is getting acknowledged.

One second later 0xDB79 is sending the request again:

Is there any sense behind that, anything we can do on gateway side, or is this a bug of the routing device?

It's better to provide sniffer logs to elaborate your issue instead of screenshots.

Network key 3C:F7:34:04:06:DA:24:21:8E:2C:77:AA:91:C7:5E:D8

Sniffer logs: https://1drv.ms/u/s!AuGD3z8N0GWFsrBTCYIaZ97hJJxP2g?e=NuOxOq

Make sure you use AF_REGISTER to add OTA cluster as server on your ZNP coordinator. We test this on Ztool and are sure it works.

Hi Ryan,

This is what we have noticed, too, today. 0xCC39 and one more of which I have forgotten the ID right now, are causing the most problems.

We have deleted them and then we noticed the issue reported by Randy (https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1028567/cc1352p-remove-old-device-from-the-network) that removed device will not be removed from the network in case they did not catch the remove. We can resolve this by catching Announce messages of unknown devices and send a Leave to them immediately, but maybe there is already a built-in mechanism for this as this a security risk as well.

In general, from what you have seen in the sniffer log, from you point of view is there anything else we need to do on gateway side about these Match Descriptor Messages or is the rest up to the end device?

Regards
Peter

There is no build-in mechanism for such case in Z-Stack and it's correct to send leave request to such device from your coordinator to ask unknown or unwanted device to leave network.

Hey Peter,

I've responded to Randy's post with more information, but YiKai is correct that nothing is built into Z-Stack to handle these instances.  Can you please further expand on the security risk that is present due to this behavior?

I think we've identified that the joining devices are the cause of the unwanted messages and short of asking them to leave there is little to be done from the gateway's perspective.

Regards,
Ryan

Hi Ryan,

If I understood your answer in the other post correctly, it is great.

By security risk I was referring to the following scenario:
If devices could just enter the network if knowing the key and they will not be removed even if are not in the module's database, one could capture the key by sniffing and then easily introduce a routing device into the network which would be able to modify or filter values, generate actions etc.

But if ZNP will eliminate devices not found in its database, then there is no risk and the mechanism I was wondering if exists, does exist. So everything fine.

Thank you!

Regards
Peter

You can refer to the response on the other thread.  A leaked NWK key is definitely a possible risk to Zigbee networks.

Regards,
Ryan