-
Notifications
You must be signed in to change notification settings - Fork 7.3k
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
[regression] 4.4.5 ESP32S3 BLE authentication failure from IOS devices (IDFGH-10659) #11890
Comments
I see no relevant changes in protocomm and wifi_provisioning |
The issue on IOS is triggered when sending |
@KonssnoK |
|
@zhp0406 answer above 👍🏼 |
Log for failure
Log for success
|
@zhp0406 did you manage to replicate? |
@KonssnoK
Can you provide me with more information, please? Thank you. |
@zhp0406 i use:
(multiple edits) It seems that something changed in the provisioning code. I'll investigate more |
What i see is that with the default application
what is see in our application (same commit of esp-idf)
|
@KonssnoK |
Working provisioning app
non-working internal FW
we didn't touch the BLE, the whole code of esp-idf is shared beetween the 2 applications. We had the following differences in sdkconfig
|
@zhp0406
|
@KonssnoK |
ok i think i might have found what is the difference. your example does not set: Apparently if you set this, Android continue to work and IOS stops working. So i confirm the regression from that commit, related to IOS only |
@zhp0406 i double confirm. So we can go back to the initial discussion, but now we know how to trigger it also on the example.
|
@KonssnoK Please choose (X) NimBLE - BLE only Also, please ensure that you set: Thank you once again. |
@zhp0406 i confirm that selecting Nimble - BLE only removes the issue. What are the next steps? |
@KonssnoK |
I can't exclude the fact that classic bluetooth isn't used. Do you have any forecast on how long will it be before a fix is released? |
@KonssnoK |
@zhp0406 We didn't do further checks yet |
@KonssnoK |
@zhp0406 thanks. I'll try the patch |
@KonssnoK |
@zhp0406 apparently my colleagues' IOS app has the same issue connecting to the device. If you can share the fix once it's known, |
@KonssnoK |
@zhp0406 As additional detail, our app is in javascript, not swift, and we still have the issue |
@zhp0406 we fear the issue is intrinsic in the IOS operating system and think that the only way to solve it is by changing the device code. IOS does not allow to specify when to bond (android does) We propose the following solution. ios_encryption_protocomm.patch What do you think @zhp0406 ? Does it make sense? Also, ??? Does it mean the encryption was not working before that commit? |
@zhp0406 is there any news? we are going to temporarily ship the attached patch in case we don't receive updates. |
@KonssnoK |
@zhp0406 did you have time to check the patch i submitted? |
@KonssnoK |
@zhp0406 apparently our patch works only on IOS 15.X but not on IOS 16.... So we are back at square one. |
@zhp0406 another test to do! I was able to connect with this on IOS 15, now we have to try IOS16 and IOS17 |
@KonssnoK Once It's important to note that bonding will save the key, so you won't need to pair again next time. If you want to clear the pairing information, you need to execute the following command:
Replace Additionally, you'll also need to remove the bonding on iOS. |
@zhp0406 |
@KonssnoK |
Answers checklist.
General issue report
Between the following 2 commits
8b94183
and
3cec3a0
something changed in the BLE component.
The result of these changes make any IOS device fail to authenticate with error
using esp provisioning 2.0.14 -> BLE -> encrypted communication selected
Android works fine.
The text was updated successfully, but these errors were encountered: