-
Notifications
You must be signed in to change notification settings - Fork 641
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
No route available #225
Comments
Can you try with a different router? |
0x8fb9 - HEIMAN, HS1RC-N, 2017.12.5, EndDevice //====== TEST 1 //====== TEST 4 //====== TEST 5 According to the test results, it turns out that the behavior of Heiman and Aqara is the same. I also ran the same tests with a router on the latest nxp firmware for JN5169 (https://www.nxp.com/docs/en/application-note/JN-AN-1216.zip). used JN5169XK010 debug board //====== TEST 1 //====== TEST 4 //====== TEST 5 I will try to find routers on other chips. While doing tests, I found strange behavior with the Heiman button and Ikea light bulb, but that's for later :) I understand that most likely the problem is on the side of the router, but test 5 shows that this can be somehow bypassed using the Many-to-One Route Request. |
After turning on the flashed coordinator, the devices could not establish routes for more than 2 hours. Zigbee network was down. Then the coordinator changed in his route request and everything worked out. Before packet 6571, the coordinator sent a Route Request with the Path Cost value: 0. No one from the device answered it. |
Sorry, I jumped to conclusions. |
Nice finding, I think we should also store the frame counter in the backup, do you know if it is in the NV? |
The NWK FrameCounter is stored in the ZCD_NV_EX_NWK_SEC_MATERIAL_TABLE table. (id 0x7). |
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days |
I found what the problem is. coordinator_backup.json
The frame counter is stored in ZCD_NV_LEGACY_NWK_SEC_MATERIAL_TABLE_START. After each cold restart of the coordinator, the counter is increased by +1250. The counter is incremented with each packet issued. Therefore, there are times when you have to wait several hours for the network to work. Just increasing the counter The frame counter is needed to protect against packet reuse. Routers ignore packets from the coordinator if its frame counter is less than it was before. Some routers store the frame counter in RAM, so after a reboot they have 0 values and receive packets from the coordinator with any frame counter. UPD. I don't have a backup file for 2652 right now. I specified a backup file from 2538. But the meaning is the same. |
I am working with CC2652P (sdk_4_20_01_04). Stick from t.me/Egony
After flashing the stick, I get the following situation every time:
0x8fb9 - HEIMAN, HS1RC-N, 2017.12.5, EndDevice
V
0x4590 - HEIMAN, HS2SK_nxp, 2017.12.5, Router
V
0x0000 - CC2652P, Coordinator
//====== TEST 1
[6] 0x8fb9 sends information to its parent 0x4590 on the pressed button;
[8] 0x4590 requests a route to the coordinator 0x0000;
[9] the coordinator responds;
[13] Router 0x4590 replies to 0x8fb9 that no route was found;
Recording in file no_route_available_30102020.pcapng
I am confused by "Path Cost: 3" in Route Reply. Can the router discard this route due to cost? And why is it 3?
//====== TEST 2
In the file set_state_30102020.pcapng,
I change the state of the router (socket) from z2m.
As you can see, the router does not respond to the route request and to the direct command for reading the attributes, which contains the router's short address.
//====== TEST 3
change_state_30102020.pcapng file.
I press the button located on the router (socket) to change the state of the relay.
//====== TEST 4
restart_router_30102020.pcapng file
I rebooted the power supply router.
Package 17-18. The route now works. Events from 0x8fb9 also normally reach the coordinator.
//====== TEST 5
And the last file normal_restart_coord_30102020.pcapng.
I turned off the coordinator for a couple of minutes, pressed the button of the end device several times, so that the router would lose the route to the coordinator, and then turned on the coordinator and started z2m (package 145). The packet 160 shows that the route was built normally.
My link key 01:03:05:07:09:0B:0D:0F:00:02:04:06:08:0A:0C:0D
issue_route_30102020.zip
The text was updated successfully, but these errors were encountered: