Bluetooth mesh provisioning freezes after the key exchange

RE: Bluetooth mesh provisioning freezes after the key exchange

Hung Bui — Tue, 23 Oct 2018 14:08:13 GMT

Hi Vladimir,

At least we don't see an error with sd_ble_gap_data_length_update() after your update.

I can see in your log there is a timeout: 0> <t: 3661792>, fsm.c, 232, PB-GATT bearer: E: E_LINK_TIMEOUT Most likely the connection is broken there.

We need to have a sniffer trace to see what exactly happened. After the publickey exchange , each peer would need to calculate the device key and the use that to encrypt the link (provide random and confirm) I don't see that it reached that part yet.

My suggestion for you is to try to roll back to the original proxy example and try to modify block by block from there until you see the same issue.

RE: Bluetooth mesh provisioning freezes after the key exchange

Vladimir — Tue, 23 Oct 2018 10:00:39 GMT

I tried:

// <i> Requested BLE GAP data length to be negotiated.

#ifndef NRF_SDH_BLE_GAP_DATA_LENGTH
#define NRF_SDH_BLE_GAP_DATA_LENGTH 27
#endif

// <o> NRF_SDH_BLE_PERIPHERAL_LINK_COUNT - Maximum number of peripheral links. 
#ifndef NRF_SDH_BLE_PERIPHERAL_LINK_COUNT
#define NRF_SDH_BLE_PERIPHERAL_LINK_COUNT 2
#endif

// <o> NRF_SDH_BLE_CENTRAL_LINK_COUNT - Maximum number of central links. 
#ifndef NRF_SDH_BLE_CENTRAL_LINK_COUNT
#define NRF_SDH_BLE_CENTRAL_LINK_COUNT 2
#endif

// <o> NRF_SDH_BLE_TOTAL_LINK_COUNT - Total link count. 
// <i> Maximum number of total concurrent connections using the default configuration.

#ifndef NRF_SDH_BLE_TOTAL_LINK_COUNT
#define NRF_SDH_BLE_TOTAL_LINK_COUNT 4
#endif

// <o> NRF_SDH_BLE_GAP_EVENT_LENGTH - GAP event length. 
// <i> The time set aside for this connection on every connection interval in 1.25 ms units.

#ifndef NRF_SDH_BLE_GAP_EVENT_LENGTH
#define NRF_SDH_BLE_GAP_EVENT_LENGTH 6
#endif

// <o> NRF_SDH_BLE_GATT_MAX_MTU_SIZE - Static maximum MTU size. 
#ifndef NRF_SDH_BLE_GATT_MAX_MTU_SIZE
#define NRF_SDH_BLE_GATT_MAX_MTU_SIZE 69
#endif

// <o> NRF_SDH_BLE_GATTS_ATTR_TAB_SIZE - Attribute Table size in bytes. The size must be a multiple of 4. 
#ifndef NRF_SDH_BLE_GATTS_ATTR_TAB_SIZE
#define NRF_SDH_BLE_GATTS_ATTR_TAB_SIZE 2048
#endif

// <o> NRF_SDH_BLE_VS_UUID_COUNT - The number of vendor-specific UUIDs. 
#ifndef NRF_SDH_BLE_VS_UUID_COUNT
#define NRF_SDH_BLE_VS_UUID_COUNT 2
#endif

I have got the same fault with this configuration.

log:

 0> <t:        531>, nrf_mesh_dfu.c,  904, ERROR: No CMD handler!
 0> <t:      11733>, fsm.c,  222, PB-GATT bearer: init
 0> <t:      11743>, prov_bearer_adv.c,  381, PB-ADV: context at 0x200070DC added to bearer
 0> <t:      11747>, fsm.c,  232, PB-GATT bearer: E: E_LISTEN_START
 0> <t:      11750>, fsm.c,  185, PB-GATT bearer: A: A_LISTEN_START
 0> <t:      11765>, fsm.c,  199, PB-GATT bearer: state S_IDLE -> S_LISTENING
 0> <t:      11769>, r4s_mesh_init.c,   76, Device UUID : 005955BB000000008777D02A7520DC1E
 0> <t:    1331614>, fsm.c,  232, PB-GATT bearer: E: E_CONNECTED
 0> <t:    1331616>, fsm.c,  185, PB-GATT bearer: A: A_LINK_OPEN
 0> <t:    1331620>, fsm.c,  199, PB-GATT bearer: state S_LISTENING -> S_CONNECTED
 0> <t:    1386015>, fsm.c,  232, PB-GATT bearer: E: E_TX_READY
 0> <t:    1386017>, fsm.c,  185, PB-GATT bearer: A: A_LINK_TIMER_START
 0> <t:    1386020>, fsm.c,  199, PB-GATT bearer: state S_CONNECTED -> S_LINK_ACTIVE
 0> <t:    1662345>, fsm.c,  232, PB-GATT bearer: E: E_PDU_RX
 0> <t:    1662351>, fsm.c,  185, PB-GATT bearer: A: A_PDU_RX
 0> <t:    1662354>, prov_provisionee.c,  317, Provisionee: invite received!
 0> <t:    1662357>, prov_provisionee.c,  110, Provisionee: sending capabilities
 0> <t:    1662360>, fsm.c,  232, PB-GATT bearer: E: E_PDU_TX
 0> <t:    1662363>, fsm.c,  185, PB-GATT bearer: A: A_PDU_TX
 0> <t:    1665535>, fsm.c,  232, PB-GATT bearer: E: E_TX_COMPLETE
 0> <t:    1665541>, fsm.c,  185, PB-GATT bearer: A: A_PDU_ACK
 0> <t:    1694293>, fsm.c,  232, PB-GATT bearer: E: E_PDU_RX
 0> <t:    1694299>, fsm.c,  185, PB-GATT bearer: A: A_PDU_RX
 0> <t:    1694302>, prov_provisionee.c,  341, Provisionee: provisioning start message received!
 0> <t:    1695938>, fsm.c,  232, PB-GATT bearer: E: E_PDU_RX
 0> <t:    1695944>, fsm.c,  185, PB-GATT bearer: A: A_PDU_RX
 0> <t:    1695947>, prov_provisionee.c,  369, Provisionee: public key message received!
 0> <t:    1695951>, fsm.c,  232, PB-GATT bearer: E: E_PDU_TX
 0> <t:    1695953>, fsm.c,  185, PB-GATT bearer: A: A_PDU_TX
 0> <t:    1710261>, fsm.c,  232, PB-GATT bearer: E: E_TX_COMPLETE
 0> <t:    1710267>, fsm.c,  185, PB-GATT bearer: A: A_PDU_ACK
 0> <t:    3661792>, fsm.c,  232, PB-GATT bearer: E: E_LINK_TIMEOUT
 0> <t:    3661795>, fsm.c,  185, PB-GATT bearer: A: A_LINK_CLOSE
 0> <t:    3661798>, fsm.c,  199, PB-GATT bearer: state S_LINK_ACTIVE -> S_CONNECTED
 0> <t:    3663850>, fsm.c,  232, PB-GATT bearer: E: E_DISCONNECTED
 0> <t:    3663853>, fsm.c,  185, PB-GATT bearer: A: A_LINK_CLOSE_NOTIFY
 0> <t:    3663857>, prov_bearer_adv.c,  381, PB-ADV: context at 0x200070DC added to bearer
 0> <t:    3663861>, fsm.c,  199, PB-GATT bearer: state S_CONNECTED -> S_IDLE
 0> <t:    3663866>, fsm.c,  232, PB-GATT bearer: E: E_LISTEN_START
 0> <t:    3663869>, fsm.c,  185, PB-GATT bearer: A: A_LISTEN_START
 0> <t:    3663884>, fsm.c,  199, PB-GATT bearer: state S_IDLE -> S_LISTENING

Did you check the code from my first message?

Also, I made advertising not stoppable.

void mesh_adv_data_set(uint16_t service_uuid, const uint8_t * p_service_data, uint8_t length) {
    ... code to set data for service uuid ...
}

void mesh_adv_stop(void)
{
    // do nothing
}

void mesh_adv_start(void)
{
    // do nothing
}

void mesh_adv_params_set(uint32_t timeout_ms, uint32_t interval_units)
{
    // do nothing
}

I start advertising at startup and change the advertisement data when mesh_adv_data_set called. If mesh_adv_stop is called I don't reset the service data. Can it be depended with the fault?

RE: Bluetooth mesh provisioning freezes after the key exchange

Hung Bui — Mon, 22 Oct 2018 13:02:07 GMT

Hi Vladimir,

We need to have a look back at your first log. You received 0x02 error code when calling sd_ble_gap_data_length_update() meaning the connection event length is too short for what you want to have with the data length. Note that by default the max event length in Mesh configured to NRF_SDH_BLE_GAP_EVENT_LENGTH = 6. In normal application it's configured to 320.

I think it's the main difference of the configuration between the mesh application and normal SDK application. And when you merge them you use the sd_ble_gap_data_length_update() handler without changing the configuration for Event length .

Also note that NRF_SDH_BLE_GAP_DATA_LENGTH in mesh application is configured to 27 when in normal sdk it's 251.

The reason we reconfigure a smaller value on Mesh application is that we don't want BLE connection occupies too much bandwidth making mesh operation limited.

You would need to modify the configuration on your sdk_config.h to avoid this. Coudl you check where you have the value of 178 octets configured ?

RE: Bluetooth mesh provisioning freezes after the key exchange

Vladimir — Fri, 19 Oct 2018 14:24:32 GMT

Is it possible that problem occurs because of Keil compiler?

I set MTU size 69 and provisioning freezes. sdk_config.h:

#ifndef NRF_SDH_BLE_GATT_MAX_MTU_SIZE
#define NRF_SDH_BLE_GATT_MAX_MTU_SIZE 69
#endif

But if I define NRF_SDH_BLE_GATT_MAX_MTU_SIZE equals 23 - everything is ok.

Yes, our plan is to use BLE and Mesh together.

Log from SEGGER RTT:

# SEGGER J-Link RTT Viewer V5.12f Terminal Log File
# Compiled: 16:04:47 on May 17 2016
# Logging started @ 19 Oct 2018 17:14:38
 0> <t:      11731>, fsm.c,  222, PB-GATT bearer: init
 0> <t:      11741>, prov_bearer_adv.c,  381, PB-ADV: context at 0x20007038 added to bearer
 0> <t:      11746>, fsm.c,  232, PB-GATT bearer: E: E_LISTEN_START
 0> <t:      11749>, fsm.c,  185, PB-GATT bearer: A: A_LISTEN_START
 0> <t:      11764>, fsm.c,  199, PB-GATT bearer: state S_IDLE -> S_LISTENING
 0> <t:    1651099>, fsm.c,  232, PB-GATT bearer: E: E_CONNECTED
 0> <t:    1651102>, fsm.c,  185, PB-GATT bearer: A: A_LINK_OPEN
 0> <t:    1651105>, fsm.c,  199, PB-GATT bearer: state S_LISTENING -> S_CONNECTED
 0> <t:    1751084>, fsm.c,  232, PB-GATT bearer: E: E_TX_READY
 0> <t:    1751087>, fsm.c,  185, PB-GATT bearer: A: A_LINK_TIMER_START
 0> <t:    1751090>, fsm.c,  199, PB-GATT bearer: state S_CONNECTED -> S_LINK_ACTIVE
 0> <t:    1792612>, fsm.c,  232, PB-GATT bearer: E: E_PDU_RX
 0> <t:    1792615>, fsm.c,  185, PB-GATT bearer: A: A_PDU_RX
 0> <t:    1792618>, prov_provisionee.c,  317, Provisionee: invite received!
 0> <t:    1792621>, prov_provisionee.c,  110, Provisionee: sending capabilities
 0> <t:    1792624>, fsm.c,  232, PB-GATT bearer: E: E_PDU_TX
 0> <t:    1792627>, fsm.c,  185, PB-GATT bearer: A: A_PDU_TX
 0> <t:    1795809>, fsm.c,  232, PB-GATT bearer: E: E_TX_COMPLETE
 0> <t:    1795812>, fsm.c,  185, PB-GATT bearer: A: A_PDU_ACK
 0> <t:    1795818>, fsm.c,  232, PB-GATT bearer: E: E_PDU_RX
 0> <t:    1795820>, fsm.c,  185, PB-GATT bearer: A: A_PDU_RX
 0> <t:    1795823>, prov_provisionee.c,  341, Provisionee: provisioning start message received!
 0> <t:    1799048>, fsm.c,  232, PB-GATT bearer: E: E_PDU_RX
 0> <t:    1799052>, fsm.c,  185, PB-GATT bearer: A: A_PDU_RX
 0> <t:    1799055>, prov_provisionee.c,  369, Provisionee: public key message received!
 0> <t:    1799058>, fsm.c,  232, PB-GATT bearer: E: E_PDU_TX
 0> <t:    1799061>, fsm.c,  185, PB-GATT bearer: A: A_PDU_TX
 0> <t:    1814973>, fsm.c,  232, PB-GATT bearer: E: E_TX_COMPLETE
 0> <t:    1814976>, fsm.c,  185, PB-GATT bearer: A: A_PDU_ACK
 0> <t:    3764959>, fsm.c,  232, PB-GATT bearer: E: E_LINK_TIMEOUT
 0> <t:    3764962>, fsm.c,  185, PB-GATT bearer: A: A_LINK_CLOSE
 0> <t:    3764965>, fsm.c,  199, PB-GATT bearer: state S_LINK_ACTIVE -> S_CONNECTED
 0> <t:    3766885>, fsm.c,  232, PB-GATT bearer: E: E_DISCONNECTED
 0> <t:    3766888>, fsm.c,  185, PB-GATT bearer: A: A_LINK_CLOSE_NOTIFY
 0> <t:    3766892>, prov_bearer_adv.c,  381, PB-ADV: context at 0x20007038 added to bearer
 0> <t:    3766896>, fsm.c,  199, PB-GATT bearer: state S_CONNECTED -> S_IDLE
 0> <t:    3766901>, fsm.c,  232, PB-GATT bearer: E: E_LISTEN_START
 0> <t:    3766904>, fsm.c,  185, PB-GATT bearer: A: A_LISTEN_START
 0> <t:    3766919>, fsm.c,  199, PB-GATT bearer: state S_IDLE -> S_LISTENING

RE: Bluetooth mesh provisioning freezes after the key exchange

Hung Bui — Wed, 03 Oct 2018 13:51:38 GMT

Hi Vladimir,

I'm sorry for the late response. I just got the case from Bjørn and will try to assist you.

Could you clarify which MTU size you set to 23 that make the provisioning worked ?

In our proxy provisioning example we support upto 69byte MTU, I don't see any problem when doing provisioning with that MTU.

I assume your plan is to have a merged application of normal BLE app and a proxy + mesh app together ?

It's important to see when the provisioning crashed, turn on Logging (at debug level ) would give some more information about the provisioning and what went wrong.

RE: Bluetooth mesh provisioning freezes after the key exchange

Vladimir — Wed, 26 Sep 2018 12:15:13 GMT

Thank you for the reply.

BLE_GATTS_EVT_SYS_ATTR_MISSING is handled in the gatt_cache_manager.

BLE_GAP_EVT_DATA_LENGTH_UPDATE_REQUEST is handled in the nrf_ble_gatt

BLE_GATTS_EVT_EXCHANGE_MTU_REQUEST is handled in the nrf_ble_gatt

BLE_GAP_EVT_SEC_PARAMS_REQUEST - security dispatcher

BLE_GAP_EVT_PHY_UPDATE_REQUEST - is handled by my code

I merged the mesh functionality with my project based on examples with own ble services.

RE: Bluetooth mesh provisioning freezes after the key exchange

Bjørn Kvaale — Wed, 26 Sep 2018 09:35:31 GMT

Sorry for the delayed response. Could you please explain why you have gotten rid of the code? Where in sdk 15 is this being handled otherwise? Have you merged the mesh functionality with an sdk example?

RE: Bluetooth mesh provisioning freezes after the key exchange

Vladimir — Thu, 20 Sep 2018 13:25:57 GMT

I found that if I change MTU size to 23 provisioning will be completed successfully. Is it possible to set MTU size more than 23? Why this behavior occurs?

RE: Bluetooth mesh provisioning freezes after the key exchange

Vladimir — Thu, 20 Sep 2018 12:51:34 GMT

I checked the provisioning state (using breakpoint at request_authentication function). The state is NRF_MESH_PROV_STATE_WAIT_CONFIRMATION. Because oob method is NRF_MESH_PROV_OOB_METHOD_NONE.