Cannot connect to device running ble50_security_server example from iPhone (IDFGH-14584)

[dimitar-kunchev]

Answers checklist.

• I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
• I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
• I have searched the issue tracker for a similar issue and not found a similar issue.

IDF version.

5.4

Espressif SoC revision.

ESP32-C6

Operating System used.

Linux

How did you build your project?

Command line with idf.py

If you are using Windows, please specify command line type.

None

Development Kit.

ESP32-C6-DevKitC

Power Supply used.

USB

What is the expected behavior?

I should be able to connect to the device with an iOS app (e.g. nRF Connect)

What is the actual behavior?

The connection cannot be established. The log output indicates the phone keeps reconnecting and eventually fails.

Steps to reproduce.

1. Build and deploy the bluetooth/bluedroid/ble_50/ble50_security_server example without any configuration changes
2. Try to connect using nRF Connect app (or other similar apps)

Debug Logs.

I (701) SEC_GATTS_DEMO: Extended advertising terminated, status 0
I (701) SEC_GATTS_DEMO: Advertising successfully ended with a connection being created
W (881) BT_HCI: hcif disc complete: hdl 0x0, rsn 0x3e
I (881) SEC_GATTS_DEMO: Extended advertising start, status 0
I (1021) SEC_GATTS_DEMO: Extended advertising terminated, status 0
I (1021) SEC_GATTS_DEMO: Advertising successfully ended with a connection being created
W (1201) BT_HCI: hcif disc complete: hdl 0x0, rsn 0x3e
I (1201) SEC_GATTS_DEMO: Extended advertising start, status 0
I (1321) SEC_GATTS_DEMO: Extended advertising terminated, status 0
I (1321) SEC_GATTS_DEMO: Advertising successfully ended with a connection being created
W (1501) BT_HCI: hcif disc complete: hdl 0x0, rsn 0x3e
I (1501) SEC_GATTS_DEMO: Extended advertising start, status 0
I (1911) SEC_GATTS_DEMO: Extended advertising terminated, status 0
I (1911) SEC_GATTS_DEMO: Advertising successfully ended with a connection being created
W (2091) BT_HCI: hcif disc complete: hdl 0x0, rsn 0x3e
I (2091) SEC_GATTS_DEMO: Extended advertising start, status 0
I (2211) SEC_GATTS_DEMO: Extended advertising terminated, status 0
I (2211) SEC_GATTS_DEMO: Advertising successfully ended with a connection being created
W (2391) BT_HCI: hcif disc complete: hdl 0x0, rsn 0x3e
I (2391) SEC_GATTS_DEMO: Extended advertising start, status 0
I (2511) SEC_GATTS_DEMO: Extended advertising terminated, status 0
I (2511) SEC_GATTS_DEMO: Advertising successfully ended with a connection being created
W (2691) BT_HCI: hcif disc complete: hdl 0x0, rsn 0x3e
I (2691) SEC_GATTS_DEMO: Extended advertising start, status 0
I (2831) SEC_GATTS_DEMO: Extended advertising terminated, status 0
I (2831) SEC_GATTS_DEMO: Advertising successfully ended with a connection being created
W (3011) BT_HCI: hcif disc complete: hdl 0x0, rsn 0x3e
I (3011) SEC_GATTS_DEMO: Extended advertising start, status 0
I (3101) SEC_GATTS_DEMO: Extended advertising terminated, status 0
I (3101) SEC_GATTS_DEMO: Advertising successfully ended with a connection being created
W (3281) BT_HCI: hcif disc complete: hdl 0x0, rsn 0x3e
I (3281) SEC_GATTS_DEMO: Extended advertising start, status 0
I (3401) SEC_GATTS_DEMO: Extended advertising terminated, status 0
I (3401) SEC_GATTS_DEMO: Advertising successfully ended with a connection being created
W (3581) BT_HCI: hcif disc complete: hdl 0x0, rsn 0x3e
I (3581) SEC_GATTS_DEMO: Extended advertising start, status 0
I (3701) SEC_GATTS_DEMO: Extended advertising terminated, status 0
I (3701) SEC_GATTS_DEMO: Advertising successfully ended with a connection being created
W (3881) BT_HCI: hcif disc complete: hdl 0x0, rsn 0x3e
I (3881) SEC_GATTS_DEMO: Extended advertising start, status 0
I (4001) SEC_GATTS_DEMO: Extended advertising terminated, status 0
I (4001) SEC_GATTS_DEMO: Advertising successfully ended with a connection being created
W (4181) BT_HCI: hcif disc complete: hdl 0x0, rsn 0x3e
I (4181) SEC_GATTS_DEMO: Extended advertising start, status 0
I (4321) SEC_GATTS_DEMO: Extended advertising terminated, status 0
I (4321) SEC_GATTS_DEMO: Advertising successfully ended with a connection being created

More Information.

It works fine with the BLE 4.2 examples.
I have experimented with custom code on the ESP to mess with the security and with the advertisement, I have experimented with custom app code
It works fine connecting from an Android phone and various PCs.
Doesn't work on several iPhones I have tried (X, 13, 15, etc)
I have tried with 5.4 release and with the master branch - no difference.

[ZhouXiao616]

Hi @dimitar-kunchev , could you please share your iOS version? The issue looks quite similar to a known iOS compatibility issue, please check #12911, my colleague has shared a workaround solution in the comments.

If the solution provided does not meet your requirements, please feel free to leave a comment and share your requirements in detail, we'll try our best to help you. :)

[dimitar-kunchev]

I have tested this with iOS 18.2.1
From what I understand in issue #12911 the problem relates to large advertisement data. I have tried to decrease it to 20
bytes by shortening the name and removing the service from the advertised raw data, but that doesn't help.

[dimitar-kunchev]

P.S.: While writing my previous comment, I saw it establishing a connection from my iPhone on BLE 5. It did spit the usual connection errors but after a while, it established a connection and fetched the services properly.

I checked out some old code I have on nRF chips and I see I had to drop the service from the advertisement to get it working there too. It's been years but I recall we had some weird iOS behavior there. So this certainly is an iOS problem. However, I have been able to get it going on nRF with BLE 5.0 so it should be possible on ESP too.

[ZhouXiao616]

Hi @dimitar-kunchev , in our view the issue is related to the unexpected behavior from iPhone side, referring to #12911 (comment).

In brief, iPhone didn't send TX LL data within the correct time range after sending the AUX_CONNECT_REQ PDU, which is incompliant with Core Spec, causing ESP chip as slave to disconnect with reason 0x3e.

A possible workaround described in #12911 (comment) is

ESP chip side

1. Start extended ADV normally if it is a must
2. After starting extended ADV, start an additional legacy ADV with the same address info

iPhone side

1. Start scanning on iPhone with nRF Connect or other apps
2. You should be able to see both extended ADV and legacy ADV from ESP chip
3. Connect to ESP chip by legacy ADV

In this way, ESP chip is advertising in BLE 5.0 but being connected in BLE 4.2, which could avoid unexpected BLE 5.0 behavior from iPhone side during connection establishment.

We hope the suggestion could help. :)