• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 55 subscribers
  • Views 422 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

LAUNCHXL-CC26X2R1: Coordinator still keeps using invalid source route

Koen Kanters
Intellectual 925 points
Part Number: LAUNCHXL-CC26X2R1

In  https://e2e.ti.com/support/wireless-connectivity/zigbee-and-thread/f/158/t/883629 I reported an issue where the coordinator keeps on using an invalid source route. Ryan provided a snippet there which seemed to fix it (but I'm not 100% sure). The fix has been integrated into  Simplelink 4.20.00.35 and therefore shouldn't be needed anymore, was confirmed in https://e2e.ti.com/support/wireless-connectivity/zigbee-and-thread/f/158/t/924576 .

Today I had the issue again with a Philips hue outdoor motion sensor.

The following happens: the hue sensor (0xd8cd) send a network request to the coordinator, the coordinator replies. One of the routers (0x548f) in the source route reports the source route as invalid.

Since the hue sensor did not receive anything yet it keeps sending the network address requests but the coordinator keeps replying with the invalid source route (even after +- 2 seconds!)

  • 0
    TI__Guru**** 208497 points

    Hi Koen,

    In the case of a NWKSTAT_SORUCE_ROUTE_FAILURE, ZDO_ManytoOneFailureIndicationCB should be called which in turn executes RTG_MTORouteReq from zd_app.c.  This will send a MTO Route Request to the network as I see in your first screenshot, which is the resultant action from the referenced E2E posts.  Is this response never returned?  You can modify ZDO_ManytoOneFailureIndicationCB to fit your application requirements.

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Intellectual 925 points

    I've accidentally forgot to save my sniff so I'm unable to check this. I will wait until the issue appears again and provide a full sniff.

    Nevertheless, I would expect an invalid source route never to be used again. I see the ZDO_ManytoOneFailureIndicationCB() does not have any parameters, how can I determine the invalid source route from there? I want to do something similar to the snippet I provided here: https://e2e.ti.com/support/wireless-connectivity/zigbee-and-thread/f/158/p/883629/3270956#3270956 (delete the invalid source route from the routing table and discover a new one).

  • 0 in reply to Koen Kanters
    TI__Guru**** 208497 points

    The default action is as explained and as such does not remove the route unless there is a new route to replace it with.  You can place your other code into ZDO_ManytoOneFailureIndicationCB if you desire a different action to be taken.

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Intellectual 925 points

    Hi Ryan,

    I'm a bit confused here. I would only expect ZDO_ManytoOneFailureIndicationCB  to be called when a "Network status: many-to-one-failure" is received. This is not the case here as a "Network status: source route failure" is received here. Why is ZDO_ManytoOneFailureIndicationCB  called on a source route failure? It sounds more logical to call ZDO_NetworkStatusCB here. In  https://e2e.ti.com/support/wireless-connectivity/zigbee-and-thread/f/158/p/883629/3268664#3268664 you mentioned that ZDO_NetworkStatusCB  is called upon a source route failure.

    Regards,

    Koen

  • 0 in reply to Koen Kanters
    TI__Guru**** 208497 points

    Hi Koen,

    NLME_NetworkStatusCB -> ZDO_NetworkStatusCB is also called for every statusCode (like NWKSTAT_SOURCE_ROUTE_FAILURE) inside NLME_ProcessNetworkStatus, so it is perfectly acceptable to keep your code here as well.  The developer is given freedom to choose which action to take upon detection of a source route failure.

    Regards,
    Ryan