Peripheral BLE_GAP_EVENT_CONNECT arrives late causing GATT operations to occur before connection event

[h2zero]

Checklist

• Checked the issue tracker for similar issues to ensure this is not a duplicate
• Read the documentation to confirm the issue is not addressed there and your configuration is set correctly
• Tested with the latest version to ensure the issue hasn't been fixed

How often does this bug occurs?

always

Expected behavior

The peripheral should know about a connected central before any other connection oriented event occurs.

Actual behavior (suspected bug)

When acting as a peripheral the central starts requesting reads/writes etc. before the peripheral knows about the connection.

Error logs or terminal output

Steps to reproduce the behavior

The cause is here:

esp-nimble/nimble/host/src/ble_gap.c

Line 3302 in 039d2d6

ble_gap_rd_rem_ver_tx(evt->connection_handle);

Instead of calling ble_gap_event_connect_call(evt->connection_handle, evt->status);, as it should in the slave roll since the connection has already been established, it waits for the result of ble_gap_rd_rem_ver_tx(evt->connection_handle); before sending the connection event.

During this time the central could, and in my tests does, start performing GATT operations before the application knows about the connection.

Project release version

latest

System architecture

Intel/AMD 64-bit (modern PC, older Mac)

Operating system

Linux

Operating system version

all

Shell

Bash

Additional context

The fix is simple, at:

esp-nimble/nimble/host/src/ble_gap.c

Line 3302 in 039d2d6

ble_gap_rd_rem_ver_tx(evt->connection_handle);

Change it to:

    if (evt->role == BLE_HCI_LE_CONN_COMPLETE_ROLE_SLAVE) {
        ble_gap_event_connect_call(evt->connection_handle, evt->status);
        ble_gap_rd_rem_ver_tx(evt->connection_handle);
    } else {
        ble_gap_rd_rem_sup_feat_tx(evt->connection_handle);
    }

And at :

esp-nimble/nimble/host/src/ble_gap.c

Line 3420 in 039d2d6

} else {

Remove the else block.

[rahult-github]

Hi @h2zero .

Thanks for the detailed report and proposed patch.

The reason for the current changes is that on some controllers/chips we can receive LE Connection Complete and then quickly hit 0x3E (BLE_ERR_CONN_ESTABLISHMENT) because link synchronization was not actually completed. If we notify the app immediately, the app starts connection work and then fails right away on that false-positive connection.

To avoid that, we defer BLE_GAP_EVENT_CONNECT until a post-connect HCI probe sequence succeeds (Read Remote Version / Read Remote Features). If that path returns 0x3E, connect is not reported as a successful link.

So the suggested change (posting connect immediately for slave role) would reintroduce the earlier regression we fixed, and we can’t take it as-is.

As a workaround, i can think of introducing a flag which helps take the implementation back to its original method of posting event immediately, that user can enable if they really want to , but this will carry the baggage of observing issues as mentioned above. This flag would be disabled by default, so default implementation remains safe behavior; advanced users can opt into original timing with clear trade-off.

[h2zero]

I understand the reason for the change but I do not believe is should be applied to the slave device. From what I understand the connection event is not triggered for the slave until the connection has been established. For the master it would make sense though and I agree with that change.

Relevant post: espressif/esp-idf#2467 (comment)

[rahult-github]

I do not believe is should be applied to the slave device

We get the disconnect 0x3E event in slave role too. That is why we have the implementation to restart advertising upon this event.

[h2zero]

We get the disconnect 0x3E event in slave role too.

I have yet to see that, but even if so this is not a great situation.

For instance, I have a master/slave setup here where I have seen the master connect, read 4 characteristics and write one all before the slave device gets the connection event, since the master device doesn't wait for anything after it gets the connection event it just does what it needs to do.

In this scenario the slave also disconnects from the master after the write, however it doesn't even know about the connection to begin with.

[rahult-github]

Please try this patch where have tried to provide a menuconfig option to control. If your system wants to have direct connection event to be sent, you can enable it from menuconfig and use .

IDF patch : add_connect_flag

Nimble patch: nimble_add_connect_flag

add_connect_flag.txt

nimble_add_connect_flag.txt

[rahult-github]

Working on a new scheme to queue ATT commands till connect is posted. This should handle both cases where sync formation is needed and also remote devices posting ATT commands after ACL connection, even if esp device is still preparing for connect event at application layer.

[h2zero]

Sorry I didn't get back to this. Instead of queueing the commands on the peripheral side you could just assume the connection is established as soon as any att command is received, that is just as valid an indicator as waiting for responses to version etc..

[rahult-github]

Sorry I didn't get back to this. Instead of queueing the commands on the peripheral side you could just assume the connection is established as soon as any att command is received, that is just as valid an indicator as waiting for responses to version etc..

Thanks for this input. Since we do not know at which point the ATT operation is received, we will have to add checks at both HCI commands /events and handle connection event posting . Though i currently feel this is making it more complex, but will check on the feasibility of this and update