ZB_ZDO_SIGNAL_DEVICE_ANNCE triggers without any device added/rejoined

[Dhaval Dalvadi]

We have used zigbee sample for coordinator we did many changes in that like subscribing and sending values in UART when any new device gets added.

but noticed ZB_ZDO_SIGNAL_DEVICE_ANNCE  also gets called with FF:FF:FF:FF:FF:FF:FF:FF mac address and 0x00 short address?
Is it expected behavior? if yes why its happening what action we should take that time?

       zb_zdo_signal_device_annce_params_t *dev_annce_params =

                ZB_ZDO_SIGNAL_GET_PARAMS(

                    sg_p, zb_zdo_signal_device_annce_params_t);

            LOG_INF("New device commissioned or rejoined (short_addr: 0x%04hx)",

                    dev_annce_params->device_short_addr);

            char ieee_address_str[24]; 

            snprintf(ieee_address_str, sizeof(ieee_address_str),

                     "%02x:%02x:%02x:%02x:%02x:%02x:%02x:%02x",

                     dev_annce_params->ieee_addr[0], dev_annce_params->ieee_addr[1],

                     dev_annce_params->ieee_addr[2], dev_annce_params->ieee_addr[3],

                     dev_annce_params->ieee_addr[4], dev_annce_params->ieee_addr[5],

                     dev_annce_params->ieee_addr[6], dev_annce_params->ieee_addr[7]);

            // Log the complete IEEE address

            LOG_INF("IEEE Address: %s", ieee_address_str);

[Maria Gilje]

Hello,

but noticed ZB_ZDO_SIGNAL_DEVICE_ANNCE  also gets called with FF:FF:FF:FF:FF:FF:FF:FF mac address and 0x00 short address?

Having a device announcing its address as 0x0000 is odd since your device is the coordinator.

Can you share more about when this happens in the network? Is there a device announcement packet sent in the network with the addresses you share? You can share a sniffer log of the network as a .pcap file, and note that if you have changed the network key from the default for nRF Connect SDK samples, we need that to decrypt the packets. Let me know if you need to share a non-default network key.

I'll be able to help more after the weekend or whenever you reply after that.

Best regards,

Maria

[Dhaval Dalvadi]

Hi

If it was coordinator it self the IEEE MAC address should have there of coordiny instead of FF:FF:FF:FF:FF:FF:FF:FF right ?

[Maria Gilje]

Hello,

It seems like you have the correct understanding of this, but I will write this in general terms so there is no misleading or confusing details.

When a device announces its presence on a network, the IEEE address in the packet is its own.

Please also reply to my questions from before so we can proceed with more support for this case.

Best regards,

Maria

[Dhaval Dalvadi]

To answer your questions of past

Can you share more about when this happens in the network?
Its random cant provide specific to reproduce 

Is there a device announcement packet sent in the network with the addresses you share?
No it should as we have only couple of devices to test we might have another coordinator which can have steering mode started but I dont think it will affect as it will be in different network.


You can share a sniffer log of the network as a .pcap file, and note that if you have changed the network key from the default for nRF Connect SDK samples, we need that to decrypt the packets. Let me know if you need to share a non-default network key.
I can try but we should not wait for it as it can take time to reproduce and on same time to sniff packets while actively working on other stuff

[Maria Gilje]

I understand that it can be tricky and time consuming to sniff the correct moment. But unfortunately it is also tricky for us to find out why there is a device announcing its address as FF:FF:FF:FF:FF:FF:FF:FF in your network when we don't have access to the network traffic. Since the issue seems random as well it also complicates our route to a resolution.

I greatly appreciate if you are able to provide us with a sniffer log. Setting up a sniffer to run while doing other work  is alright.

Best regards,

Maria