This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

ZigBee install code Network left (leave type: 0)

Hi,

I was implementing ZigBee coordinator in nrf connect v1.18.0 to connect sensor which develops from template sample. every thing went fine until I add install code (took from shell sample). building and running the sample was fine:

  • coordinator side:

ic = "83FED3407A939723A5C639B26916D505C3B5" 

zb_secur_ic_add(ic_add_ctx.addr, ZB_IC_TYPE_128, ic_add_ctx.ic, zb_secur_ic_add_cb);

+

zb_set_installcode_policy(ZB_TRUE);
zb_bdb_set_legacy_device_support(1);

  • ep side:

ic = "83FED3407A939723A5C639B26916D505C3B5" 

if (zb_secur_ic_set(ZB_IC_TYPE_128, ic) != RET_OK) {
			LOG_ERR("Failed to set IC");
		}
                else
                {
                    
                      LOG_INF("{0} done setting ic");
                }

The end device leave network after a second of joining and retry joining network!
RTT of coordinator: 

RTT of endpoint:

why the ep leave network Error message (Network left (leave type: 0))? is there something I must add?

from my understanding of install code device that dose not have same ic that coordinator added cannot join the network. but when I disable policy (zb_set_installcode_policy(ZB_FALSE)) all devices can join the network(weather it have same ic or dose not have!!). therefore, the problem that I mention above occur after enabling install code policy ! is there something I misunderstood?!

other question how can I generate new install code (16b+2crc) ? and can all ep have same install code?

this sniffing file of network (ic policy=True): ZB_ic.pcapng

both devices are nrf52833. nrf connect 1.18.0.

Thanks 

Parents
  • Hi,

    In the log on the coordinator it says that it failed to parse eui64. Are you certain the address you give as parameter in zb_secur_ic_add() is correct? Are you using the Zigbee shell sample and issuing shell commands (such as bdb ic add), or have you copied the relevant code from the shell library to your code?

    Can you try to read and print the install codes stored on the coordinator to see if they have been added correctly?

    In the log from the sensor I do not see the result of setting the install code. Does is say that it failed to set the install code, or does it print "done setting ic"? Remember that on the joining device you must set the install code before the stack is started, so before zigbee_enable().

    from my understanding of install code device that dose not have same ic that coordinator added cannot join the network

    This depends on the value of the allow-Install-Codes Trust Center policy. You have three options:

    • 0x00 – do not support Install Codes
    • 0x01 – Support but do not require use of Install Codes
    • 0x02 – Require the use of Install

    So if it is 0x01 then it supports Install Codes, but it does not require it. I am not sure whether zb_set_installcode_policy(ZB_TRUE) sets the value to 0x01 or 0x02, but I will ask the developers to clarify.

    other question how can I generate new install code (16b+2crc) ?

    You will need to generate a random 128 bit number and use it to calculate the CRC16. The install code CRC calculation is based upon the CRC 16-CCITT algorithm, and you can find open source implementation of the algorithm online. There is more information about this in the Security chapter in the Base Device Behavior specification.

    and can all ep have same install code?

    No, each node should have it's own random install codes. Since the codes are random there is a possibility that they are not unique, but knowing a set of install codes should not give any knowledge of another install code. So if you have manufactured multiple sensor devices, no one should be able to figure out the install code of a sensor device they do now own based on what the install code on their sensor device is.

    this sniffing file of network (ic policy=True): ZB_ic.pcapng

    I am not able to see all the packets in the sniffer log as some of them are encrypted. Are you able to share the network key so that I can decrypt the packets? I can see the Beacon and Association packets, but not much that will tell me what the issue is.

    Best regards,

    Marte

  • Hi,

    Thanks for your replay

    I have fix problems of parse eui64 and store ic correctly also, set ic code in ep before the zigbee_enable()

    Can you try to read and print the install codes stored on the coordinator to see if they have been added correctly?

    yes I was able to list ic which include the correct install code with eui64 of device. However still get the same error (I: Network left (leave type: 0))!  

    the device try to join to coordinator but leave at same time and re join again and leave  at same time! 

    I doesn't know what the problem is! 

     

    So if it is 0x01 then it supports Install Codes, but it does not require it. I am not sure whether zb_set_installcode_policy(ZB_TRUE) sets the value to 0x01 or 0x0

    I think zb_set_installcode_policy(ZB_TRUE) set value to 0x02.

     

Reply
  • Hi,

    Thanks for your replay

    I have fix problems of parse eui64 and store ic correctly also, set ic code in ep before the zigbee_enable()

    Can you try to read and print the install codes stored on the coordinator to see if they have been added correctly?

    yes I was able to list ic which include the correct install code with eui64 of device. However still get the same error (I: Network left (leave type: 0))!  

    the device try to join to coordinator but leave at same time and re join again and leave  at same time! 

    I doesn't know what the problem is! 

     

    So if it is 0x01 then it supports Install Codes, but it does not require it. I am not sure whether zb_set_installcode_policy(ZB_TRUE) sets the value to 0x01 or 0x0

    I think zb_set_installcode_policy(ZB_TRUE) set value to 0x02.

     

Children
  • ZB_ic2.pcapng


    This sniffer log(network key: 00112233445566778899aabbccddeeff)

  • Hi,

    Is the network open when the device tries to join? In the network coordinator sample you can reopen the network with button 1.

    In the sniffer log I can see the device send an Association Request and receive an Association Response, but the next steps of the joining does not happen, i.e. the device does not send a Device Announcement or Node Descriptor Request, and the network key is not verified. I am not sure why this is happening, but I will try reproducing it.

    Can you test using the Zigbee shell sample and see if the issue is with the network coordinator, the sensor, or both? So test once where you replace the network coordinator with the shell and use it the shell as a coordinator together with the sensor. Then test by replacing the sensor with the shell and use the shell as a router together with the network coordinator.

    Best regards,

    Marte

  • Hello,

    So test once where you replace the network coordinator with the shell and use it the shell as a coordinator together with the sensor. Then test by replacing the sensor with the shell and use the shell as a router together with the network coordinator.

    After some experiments I found that I was adding wrong long address of sensor in the coordinator. the sensor join the network after adding its own extpanid !

    now my question, In coordinator, how can I know the extpanid of device that I want to add? is it fixed ( no one can change it or  it randomly generated in every new build of project?!

    I mean I want to add ic automatically by the coordinator for specific devices!

    thank for your time ^_^ 

  • Hi,

    That is good to hear!

    The extpanid, or the long address, of the device is set during initialization of the Zigbee stack with the function zb_set_long_address. When it comes to Nordic chips the device address is already stored in the FICR registers, so the way it is done in our SDKs is that the long address is read from FICR registers with zb_osif_get_ieee_eui64, and then it is set with zb_set_long_address:

    /* Set device address to the value read from FICR registers. */
    zb_ieee_addr_t ieee_addr;
    zb_osif_get_ieee_eui64(ieee_addr);
    zb_set_long_address(ieee_addr);

    Because of this the address will be static, and a device will have the same address no matter if you build a project again or build a different Zigbee project, as long as the Zigbee stack is initialized correctly, unless you change it yourself with zb_set_long_address.

    There are multiple ways you can find what this address is. On the device itself you can for example print the address after getting it with zb_osif_get_ieee_eui64. You can also use Zigbee shell to get it, either with zdo eui64 if it is the address of the shell device you want to find, or zdo ieee_addr short_addr to find the long address of the device with short address short_addr.

    Best regards,

    Marte

Related