• State TI Thinks Resolved
  • Locked Locked
  • Replies 2 replies
  • Answers 1 answer
  • Subscribers 56 subscribers
  • Views 216 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.

CC1352P: Excessive Route Request

Bill Kuckuk
Expert 1305 points
Part Number: CC1352P

We had asked this same question on the old 1.2.2 stack, but I'm going to ask it again.  Why does a ZC/ZR send so many un-needed route request?

Please see the attached word doc and wireshark capture.  

/cfs-file/__key/communityserver-discussions-components-files/158/RouteRequest.zip

  • 0
    TI__Mastermind 28440 points

    Hi,

    Thanks for attaching a detailed analysis and sniffer log.

    We will investigate and get back to you next week.

    Regards,
    Toby

  • 0
    TI__Guru**** 202256 points

    Hi Bill,

    I have been able to recreate the issue and determined that it is due to route reply processing finding the neighbor table entry but not updating it with new path cost information as is accomplished during link status processing.  That is why additional route requests are sent regardless of route replies returned until a new link status is received.  The code's logic may best be explained due to the fact that route requests must expect multiple hops (i.e. the destination node may take several hops and not be immediately accessible) whereas Link Statuses directly apply to neighboring devices.  Fixing this would require altering the pre-compiled Zigbee source libraries and I have submitted a bug investigation to the Software Development Team.  I will let you know if/when this is achieved for an upcoming SimpleLink SDK release.

    Regards,
    Ryan