• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 56 subscribers
  • Views 653 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.

CC2531: Multi -hop joining with trust center

neugen
Prodigy 100 points
Part Number: CC2531


Hi all,

I have a test environment consisting of a Zigbee 3.0 network commissioned using a CC2531 acting as coordinator and trust center.

The CC2531 USB dongle runs ZNP 3.0.2 firmware.

I have enabled "legacy mode", in order to allow non-Zigbee 3.0 device to join the network. (did this using MT APP_CNF_BDB_SET_TC_REQUIRE_KEY_EXCHANGE(FALSE) command).

A router (network address 0xe053)  was succesfully joined and authorized (directly by the coordinator : see frame 21 from the attached Wireshark capture).

I want to  join a new device through the intermediate 0xe053 router.

In order to achieve this, I've sent the MT ZDO_MGMT_PERMIT_JOIN_REQUEST command to the router (see frame 41 from the capture).

The new joining device associates with the router (see frame 48 and 52 from the capture). After this, the router sends a UpdateDevice command to the coordinator/trust center, which does not authorize the device, but instead it instructs the router to  kick it out of the network (frame 58).

Is this the expected behavior ? How can I authorize the device in this scenario ?

If the joining device associates directly with the coordinator, the joining device is authorized (see frame 129, 133, 135 from the capture).

Regards,

Eugen

5238.MultihopJoining.zip

  • 0
    TI__Mastermind 35070 points

    Hi,

    This is because the Trust Center (ZC) has permit join turned off.

    If you turn on permit join for the ZC, then a join through a router should work correctly.

    However, if the joining device is in radio range of the ZC, then it may consequently join the ZC instead. You could move the joining device physically further from the ZC.
    Or, if you are using a CC253x EVM, then to specifically test a joining device not joining directly to the ZC, you could do something like the following:

    We know that ZC always has a short address of 0x0000. When a joining device receives a beacon, a beacon indication is passed up from the NWK layer to ZDApp (see ZDO_beaconNotifyIndCB). The beacon indication (data type of NLME_beaconInd_t) has a sourceAddr field. In the function ZDO_beaconNotifyIndCB, the joining device could then discard the beacon sent by ZC. This will cause the joining device to join the network only through routers.

    Regards,
    Toby

  • 0 in reply to Toby
    Prodigy 100 points

    Hi Toby,

    Thank you for your answer.

    One more question please: when one opens a network for joining, is it necessary to explicitly instruct all the routers from the network to allow joining ?

    (like sending them a  MT ZDO_MGMT_PERMIT_JOIN_REQUEST for example)

    Thank, you,

    Eugen

  • 0 in reply to neugen
    Guru 735685 points

    When one opens a network for joining, it is not necessary to explicitly instruct all the routers from the network to allow joining but we usually do this.