-
Notifications
You must be signed in to change notification settings - Fork 51
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
Enabling RPA causes bonding failure #8
Comments
I just posted a PR that directly fixes this, checkout #7. |
Hi @duncairn Thank you for raising the issue, I can understand that the documentation needs to be improved for this. However we have tried to summarize the functionality in README of
Can you please provide sdkconfig as well ? It would be really helpful to get DEBUG prints in the log ( |
Thanks for getting back to me quickly on this, @prasad-alatkar , and I apologize for not digesting the readme properly - I had mistakenly looked at the readme from the previous version, hence why I missed the instructions. I made the changes you suggested in bleprph_on_sync():
Unfortunately, that was a small improvement. The phone would connect and pair OK first time now, but on disconnect and reconnect the ESP would show up as a different device, leaving the phone trying to connect to a device that was no longer there. The log for this is: I left the previous additional log entries in place for reference, and at suitable pauses (such as when waiting for the phone to accept the user's pair command) grabbed a store peer count as a marker. I then made the mods that @h2zero had made in checkout #7 (thanks - well timed!). Now I could disconnect and reconnect, and still access characteristics. Great! The log for this: I then rebooted the phone to force an address change, and on trying to reconnect it failed with no access to characteristics (here is the continued log from the previous - the ESP wasn't restarted during this): Summarising, the own_addr_type fixed the first connect problem, but would cause the ESP to appear as a different device on disconnect/reconnect, @h2zero 's mods fixed that and got me back to where I was originally without RPA but now with RPA. So it's an improvement but still not working. For completeness, as requested: |
The
Comapre it to yours and give it a try, I had no issues this way. |
@duncairn After taking a look at your logs, I was also a bit confused as why it works for me and not for you. Nevertheless I think I have found the issue, and again I need to be blamed for the poor documentation for this. The issue you are facing is the phone device is not able to resolve the RPA of ESP32. Now if everything else is good, it can only happen when the phone device does not have IRK of our device. This IRK is distributed during key exchange (after pairing). To distribute IRK we have to mention in our host configuration ( @h2zero Thank you for taking time out and contributing to esp-nimble, I had taken a very quick look at your PR. I will update there my observations, I just think the check |
Thanks for trying again, @h2zero .
Unfortunately, this didn't work at all since it would fail when trying to advertise (rc = 530). I tracked it down to this line: `rc = ble_hs_id_infer_auto(1, &own_addr_type); The '1' was the cause. Changing back to 0 gets it advertising again, but of course then we're back to the start. @prasad-alatkar - I applied your patch (not your problem that I failed to read the instructions at the start!) but it seemed to make no difference. That is, disconnect/reconnect work fine, but phone reboot and change of address fails. However, I am doing this using the patch that @h2zero provided in #7, so will revert to the pre-patch version and see if it works in that. Do you need logs for this? |
Hi @duncairn by change of address, Do you mean 'The phone (scanning app) observes same address of ESP32 (paired previously) ' ? If that is the case then we are good. I mean, you can observe the new address from another phone device (scanning app). Apart from that you can configure RPA timeout (time after which new RPA address is assigned) from menuconfig, by default it is set to 900 seconds. |
Ah, I'm afraid I might be using the wrong terms and confusing things. By 'change of address' I mean the phone's change so the ESP doesn't recognize it as an already-paired central. iOS devices change their public address periodically (not sure how often but I read somewhere it could be every 15 minutes), so to force that to happen when I need it to I just reboot the phone. I am fairly sure the phone still recognizes the ESP since it doesn't ask to pair with it, so whether or not the ESP is changing public address, that part of it isn't a problem for me. The problem is purely that the ESP doesn't recognize the phone after the change of phone public address. Regarding my previous comment, I reverted @h2zero 's #7 patch and retained your most recent patch (of the bleprph example). This time there was no problem with the phone disconnecting and reconnecting, so the issues that enabling RPA provoked (multiple ESP devices appearing, etc) would seem to be down to my changes to main.c. However, the problem of the ESP not recognizing the phone after the phone has been rebooted (i.e. the phone has changed public address, and the reason for enabling RPA) is still there. Hope I haven't confused things further! |
It is possible that scheduler already fired and aux data is NULL so we should unref it only if scheduler item was removed. ble_ll_scan_aux_data_unref (aux_data=<optimized out>) at repos/apache-mynewt-nimble/nimble/controller/src/ble_ll_scan.c:1079 1079 BLE_LL_ASSERT(aux_data); (gdb) bt #0 ble_ll_scan_aux_data_unref (aux_data=<optimized out>) at repos/apache-mynewt-nimble/nimble/controller/src/ble_ll_scan.c:1079 espressif#1 0x0001f732 in ble_ll_scan_rx_pkt_in_on_aux (pdu_type=<optimized out>, om=0x2000d6f8 <os_msys_1_data>, hdr=0x2000d710 <os_msys_1_data+24>, addrd=addrd@entry=0x20004ecc <g_ble_ll_stack+404>) at repos/apache-mynewt-nimble/nimble/controller/src/ble_ll_scan.c:3156 espressif#2 0x0002010e in ble_ll_scan_rx_pkt_in (ptype=ptype@entry=7 '\a', om=om@entry=0x2000d6f8 <os_msys_1_data>, hdr=hdr@entry=0x2000d710 <os_msys_1_data+24>) at repos/apache-mynewt-nimble/nimble/controller/src/ble_ll_scan.c:3198 espressif#3 0x0001299e in ble_ll_rx_pkt_in () at repos/apache-mynewt-nimble/nimble/controller/src/ble_ll.c:837 espressif#4 0x000129de in ble_ll_event_rx_pkt (ev=<optimized out>) at repos/apache-mynewt-nimble/nimble/controller/src/ble_ll.c:1164 espressif#5 0x00012830 in ble_npl_event_run (ev=<optimized out>) at repos/apache-mynewt-nimble/porting/npl/mynewt/include/nimble/nimble_npl_os.h:116 espressif#6 ble_ll_task (arg=<optimized out>) at repos/apache-mynewt-nimble/nimble/controller/src/ble_ll.c:1214 espressif#7 0x00038e9c in nrf52_clock_hfxo_release () at repos/apache-mynewt-core/hw/mcu/nordic/nrf52xxx/include/mcu/cortex_m4.h:37 espressif#8 0x00000000 in ?? ()
So there's a couple things going on here it seems, could you post your on_sync() and app_main() from your file, or the whole file? There are a few things that need to be set correctly for random addresses to work correctly with bonding etc. Also, just a heads up, you can just turn bluetooth off and on on your phone to change the address, no need to reboot. |
For your reference when looking at your logs, this is how mine appear when correct (I do have my patch applied here though). This is with RPA enabled on the esp32. Only difference with it disabled is the Initial connection:
Encrypted/bonded:
Disconnect:
Notice the change of Reconnect:
For completeness here is the code for
One last suggestion is to use Edit: correct log, fix bad edit 😄 |
@duncairn I just tested your file with and without my patch and it works as expected. With RPA on and no patch reconnection and encryption work, with RPA off, when the phone address changes reconnection and encryption do not, must re-pair. With the patch all is well either way. I suspect my note above about |
@h2zero - thanks for persevering with this. I am not seeing what you do, however, even after erasing the flash and clearing the phone pairing info (which I do before each series of tests anyway). Perhaps I should be more explicit and say that after the phone change of address, it will connect with the ESP and apparently resume, but it is not able to transfer data. When it first bonds, and after a simple reconnect, I can access the characteristic that sends a random number back (that is, 5c3a659e-897e-45e1-b016-007107c96df6). When I try this after the address change, I can seem to access the characteristic but nothing is read. Can you confirm that when you try this you really receive a new random number? |
I will try again and see if I can repro what you're seeing, can you confirm for me that you are using the file as posted and are not patched? Edit: To answer your question though, yes I can read a new value each time from the characteristic. I'm going to wait for the esp to change it's address and see what happens then. So far 3 address changes with my phone and no problems. What app are you using? |
I can't run the exact file you posted because I get The app I tend to use is BLE Scanner by bluepixel, but I get the same with BlueSee. [Thinks...] It has to be the own_addr_type variable that is being set inappropriately since it works (that is, the advertisement goes OK) if I explicitly set it as per @prasad-alatkar 's suggestion to BLE_ADDR_RANDOM. I'll dig into this... |
I’ve been using the file you posted actually. Just so we’re on the same page. Try using nRF connect for your phone app. That’s what I’ve been testing with. |
nRF suggests you're using an Android phone? I use that on my Android phone but haven't tested RPA with it yet - the reason for needing RPA was because iOS would constantly pop up the pairing dialog whereas Android, with nRF, didn't. It seemed that nRF (or Android) would just go through the motions of re-bonding without saying anything if there was a problem, whereas iOS wouldn't. |
Just tried with nRF on Android and there was no issue. In fact, I had to closely study the logs to check that the phone had in fact changed its address! On connect after a reboot (I did the BT disable thing but wanted to make sure) I could see that the bonding flag in nRF flicked off and back on, so if there was any problem it was covered up. |
@duncairn Just for a complete answer to your question, after 4 address changes on the esp32 and approx. 8 changes on the phone I am still able to connect and read that characteristic with no trouble. Good news is I found the issue you have with
I am using an iPhone SE as you are, nRF connect has an iOS app as well. Edit: Just a thought but what IDF are you using? I'm testing on the master branch. |
OK! Sorry for making assumptions, and thanks for pointing out nRF is on the playstore - wish I'd found that to start with ;) I changed bleprph_on_synch() to exactly as your post there (a cut'n'paste), but still get the advertisement enabling error, so there is clearly something amiss. I think a re-port of nimble 1.2 into esp-idf might be in order too at this point. |
Lol no need to be sorry, most people here use android phones, natural assumption. It should just popup a message asking to pair when you try to read the characteristic. That error could likely be due to using an older commit of esp-nimble, I would suggest updating to current if needed and try again. |
Sorry for the delay in getting back to you on this - a lot of water has passed under the bridge since! First, I was using esp-idf 4.1 but updated to include nimble 1.2. So I tried esp-idf 4.2 (dev) and that didn't show the advertising error when own_addr_type was 3. The nimble code was exactly the same, the example app also exactly the same, so the implication is that something outside of nimble would be affecting it. (You don't want to know about the trouble that enabling debug-level logging caused on 4.2!) But... still there was the fail on address change. So I tried updating to esp-idf 4.2 (release) but couldn't because my setup wouldn't install the new requirement of gdbgui (it would fail on cffi). This is using msys and make (i.e. the legacy development environment), and previously I'd failed to get the cmake environment to install properly. Maybe that had something to do with things. To make sure it's not my setup, I ran up a brand new fully-patched W7 in a VM and installed 4.2 (release) and the cmake stuff in there. That also failed(!) but eventually I worked through all the workarounds and had a pristine unadulterated 4.2 (release) compiling and programming the ESP. Still, I get the fail on address change! I can't see how it can be working OK for you when it doesn't for me even with a totally clean system. There has to be something else involved which is screwing things. Maybe the phone? This is a iPhone SE running 13.3.1 and the only stuff I've added has been the bluetooth scanners. |
Wow, good effort on your part 👍. Still very strange that you are having such difficulties. I have been using the master branch but 4.2 (release) seems to be on-par with that as far as NimBLE is concerned. Would you be able to post another log? One that shows a connect->bond->disconnect->change address->reconnect? I'm quite curious to see what you do. |
No problem! Attached. This is using an Adafruit ESP32 Feather, just to make sure it's not something about our hardware setup that's causing this. I'll try the master branch later today - any straw is worth clutching right now :) |
Well I can see in your log you are not storing the IRK for either your device or the phone, that's where you need:
from the patch file above that @prasad-alatkar posted. Try that and post another log, there may still be local id address issues after but lets see before we jump in. |
@h2zero thank you for your time and efforts. Just want to touch upon few points here.
Ideally, we should not call So to sum it all, just setting addr_type to
Can you please provide DEBUG log when you see this issue ? Now, if I understand clearly, if the phone has not changed its IRK (identity key to resolve RPA) then even if it changes the address (RPA) the RPA should be resolvable by our ESP device as it has the IRK which is sufficient to resolve identity of the peer device. I have verified the working behavior with Android phone. |
This was resolved by your patch posted early on. I still seemed to have the issue becuase the patch was applied incorrectly, so part of it was inoperative. Entirely my fault, and I'm very sorry for making that mistake and dragging this on. I appreciate the patience exhibited by yourself and @h2zero . That said, do you want logs now it works? I thought probably not, but if you want them for comparison I can run them off :) |
Hi @duncairn happy that the issue is resolved now.
I am quite sure this thread might help few users while implementing RPA feature 😃 |
@prasad-alatkar you are quite right here, sorry for confusing this. I had that in my code while I was testing things and it was working so I shared it here in-case it helped. @duncairn Glad to hear you got it working, definitely a good thread for others in the future. |
@duncairn Please help to close the issue if resolved. |
My apologies @prasad-alatkar - being new to the github way I didn't realise it would be up to me, but it is logical that it should. Done ;) |
Hi i tried this solution it still doesn't work for me. I'm using nimble v1.3.0 |
I am trying to bond en ESP32-based project with an iPhone SE (but this affects any iOS device). Since there is no user input available I specify Just Works, turn on MiTM, etc. It works fine initially - the phone will pair and bond, then on next connect it won't prompt for pairing. I can restart the ESP32 and it is still all fine. However, once the phone decides to change its public address, any connection results in nothing being transferred. The phone must be told to forget about the ESP and go through the pairing/bonding process again.
I gather that Resolvable Private Addresses are the way around this, and that ESP Nimble 1.2 apparently has this functionality, but when I enable it with:
ble_hs_pvcy_rpa_config(1);
pairing/bonding doesn't take place and, typically, if a characteristic is accessed the connection drops. Since the RPA enabling function wasn't too obvious, I am wondering if this is indeed meant to work or if it's not yet ready.
I've attached two logs which show an overview of where it goes wrong. The 'NimBLE' entries I added to trace what storage calls were being made, but left them in since they provide useful anchors. Cutting to the chase, the log where it goes wrong says:
handle=0 our_ota_addr_type=1 our_ota_addr=57:48:b1:82:9f:a8 our_id_addr_type=0 our_id_addr=4c:11:ae:c9:53:de peer_ota_addr_type=1 peer_ota_addr=4f:9d:c9:74:79:0b peer_id_addr_type=1 peer_id_addr=4f:9d:c9:74:79:0b conn_itvl=24 conn_latency=0 supervision_timeout=72 encrypted=0 authenticated=0 bonded=0
where the good (non-RPA) log says:
handle=0 our_ota_addr_type=0 our_ota_addr=4c:11:ae:c9:53:de our_id_addr_type=0 our_id_addr=4c:11:ae:c9:53:de peer_ota_addr_type=1 peer_ota_addr=4f:9d:c9:74:79:0b peer_id_addr_type=1 peer_id_addr=4f:9d:c9:74:79:0b conn_itvl=24 conn_latency=0 supervision_timeout=72 encrypted=0 authenticated=0 bonded=0
The ESP Nimble version is 1.2 but I patched it with the NimBLE_CCCD_overflow_loop_fix.
RPA_disabled.txt
RPA_enabled.txt
(Forgot to say this is using the example bleprph application. The only mod I made to that was to add the RPA enable line, and a command to report the store peer count.)
The text was updated successfully, but these errors were encountered: