Hello,
We're developing an LPN product that will leave the mesh and stay off the mesh for up to 3 days (possibly more). When it rejoins the mesh, the central server/gateway could have some resets in between.
Is there a chance the IV index will prevent the nodes from communicating once reconnected to the mesh?
I am looking at this thread and wondering how much is safe to change:
https://devzone.nordicsemi.com/f/nordic-q-a/80558/bt-mesh-iv-update-parameters-timers
Thank you
Hi,
IV Index update can only happen once every 192 hours (8 days). This means you should have no IV Index related issues if away from the network for 3 days. If the IV Index of the node is lagging too far behind for an IV Index update, the IV Index Recovery procedure will kick in, up to around 40 IV Updates behind. If further behind the node is unable to rejoin the network and must be reprovisioned.
If you experience issues after a week away from the network, then there might be some issues with the IV Index Recovery procedure. After around 10 months you risk enough IV Index updates to have passed for the node to have completely lost the network.
Regards,
Terje
"If you experience issues after a week away from the network, then there might be some issues with the IV Index Recovery procedure."
If this event happens what can be done to recover the IV index? Is there a method of manually triggering it? I've noticed some units stop talking all together to us after a couple of weeks separated but some messages do manage to come back through (mainly those sent by the LPN, not the other way). The only fix I've found is unprovisioning and reprovisioning once it starts up the advertisement. This likely won't be acceptable to our users so I'm hoping there's a safe way to send out the secure beacon, or increase the rate it goes out such that the scenario is less likely to happen.
From the link I posted they make a few suggestions about updating some defines.
NETWORK_MIN_IV_RECOVERY_INTERVAL_MINUTES or even set it to zero for debugging purposes so that a node won't wait for timeout to run the IV Index Recovery procedure. (will this prevent said scenario from happening?)
Our units are battery powered and have seasons where they're in use and not in use. If the whole mesh was powered off for up to 6 months at a time, would this pose any issue? I'm thinking we need a "storage mode" that would prevent the IV updates from happening.
I think I need to clarify the scenario a bit better:
"IV Index update can only happen once every 192 hours (8 days). This means you should have no IV Index related issues if away from the network for 3 days."
What could happen with our device is that it goes out of the mesh for 3 days, comes back, *maybe* talks back and forth with the server (sending stuff like battery level back), and then goes out of the mesh.
A schedule could look like this (and why the 8 days is concerning)
Day 1: Out of the mesh
Day 3: Back on mesh briefly,leaves again
Day 6: Back on mesh briefly,leaves again
--Day 8: IV update happens--
Day 9: Back on mesh but can no longer communciate as IV is now out of date
Hi,
Alex Ross said:How can I be sure I'm sending out a secure beacon?
I highly doubt there could be any issue there, but if you could sniff the network traffic (e.g. nRF Sniffer) or provision a DK into the network with a mesh applicaiton logging network activity.
Alex Ross said:Essentially I have a switch that when triggered, the client sends a notification over mesh to the server. This works, I can see the message come in on the server. However, sending messages down to the client are being ignored.
This sounds a bit weird. How are the messages addressed? Are the proper appkeys bound to the models and used for the publication? I agree, if messages go one way this is most likely not an IV Index issue.
For confirmation of my assumptions, the LPN is what you refer to as the client, and the gateway is what you refer to as the server? What mesh models are you using?
Regards,
Terje
"I highly doubt there could be any issue there, but if you could sniff the network traffic (e.g. nRF Sniffer) or provision a DK into the network with a mesh applicaiton logging network activity."
I'll try both of these things. I can add another client and output what it sees. Can you tell me what function triggers the secure update so I can add a log output?
"This sounds a bit weird. How are the messages addressed? Are the proper appkeys bound to the models and used for the publication? I agree, if messages go one way this is most likely not an IV Index issue.
For confirmation of my assumptions, the LPN is what you refer to as the client, and the gateway is what you refer to as the server? What mesh models are you using?"
Correct, client = LPN.
In the nRF Mesh app I can refresh TTL, and I've verify they've subscribed to the correct groups and publish to the correct group. I even see it add itself as a friend to the server, however nothing I do seems to make it's way down to it.
I'll try out the nRF Sniffer and see what I can find. My other thought was to override the IV index to something higher and see if I can trigger an IV update in test mode that way.
The model is based off of the generic on off but modified for an 8 byte message.
It's worked pretty well for a while now, it just seems occasionally something really weird happens and the messages get rejected in some fashion.
Okay so now I'm getting somewhere.
I overrode a client's IV index to be 42 (within). This caused by server to update to IV index 42 as well, now I can see all of my nodes again (friendship succeeded, I see them all), however, even the client can't send a message to the server anymore. When they're both fresh, no problem, however once the IV update happens, the two are unable to send messages to each other anymore (I have verified with a log output message that the IV index is correct and matches.)
The other funny part is that once I have the IV index "hacked" I can no longer get the TTL information from the app either. That is to say:
-Start with default IV on server, TTL can be loaded in nRF Mesh App
-Provision, things look good, TTL refresh still works
-"Hack" IV to match locked up friends
-Now the server is friends with the locked up clients, however button presses aren't working
-TTL loading doesn't work either
-It seems as though it's stuck in NET_STATE_IV_UPDATE_IN_PROGRESS mode as well
Basically I need a way to hack the IV index in the most expected of ways such that the TTL refresh in the app still works. I also have the client in the same configuration, and again, I can't load the TTL. It almost seems as though an IV index of any non zero value and the app doesn't work with it.
Does the nRF Mesh app for iOS have it's own IV index?
Any suggestions?
I'm pretty convinced me screwing with the IV index is messing with the sequence number and now nothing gets through anywhere
Should I open up a new issue for this?
Should I open up a new issue for this?
