• State
  • Locked Locked
  • Replies 12 replies
  • Subscribers 58 subscribers
  • Views 2168 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.

ZigBee route requests forward issue

Boer Wei70
Prodigy 10 points

Other Parts Discussed in Thread: Z-STACK

Hi All,

We meet a weird situation that a router does not forward route requests. The topology is shown as below.

ZC --- ZR1 (0xE065) --- ZR2 (0x8866)

Both of ZC and ZR2 issue a route request (radius=5) but ZR1 doesn’t forward those requests.

I don't know why?

Please help to check this issue.

Thank you.

Boer Wei

 

 

 

  • 0
    Guru 735695 points
    Which Z-Stack version and example does your test use? If possible, please describe your test steps in detail and attach your sniffer log (not screen capture).
  • 0 in reply to YiKai Chen
    Prodigy 170 points
    We are using HA v1.2.0 with Zstack v2.6.1 and using source routing scheme. The test procedures are shown below.

    Step1. Power on ZR1 and wait it joined to ZC. If it is joined to the network, go to step2.
    Step2. Power on ZR2 and wait it joined to the network via ZR1
    Step3. Power off ZR1 and ZR2 then repeat step1.

    Sorry, I don't know how to attach log file on it.

    CYLin.
  • 0 in reply to YiKai Chen
    Prodigy 170 points

    Attach the log file.no_relay.zip

  • 0 in reply to CYLin
    TI__Genius 9325 points
    Hi CYLin,

    Can you please provide me with the TC link key and the network key that were used in the log so that my Ubiqua can decrypt it?

    - Cetri
  • 0 in reply to Cetri
    Prodigy 170 points

    It only needs network key and it is "0x12 0x34 0x56 0x78 0x90 0x12 0x34 0x56 0x78 0x90 0x12 0x34 0x56 0x78 0x90 0x12"

    CYLin.

  • 0 in reply to CYLin
    TI__Genius 9325 points
    Hi CYLin,

    It is observed that the network frame counter of all the packets from 0x8866 is 0xFFFFFFFF(4294967295) which is the maximum value. The ZC and 0xE065 cannot accept any packet from 0x8866 because the network frame counter has never incremented since it sent Device Announce(which seems missed by the sniffer).

    Do you have any different configurations on 0x8866 from those on 0xE065? I have never seen the case where network frame counter naturally reaches the maximum value. Can you factory reset 0xE065 and retry?

    - Cetri
  • 0 in reply to Cetri
    Prodigy 170 points
    Since we don't enable NV_RESTORE in this project, we find the network frame counter is a key point that receiver drop the packet if its counter is less than the previous one recorded before. Thus, we'll raise this counter to maximum value when the node start to send data at application layer.

    1) How to maintain this frame counter if we don't enable NV_RESTORE?
    2) How does following two variables work in the stack?
    a. nwkFrameCounter
    b. nwkFrameCounterChanges
    3) How to determine the two definitions below?
    a. MAX_NWK_FRAMECOUNTER_CHANGES
    b. NWK_FRAMECOUNTER_CHANGES_RESTORE_DELTA

    CYLin.
  • 0 in reply to CYLin
    Guru 735695 points
    frame counter is used for manipulating message transmitting between sender and receiver. You shouldn't change it in your application.
  • 0 in reply to CYLin
    TI__Genius 9325 points

    CYLin,

    If you are using security and you power cycle the device, NV_RESTORE should be on. If you never power cycle the device, you don't have to set NV_RESTORE.

    In any case, nwkFrameCounter should NOT be manipulated by the application as Yikai mentioned. I wouldn't recommend making any changes on the variables and the definitions you listed.

    - Cetri

  • 0 in reply to Cetri
    Prodigy 170 points

    We have already enabled the NV_RESTORE and the symptom still the same. The attached file is captured by Wireshark and the topology is shown below. You can see the route request packet (src=0x15aa) from No.236 to No.280 that does not re-broadcast by ZR1. Do there still have anything wrong?

    Topology:
    ZC - ZR1(0x7737) - ZR2(0x15aa)

    Test procedures:
    Step1. Turn on ZC.
    Step2. Turn on ZR1 and waiting ZR1 join the PAN. ZC can receive data from ZR1.
    Step3. Turn on ZR2 and waiting ZR2 join the PAN. ZC can receive data from ZR2.
    Step4. Turn off ZR1 and ZR2
    Step5. Repeat the step 2 to step 4.

    PS. The network key is the same as previous one.

    RelayIssue.zip
    CYLin.

  • 0 in reply to CYLin
    TI__Genius 9325 points

    Hi CYLin,

    The last issue is a totally irrelevant with the original one of this thread. However, it is a known issue.

    In current implementation of Z-Stack, if the concentrator have done MTO route discovery and the routers have gotten the routes targeting the concentrator as a result, the routers will ignore route requests from another router looking for the concentrator because they suppose every router in the network has the MTO route entry associated with the concentrator.

    In your case, the ZC initiated a MTO route discovery at #233. That was repeated by 0x7737 at #234. Than means 0x7737 got to have the MTO route entry targeting the concentrator(ZC). I guess 0x15AA was powered off so didn't receive the MTO route request. After a while, 0x15AA came back and sent out a route request looking for the ZC at #236. 0x7737 was able to hear that message but ignored because the destination of the route request was the concentrator. This problem lasted until the concentrator issued another MTO route discovery(#281) and 0x15AA received it(#283).

    Although this problem is seen only temporarily until every router receives MTO route request, I agree it brings inconvenience. So we have removed this constraint and therefore the new version of Z-Stack(coming up in a few weeks) will be behaving as you desire.

    - Cetri

  • 0 in reply to Cetri
    Prodigy 170 points

    We have migrated the Z-Stack to v2.6.3 and also did the same testing in the past few days. The route request will be re-broadcast by intermediate router (0xa1f5) at this Z-Stack version. But it sometimes still ignored by intermediate router. The attached file is the packet for you reference. 

    Topology:
    ZC - ZR1 (0xa1f5) - ZR2 (0xe1f9)

    Network Key: 
    22222222222222222222222222222222

    wireshark_bad_log.zip

    CYLin.