• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 55 subscribers
  • Views 1543 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 keeps using invalid source route

Koen Kanters
Intellectual 925 points
Part Number: LAUNCHXL-CC26X2R1
Other Parts Discussed in Thread: SIMPLELINK-CC13X2-26X2-SDK, Z-STACK

I'm experiencing a problem where the coordinator keeps on using a source route which is marked as invalid by the network.

The simplelink version is: SIMPLELINK-CC13X2-26X2-SDK_3.30.00.03 and is compiled with the following options: https://github.com/Koenkk/Z-Stack-firmware/blob/master/coordinator/Z-Stack_3.x.0/firmware.patch#L86

When the coordinator has a source route to an ED and the ED switches to a different parent, the coordinator keeps on using the invalid source route.

Example:

The ED (0xe9a3) does broadcast network request

The coordinator (0x0000) responds to this request which includes a source route

The old parent of the ED (0xe064) indicates to the coordinator that the source route is invalid and responds with a Source Route Failure

As the ED did not receive a response to the network address request, it sends the request again, but the coordinator responds with the same source route resulting in another Source Route Failure indication by 0xe064. This sequence repeats itself a few times but the coordinator keeps on using the invalid source route.

If the coordinator receives a source route failure indication I would expect one of the following to happen:

- The coordinator rediscovers the route and resend the response (in this case the network address response)

- The coordinator removes the invalid source route from the source routing table. Therefore the next time it sends a request to the device it will rediscover the route.

  • 0
    TI__Guru**** 208507 points

    Can you please provide the full sniffer log?  Reception of NWKSTAT_SOURCE_ROUTE_FAILURE is not acted upon inside of the Z-Stack pre-build libraries but you can detect it inside ZDO_NetworkStatusCB.  Then you would remove the existing route with RTG_RemoveRtgEntry and initiate a route discovery with NLME_RouteDiscoveryRequest.  I would expect the route to be updated regardless after a maximum of 120 seconds (CONCENTRATOR_DISCOVERY_TIME).

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Intellectual 925 points

    Thanks for the suggestion Ryan. I don't prefer to share my sniff publicly so I've send it to your TI mail.

  • 0 in reply to Ryan Brown1
    Intellectual 925 points

    I've changed the code to the snippet below, will let you know the results in 1 or 2 weeks (because it takes some time for the problem to arise)

    void ZDO_NetworkStatusCB( uint16_t nwkDstAddr, uint8_t statusCode, uint16_t dstAddr )
{
  (void)dstAddr;     // Remove this line if this parameter is used.

  if ( (nwkDstAddr == NLME_GetShortAddr())
      && (statusCode == NWKSTAT_NONTREE_LINK_FAILURE) )
  {
    // Routing error for dstAddr, this is informational and a Route
    // Request should happen automatically.
  }

  if ( (nwkDstAddr == NLME_GetShortAddr())
        && (statusCode == NWKSTAT_SOURCE_ROUTE_FAILURE) )
  {
    // Received a source route failure, remove route and rediscover.
    RTG_RemoveRtgEntry( dstAddr, 0 );
    NLME_RouteDiscoveryRequest( dstAddr, 0x8, 30 );
  }
}