Problem of connection between Nordic's zigbee device and other Zigbee device

[Raffaela]

Hi,

I have a problem with a specific Zigbee certified device that I can't connect to my Nordic device.

When trying to connect to the device, I go to see the status:

void zboss_signal_handler(zb_uint8_t param)
{
    zb_zdo_app_signal_hdr_t  * p_sg_p = NULL;
    zb_zdo_app_signal_type_t   sig    = zb_get_app_signal(param, &p_sg_p);
    zb_ret_t                   status = ZB_GET_APP_SIGNAL_STATUS(param);
    zb_bool_t                  comm_status;

    switch (sig)
    {
        case ZB_BDB_SIGNAL_DEVICE_FIRST_START:
        case ZB_BDB_SIGNAL_DEVICE_REBOOT:
            
            if (status == RET_OK)
                        {
                NRF_LOG_INFO("Joined network successfully");
                bsp_board_led_on(ZIGBEE_NETWORK_STATE_LED);
            }

and it is equal to -1, so it is not RET_OK.

It's the first time that I have this problem of interoperability. Is it necessary to do something specific so that the Nordic device is visible from any other Zigbee device?

Best regards,

Raffaela

[Marjeris Romero]

Hi Raffaela,

Which nordic example are you using and what do you which device do you want to connect to? Are you sure both devices are running on the same zigbee channel?  By default, our examples operates on channel 16 only. In case someone tries to connect .e.g. our light switch example to his network and his network is set on channel 15, the device will not join.

Best regards,

Marjeris

[Raffaela]

Hi Marjeris,

Thank you for your reply. I'm using the light bulb example. I'm sure that the channel is correct because I'm using the sniffer and I see the zigbee traffic. The device is one of the Zigbee Alliance that it has the Zigbee Certification (Zigbee 3.0).

Thank you, 

Raffaela

[Marjeris Romero]

Hi Raffaella,

The signal change once the TCLK exchange is completed, but this is not despicted in the screenshot. Could you please send me the whole traffic dump and not just a screenshot? Please use .pcapng file format if possible.

Best regards,

Marjeris

[Raffaela]

Hi Marjeris,

Sorry for the late response. I have the whole traffic dump, but not in .pcapng but in .psd format: I use the CC2531 TI Dongle and the software "Texas Instrument Packet Sniffer". I hope that it is useful.

I continued to do other tests and noticed that if I set the Zigbee channel of the device I'm building (I usually use the define ZB_TRANSCEIVER_ALL_CHANNELS_MASK to make the device visible in all channels), it happens that the device tries to connect for good 8 times with different short addresses, although the endpoint is always the same.

Thank you,

Raffaela

Data_Sniffer_20191104.psd

[Raffaela]

Hi Marjeris,

By carefully monitoring the Zigbee traffic, I noticed that this message is missing and is not sent from my device when trying to make a connection (This superframe is sent by an other device that works fine with all the Zigbee devices):

How can I enable superframe sending?

Thank you,

Raffaela

[Marjeris Romero]

Hi Raffaela,

Unfortunately I am not familiar with Texas Instrument Packet Sniffer. Could you be so kind of setting up nRF Sniffer for 802.15.4 and sending the sniffer trace using Wireshark?

The last packet you send looks like a frame with an association permit, sent from another node in the network (not the coordinator), but this doesn't say too much to me.

Can you please explain more about the context of the situation? What does the topology of the network look like? What kind of coordinator are you using? Does the coordinator support network steering commissioning? Is the coordinator sending an association response to the router? Do they interchange keys?

Best regards,

Marjeris

[Raffaela]

Hi Marjeris,

I finally found the formt that you asked to me. I'm using a coordinator that support netowrk steering commissioning. I'm not sure that they interchange keys but what I see is that the status that is calculated in this way is equivalent to 0xffff and not 0x0000. 

zb_ret_t                   status = ZB_GET_APP_SIGNAL_STATUS(param);

Tha last packet was a mistake, sorry. 

I hope that the file help you to understand better the problem.

Thank you and best regards,

RaffaelaSniffer_20191106.pcapng 

[Marjeris Romero]

Hi Raffaela,

Unfortunately, I didn't get so much information from the sniffer log. It looks like the router with long address f4:ce:36:49:80:94:a3:59 sends an association request to the coordinator and gets a association response from the coordinator but I don't see they are exchanging keys, then the router goes out of the network and sents an new association request again and gets a new short address...

All the packets in the sniffer logs are also marked with "Bad FCS" which is strange, but I don't know if this is because of exporting the sniffer logs to Wireshark from another sniffer... It also seems like Wireshark was no able to decrypt all packets because there is not a key transfer between the devices.

It would have been better if you could sniff using a nRF52840 dongle together with our sniffer software.

You could try to check if you are erasing the persistance storage of the light bulb example each time you try to connect to the coordinator? Try doing a "nrfjprog --eraseall" and flash the DK again with the light_bulb example with zigbee_erase_persistent_storage set to ZB_FALSE. Try also to erase the stored information about the router in the coordinator and sniffing the association phase again.

I have asked this before but could you give more details about what type of 3rd party coordinator you are using? Name and type information could be useful so I can report this internally.

Best regards,

Marjeris

[Raffaela]

Hi Marjeris,

I didn't use Wireshark but I used Ubiqua Protocol Analyzer.

Yes, I was erasing the persistance storage but I changed and I set ZB_FALSE not ZB_TRUE, but there is not difference. 

The other thing that I noticed is that the incoming buffer is empty; I printed the buffer in this point:

p_buffer = (zb_buf_t *)ZB_BUF_FROM_REF(param);

This is the buffer that I saw:

0000000000000000000000000000000000000000000000000000000000000000000000005000000000000000000000000000000000000000000000000000000000000000000000000000

The Coordinator that I'm using is this:

GWA1502 - 2-channel contact interface Zigbee, 230V AC

Zigbee 3.0

Remote Control

GEWISS S.p.A.

Best regards,

Raffaela

[Marjeris Romero]

Hi Raffaela,

I read the user manual of the GWA1502 but didn't find so much useful information. It says you should do a factory reset before making the GWA1502 a coordinator, have you tried that?

It's difficult to see what is happening without good sniffer traces. Are you able to set up our nRF Sniffer for 802.15.4 together with for example a nRF52840 dongle or a nRF52840 DK and sniff the traffic between the GWA1502 coordinator and the light bulb example?

About the buffer being empty it all will depend where do you take the buffer from? If you simply allocate one, there is no point in printing its contents. If you get the buffer from the radio (through zigbee stack/endpoint), you may parse and print the contents of the incomming packet.

Please take a look at components\zigbee\common\zigbee_logger_eprxcl.c, which we use in the CLI example to parse and print buffers.

Best regards,

Marjeris

[Raffaela]

Hi Marjeris,

I did a factory reset before making the GWA1502 a coordinator.

I set up your Sniffer and I send you the log ok?

Thank you and best regards,

RaffaelaGewiss Nordic.pcapng

[Marjeris Romero]

Hi Raffaela,

Thanks for the sniffer traces. I see that the joining procedure is started but not completed, but I am not sure why this is hapening. Do you also have the log output from the light_bulb example and can you attach them?

I am a little unsure about what the "Many-to-One route request" send from the coordinator is for, but I am wondering if this is a legacy Zigbee PRO command. Have you tried setting zb_bdb_set_legacy_device_support(1)?

Best regards,

Marjeris