Zigbee routing feature problem

[Mateus Vesuvious]

Hi guys, 

 So i have some Nordic DK board including some dongles, NRF52840 DK, NRF52833 DK running with Zigbee and thread SKD 4.1.0 and make a mesh out of them. But I have this problem with mesh topology in Zigbee relating to route discovery. I did 2 experiments

1.The first experiment is set up like this figure 

So I have a mesh of devices including some zigbee routers and 1 coordinator like in (1). I tried to move the router 1 on top away from the coordinator so that it is out of range and would send a message to the coordinator through a hop in the middle like in the (2) . From what i learn in the zigbee spec, the router will try to fix and create a new route if the destination is unreachable. I use a sniffer to monitor the network but i did not see any route request sent even after 3-4 minutes. Then, I reset the device but still nothing happened. So how can I make a out of range router to rebuild a route to the coordinator. Is it suppose to make a new route when the destination address is not in the routing table.

2.The second experiment i did is that I create a mesh with 1 coordinator and 4 routers like the figure below 

So this time, i managed to make router 1 to join through router 2( which is near router 3) and send message to coordinator like in (1). But the problem is that, when i turn off router 2. In theory Router 1 should re route to path (2). But it did not, when it sent out the message, it kept sending to the addr 0x0000 and not start to send any route request. This time i also waited for 4 minutes and reset every device in the network. But still nothing happened. 

For the firmware inside, I ran Cli zigbee example coordinator and ran a custom firmware from light bulb example on all of the routers. I will attach the firmare at the end so that you can take a look at it with all the SDK config and makefile 

Thank you for any help, the code for router is included below 

Mateus 

light_bulb.zip

[tomchy]

Hello Mateus!

Could you point out the section inside the spec that obliges the router to keep an active route to the coordinator?

I was just thinking - could you configure a periodic reporting on the mobile router and rerun your tests? The CLI sample already has all required commands, no recompilation is needed.

The idea here is that sending reports to the coordinator at constant interval will push the router to refresh the route. Additionally - you will see if the router figures out the route, based on other packets.

BR,

Tomchy

[Mateus Vesuvious]

Hi Tomchy, 

Thank you for your answer.

For the first question, may be you misunderstand the figure i do not intend to say that the router should be keeping an active route. But the dash lines just mean that each router is in within the range of each other and it is possible for the router to route pathways along different dash lines . But as i have in the attached code. I only send the data to the coordinator so the   router should find the way to relay the message to the coordinator (a) if the coordinator is not the routing table and (b) if the packet sending not receive an ACK. as in section 3.6.3.5.1 Initiation of Route Discovery of the Zigbee spec line 8981 - 8983. But i do not see that behavior in the test above. 

For the second question, i also tested the configure report a few days ago. I use a the coordinator to bind and then configure the report for every 10 sec, but the result is still the same. Do I have to lower the time to even more to see the route discovery faster? 

And for the last question, can you show me what kind of packets to expect to know if the router figure out the route. For me i only know the about route request and route reply but i did not see any of them in either of the test case above. 

Thank you very much, please reply soon.

Best regards, 

PS: I include the spec that i read with this post so you can check if i misunderstand anything.

zigbeealliance.org/.../docs-05-3474-21-0csg-zigbee-specification.pdf

Tu 

[Mateus Vesuvious]

Hi Tomchy,

Thank you very much for your support, I will definitely look in to that and try to create a cli cmd for routing table, but i have some question for you about zigbee.

So tell me if i am wrong but after receiving route reply, the node will add the new route to the coordinaotr into the routing table and the status for that entry is going to be VALIDATION_UNDERWAY and then being used as the new path. And I just want to know what will happen if it receive a link status directly from the coordinator, Will it update the neighbor table and started to send directly to the coordinator. So in order for the route resquest to be initiate, the router should be completly out of range with the coodinator in both direction right?  

And Some time when i Turn on the many to one request, after the router can establish a new path, there is also a problem that the node go back to send directly to the coordinator withou using the new path it create. It looks like it reset the routing table somehow. Can you guess why it is happen.

