-
-
Notifications
You must be signed in to change notification settings - Fork 162
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
Bonded clients do not work when switching from 1.4.2 to 2.0.0 or vice versa #740
Comments
It appears this may be a result of upstream changes in the way the data is stored in NVS, I haven't identified the changes yet but it may just have to be another part of the breaking changes coming with 2.0.0 release. |
@KlausMu I have identified the cause of this issue and it was an intended change, that is also a good one. |
Ok, thanks. Do I understand correctly: Going from 1.4.2 to 2.0.0 Going from 2.0.0 back to 1.4.2 |
Correct, this basically changes the device identity.
The NVS partition will still have that IRK, the old firmware will not be aware of it. I can't say for sure what the crashing is, I would need to test it. I suspect it's due to the different data stored in NVS due to the IRK change. Best bet is to erase the flash because the NVS format will have been changed. Or at least erase the NVS on boot. You could do this by writing a version parameter or something and detecting it. |
@KlausMu I have created a way to detect the downgrade and only erase the NimBLE bond storage info instead of the entire NVS.
Give that a try and let me know. |
@h2zero I think this could be useful, but I am not 100% sure which cases your code covers. So when exactly is I did some tests, and I think I understood the following: rpa_rec_1 local_irk_1 Overall, I think the following pseudo code could be used:
Do you think this is correct? |
Both of those keys are only present in version 2.x (nimble core 1.5), so in your app you can use the code I provided to detect if they exist and erase the bonds if found. I'd put this right at the beginning of setup, before any NimBLE calls. |
Ok, they are only set by 2.0.0. And if I am in 1.4.2, I should simply delete the bonds (and these two blobs) in any case. But I think the first part of my code (detect upgrade from 1.4.2 to 2.0.0) should be correct, right? |
Yes, that would be correct as well. |
Ok, I'll test it in more detail and give feedback here. Thanks! |
Two more questions: Question 1 Question 2 |
@KlausMu You can check for
I can't think of any way to clear the RAM other than reset. |
Finally, I got it working. Both when upgrading from 1.4.x to 2.0.x, and when downgrading from 2.0.x to 1.4.x.
|
I am using NimBLE with an ESP32. It seems the way bonded clients are stored in NVS changed from NimBLE 1.4.2 to 2.0.0.
Going from 1.4.2 to 2.0.0
In 2.0.0, I can connect to an already bonded peer (which was bonded in 1.4.2). Even direct advertisement works (see #651)
But when sending data, the result is
Normally, in version 1.4.2, when sending data, there is something like
As a result, I have to delete all bonds in 2.0.0 and to repair them. From that on, everything works as expected.
Going from 2.0.0 to 1.4.2
When going back from 2.0.0 to 1.4.2, the software crashes at
If there was no bonded peer in 2.0.0, going back to 1.4.2 works without problem.
The text was updated successfully, but these errors were encountered: