esp-idf-provisioning-ios
esp-idf-provisioning-ios copied to clipboard
espressif
ESP BLE Provisioning app is broken on iOS
A few days ago the ESP BLE Provisioning App stopped functioning on iOS. I could no longer provision ESP32 devices that had worked perfectly before.
Inspecting the latest code I see that the ProofOfPossession key in ESPProvision/Info.plist has changed to "abcd123456233". I'm guessing this is why the app is broken as all other sample code uses "abcd1234".
@neillowden @rhr407 We are looking into this. Please fill in the details mentioned below to help us better debug the issue:
Describe the bug A clear and concise description of what the bug is.
To Reproduce Steps to reproduce the behavior:
- Go to '...'
- Click on '....' ...
Frequency Tell us the number of times you are able to reproduce the issue. It will help us to check if the issue is occurring intermittently.
Expected behavior A clear and concise description of what you expected to happen.
Screenshots If applicable, add screenshots to help explain your problem.
ESP Device Information:
- ESP-IDF version: [e.g. 4.0]
- Example referenced: [e.g. wifi_prov_mgr]
- Board type: [e.g. ESP-32]
iOS information:
- Device type: [e.g. iPhone/iPad]
- Device model: [e.g. iPhone 7]
- iOS version: [e.g. iOS8.1]
- App Version: [e.g. v.2.0.8]
Provisioning information:
- ESPProvision iOS SDK version: [e.g. 2.0.8] (if applicable)
- Device type: [e.g. SoftAP/ BLE]
- Security: [e.g. Secure/Unsecure]
ESP Device logs: If applicable, add device logs here.
Additional context Add any other context about the problem here.
Hi @neillowden @rhr407, we have tracked down the issue and it may be related to the pairing of BLE devices that was introduced later in the ESP-IDF. Due to this connection with BLE device is successful for the first time but if we do erase_flash on the same device then pairing information is getting erased from the device. However, iOS still keeps this information and tries to pair it with that which ultimately leads to failure.
We are currently working on the fix. For now, you can go to iPhone->Settings->Bluetooth and forget the device from the list and try again. Let us know if doing this fixes your issue.
@vikas-chandra-mnnit For us the device service name does not show up. This is also after doing a erase_chip. Is this the same for you? Currently my devices show up with the name N/A when using a app like ble scanner
@vikas-chandra-mnnit I tried your work around of deleting it from paired devices and this did not fix the issue. When do you think the fix will be implemented for this? and is there anything else I can try to help you guys fix this?
During my testing I found using an "BLE Scanner" app, that even though the IOS doesnt recogonize the name of the device when scanning, if you try to connect/pair to it. It will see it as an esp device.
Hi @divrajBevie, please provide us additional information mentioned below. This will help us a lot to identify the issue and provide a resolution.
Describe the bug A clear and concise description of what the bug is.
To Reproduce Steps to reproduce the behavior:
Go to '...' Click on '....' ... Frequency Tell us the number of times you are able to reproduce the issue. It will help us to check if the issue is occurring intermittently.
Expected behavior A clear and concise description of what you expected to happen.
Screenshots If applicable, add screenshots to help explain your problem.
ESP Device Information:
ESP-IDF version: [e.g. 4.0] Example referenced: [e.g. wifi_prov_mgr] Board type: [e.g. ESP-32] iOS information:
Device type: [e.g. iPhone/iPad] Device model: [e.g. iPhone 7] iOS version: [e.g. iOS8.1] App Version: [e.g. v.2.0.8] Provisioning information:
ESPProvision iOS SDK version: [e.g. 2.0.8] (if applicable) Device type: [e.g. SoftAP/ BLE] Security: [e.g. Secure/Unsecure] ESP Device logs: If applicable, add device logs here.
Additional context Add any other context about the problem here.
Hi @vikas-chandra-mnnit,
To recreate this issue, you will need the following:
- IOS device (I am running on IOS 14) (tested with iPad 2020 and iPhone 11)
- ESP32
- IDF version (4.4)
- Latest EspressIF BLE Provisioning download
- 3rd Party App for Scanning BLE devices
The following steps need to be followed to recreate the issue:
- Run the example provisioning software.
- Security 1 (Secure)
- BLE transport layer
- Use the BLE app to provision the device
- Erase the chip and download new firmware with different service name (change PROV_ -> TEST_)
- Run through the steps on the provisioing app again with the different Prefix.
- NOTICE: device does not appear
- Open BLE scanner app and notice the scanned device is not showing up with a name (name = N/A). With comparing the custom UUID and the scanned UI ids, you can see it is present however IOS doesnt recognize it name.
@divrajBevie Thanks for providing a detailed description of the issue. Using it we were able to simulate the behavior. The reason iOS shows an old name is due to the fact that once connected OS caches the GAP name and reports it as a peripheral name. More descriptions of this can be found from this Apple thread.
I also used the BLE scanner app and verified that BLE device is shown in the list with the old name PROV_EB1595. We are actually using advertised name in our app which means you will always see the updated name when you go through the manual flow.
If your BLE device is not showing in our app that may be due to the fact that it is already connected to the iPhone and is not in discoverable mode. You can verify this by going to iPhone->Settings->Blueetooth and check for a connected device. This may be happening automatically and it's an issue.
We have implemented a fix for this behaviour and it is currently in review state. We will update you once it is merged and available.
Hi @vikas-chandra-mnnit Has there been any update on this? I have checked by deleting the bluetooth device frm connected device and still experience this issue?
@divrajBevie Changes are approved and ready but are taking longer than expected to merge due to some unforseen events. Meanwhile, I am attaching a patch file for the changes here which you can apply to resume your work. Will notify you once the updates are pushed. Ble_Prov_Fix.txt
Steps to apply:
- Change extension of file from .txt to .patch.
- Use command
git apply Ble_Prov_Fix.patchover your repo.
@vikas-chandra-mnnit I have applied this patch and still not resolved the issue. I have found something interesting however. When building the wifi provisioning example with Bluedroid stack you experience this issue, however that is not the case with nimBLE. I have highlighted on this issue here https://github.com/espressif/esp-idf/issues/7647 . Could you please look into this and see if you are able to recreate this?
Hi @divrajBevie, apologies for the delay, we have pushed a fix for the BLE issue here https://github.com/espressif/esp-idf/tree/release/v4.3. Please checkout this branch and let us know if it resolves your issue.
I tested it with release version idf 4.4 by configuring my device using the protocomm example in the wiki page:
https://docs.espressif.com/projects/esp-idf/en/v4.4/esp32/api-reference/provisioning/protocomm.html
Is not possible to see my esp32 with any iphone from 8 to above (haven't tested with previews versions). Seems like the fix was not applied to what the protocomm_ble_start function does.
@vikas-chandra-mnnit could you share the commit of the fix so I can check what exactly changed?
@sch0bert I ended up using the NimBLE Stack instead (with that it was working as intended). With the bluedroid stack, you need to first go to a standalone bluetooth scanning app and find your esp32 in the list. Once found, try to connect to it with the standalone app, this will set your esp32 local name on your iphone. Then the esp32 app will work.
It appears the bluedroid is not able to update the local name automatically and you have to manually do it.
Indeed this is the way it work also for my through protocomm but it shouldn't be like that. It used to work normally in IDF 4.0.3 but when I migrated to 4.4, it started failing.
@vikas-chandra-mnnit @divrajBevie should I open then an issue in the idf project instead?
Indeed this is the way it work also for my through protocomm but it shouldn't be like that. It used to work normally in IDF 4.0.3 but when I migrated to 4.4, it started failing.
@vikas-chandra-mnnit @divrajBevie should I open then an issue in the idf project instead?
@sch0bert, yes please open this issue in esp-idf project for better resolution.