Thank you and have a good day, I have attach a sniffer with it so you can look for any problem 

Problem with link status.pcapng

Mateus

[Mateus Vesuvious]

Hi Majeris, 

Thank you for your reply, i have managed to make a route request happen. But I have some questions to ask, 

So if the router 1 create a new route to coordinator but after that it receive a link status from the coordinator. Does it going to send the next packet by the new route through another router or going directly to the cordinator. In my experiment, I have this problem that after a few time making a new route, the node keep sending data to the coordinator directly. So I will a packet sniffer to you so you can take a look at it.

And I also have an other similar question with many to one request, as far as i know, It will tell the routers to reserve an entry for sending the data to the collector (which is in my case is the coordinator, right?) and the router when it send somethinng will send a route record to it to send. But when I try it, routers did not send anything, instead, after a while of sending data through the new route, when MTORR hit, the router go back to use the direct path. Can you guess why it happen?

Thank you very much, hope to hear from you soon and have a nice day,

Here is the capture 3704.Problem with link status.pcapng

Best regards,

Mateus

[Mateus Vesuvious]

Hi Marjeris, 

Do you have any explanation about why the connection is broken after just being formed? I have something to ask you

I use the api that you gave me to log the neighbor table and the routing table to debug the problem, And it is look like router can still receive the link status message one in a long while. So i have logged the tables out, i can see 0x0000 is still in side the neighbor table even when the router can not send anything to the coordinator. The entry is always their even with a very low LQI (like under 15) so i guess the router still see the coordinator as its neighbor and keep sending directly. But it is just my theory and since i can not find any thing on the zigbee spec for that. I want to ask you. 

1.If an entry is available in neighbor table, is it true that the node will send the message directly to the address of that entry without looking at the routing table. 

2. When a new path is formed, what is the behavior of the node if it receive a link status, will it prioritize the neighbor table and not use the corresponding entry in routing table

3. If it is the case, can you point out some ways for me to avoid this?

Thank you and please reply soon,

Best regards, 

Mateus

[Mateus Vesuvious]

Hi Majeris, 

Is there any update on the problem I had?

I have some other things to update to you. So when I printed out the neigbor table and then check the link status, I can see that they are not really the same. Usually, the link status will lack some addresses from the neighbor table. And because i also print out the aging parameter of the node to log, I am pretty sure that all of the missed addresses are still exist (since their aging keeps changing with every 15s) I want to know if this is a normal behavior of the node or is it an uncommon things to see. 

Thank you very much, please let me know if there are some new update. 

Best regards, 

Mateus

[Marjeris Romero]

Hi Mateus,

I am very sorry for the lack of reply here. First thing, I will need a network key for reading the data from the packets in the sniffer trace you sent to me. If you start the sniffer trace before the network is formed this network key will be stored by wireshark automatically, but if the sniffer trace is started later on you should have a network key available to decode the sniffer traces. Right now the packets on the sniffer trace is undecoded:

And can we have a summary of the latest questions you have asked for this ticket? And what scenario (1 or 2 on the figures above) are we talking about? I need to try to summarize the inquiries in this ticket to past them to our developers.

Mateus Vesuvious said:

I have some other things to update to you. So when I printed out the neigbor table and then check the link status, I can see that they are not really the same.

Here I wouldn't expect it to be the same.

Link Status commands are use to keep track of route symmetry. A router will send out a radio 1 broadcast to indicated link status. All the neighboring routers keep track of these messages to determine which routers can hear them and which routers they can hear. So you can have more addresses in the neighbor table withot having them listed in the Link Status command.

While the neighbor table contains information on every device within transmission range, you can have entries in the neighbor table with value of 0 for outgoing cost field if no link status command listing from this device has been received.

The age field indicates the number of nwkLinkStatusPeriod intervals that have passed since the last link status command frame was received, up to a maximum value of nwkRouterAgeLimit.

More information about the neighbor table can be found in the Zigbee specification:
docs-05-3474-21-0csg-zigbee-specification.pdf

Best regards,

Marjeris