Hi,
In-app when you scan for device and after it is found you press the connect and then the notification/permission to pair pops out. Our app developers are saying that we must disable this notification in our firmware, but I can't find any similar settings in nRF SDK. If I connect to the device from nRF connect I don't see any notification/permission to pair.
Can we disable notification/permission to pair in firmware or not?
Thanks for help
Blaz
Hi,
Unfortunately, the BLE stack automatically pops up an alert view to prompt the user to confirm or cancel the pairing process. This is something that is happening on the OS BLE stack, so you won´t be able to prevent it from appearing from the application unless you don't use encrypted characteristics. The bonding process is triggered when you try to read an encrypted characteristic.
-Amanda H.
Dear Amanda,
Thank you for your support.
Our application was developed from ble_app_bms example. Our BLE security settings were set to pair/no bonding. From your answers, I assume that we must set up BLE connection no pair no bonding?
Form the instructions form your site it is written No pairing/bonding: NULL (or do not call pm_sec_params_set)
I have disabled the pm_sec_params_set function and the app is still working. When I connect to the device after a few seconds I get time out message and disconnection of the BLE connection: BLE_HCI_REMOTE_USER_TERMINATED_CONNECTION.
I find timeouts with disconnection in ble_evt_handler:
case BLE_GATTC_EVT_TIMEOUT:
// Disconnect on GATT Client timeout event.
NRF_LOG_DEBUG("GATT Client Timeout.");
err_code = sd_ble_gap_disconnect(p_ble_evt->evt.gattc_evt.conn_handle,
BLE_HCI_REMOTE_USER_TERMINATED_CONNECTION);
APP_ERROR_CHECK(err_code);
break;
case BLE_GATTS_EVT_TIMEOUT:
// Disconnect on GATT Server timeout event.
NRF_LOG_DEBUG("GATT Server Timeout.");
err_code = sd_ble_gap_disconnect(p_ble_evt->evt.gatts_evt.conn_handle,
BLE_HCI_REMOTE_USER_TERMINATED_CONNECTION);
APP_ERROR_CHECK(err_code)
But they are not the reason of diconnect.
Can you please help me out where I can disable this timeout.
Regards,
Blaz
Dear Amanda,
Thank you for your prompt support. Because of big changes in code, which will be very risky at this moment, the customer has decided that we go back to paring and bonding.
In the next version, we will implement no preparation, no bonding. In our custom characteristic, we have the following properties:
RLX_VIBRATION_LEVEL_CHAR_UUID 0x456b notify-read/write
RLX_MOTOR_CURRENT_CHAR_UUID 0x456c notify-read
RLX_CHRG_CURRENT_CHAR_UUID 0x456d notify-read
RLX_TEMP_CHAR_UUID 0x456e notify-read
RLX_BAT_VOLTAGE_UUID 0x456f notify-read
RLX_TEST_CHAR_UUID 0x4570 notify-read/write
RLX_PRESSURE_LEVEL_CHAR_UUID 0x4571 notify-read
From which example it will be the best to start if we want to build up the app from scratch wit no paring no bonding. Do you think the blinky example is most appropriate?
The current application was not built by us we got it from customer and some other developers were developing it. Now we would like to build it again the right way.
Regards,
Blaz
Hi Blaz,
We usually suggest starting from the Template Application example which doesn't use encrypted characteristics, so the mobile won't pop up a window to ask pairing or bonding. Users could use service under bond or no-bond. The blinky example does not use the peer manager library and bond/pair. It might be a good example to fit your requirements.
-Amanda H.
Dear Amanda,
Unfortunately, we have new problems. We have discovered that on apple we have some problems with connections. For example, if we use nRF connect on the android or desktop version we can connect without any problems. Here is the log of connection:
<debug> peer_manager_handler: Connected, securing connection. conn_handle: 0 <info> app: Connected <debug> peer_manager_handler: Event PM_EVT_CONN_SEC_PARAMS_REQ <debug> peer_manager_handler: Security parameter request <debug> peer_manager_handler: Event PM_EVT_CONN_SEC_START <debug> peer_manager_handler: Connection security procedure started: role: Peripheral, conn_handle: 0, procedure: Pairing <debug> peer_manager_handler: Event PM_EVT_CONN_SEC_PARAMS_REQ <debug> peer_manager_handler: Security parameter request <debug> peer_manager_handler: Event PM_EVT_CONN_SEC_SUCCEEDED <info> peer_manager_handler: Connection secured: role: Peripheral, conn_handle: 0, procedure: Pairing <info> app: PM_EVT_CONN_SEC_SUCCEEDED Event <debug> peer_manager_handler: Event PM_EVT_LOCAL_DB_CACHE_APPLIED <debug> peer_manager_handler: Previously stored local DB applied: conn_handle: 0, peer_id: 6553
If we use nRF connect on the apple phone the first time we connect the connection is established then it is disconnecting and after we do reconnect it is connected without any problems. Here is the log.
<debug> peer_manager_handler: Connected, securing connection. conn_handle: 0 <info> app: Connected <debug> app: PHY update request. <debug> nrf_ble_gatt: Peer on connection 0x0 requested a data length of 251 bytes. <debug> nrf_ble_gatt: Updating data length to 27 on connection 0x0. <debug> nrf_ble_gatt: Data length updated to 27 on connection 0x0. <debug> nrf_ble_gatt: max_rx_octets: 27 <debug> nrf_ble_gatt: max_tx_octets: 27 <debug> nrf_ble_gatt: max_rx_time: 2120 <debug> nrf_ble_gatt: max_tx_time: 2120 <debug> nrf_ble_gatt: Peer on connection 0x0 requested an ATT MTU of 293 bytes. <debug> nrf_ble_gatt: Updating ATT MTU to 23 bytes (desired: 23) on connection 0x0. <debug> peer_manager_handler: Event PM_EVT_CONN_SEC_PARAMS_REQ <debug> peer_manager_handler: Security parameter request <debug> peer_manager_handler: Event PM_EVT_CONN_SEC_START <debug> peer_manager_handler: Connection security procedure started: role: Peripheral, conn_handle: 0, procedure: Bonding <debug> peer_manager_handler: Event PM_EVT_CONN_SEC_PARAMS_REQ <debug> peer_manager_handler: Security parameter request <debug> peer_manager_handler: Event PM_EVT_CONN_SEC_SUCCEEDED <info> peer_manager_handler: Connection secured: role: Peripheral, conn_handle: 0, procedure: Bonding <info> app: PM_EVT_CONN_SEC_SUCCEEDED Event <debug> peer_manager_handler: Event PM_EVT_PEER_DATA_UPDATE_SUCCEEDED <debug> peer_manager_handler: Peer data updated in flash: peer_id: 0, data_id: Bonding data, action: Update <info> app: New Bond, add the peer to the whitelist if possible <info> app: m_whitelist_peer_cnt 2, MAX_PEERS_WLIST 8 <debug> peer_manager_handler: Event PM_EVT_PEER_DATA_UPDATE_SUCCEEDED <debug> peer_manager_handler: Peer data updated in flash: peer_id: 0, data_id: Bonding data, action: Update <info> app: New Bond, add the peer to the whitelist if possible <info> app: m_whitelist_peer_cnt 2, MAX_PEERS_WLIST 8 <debug> peer_manager_handler: Event PM_EVT_PEER_DATA_UPDATE_SUCCEEDED <debug> peer_manager_handler: Peer data updated in flash: peer_id: 0, data_id: Bonding data, action: Update <info> app: New Bond, add the peer to the whitelist if possible <info> app: m_whitelist_peer_cnt 2, MAX_PEERS_WLIST 8 <debug> peer_manager_handler: Event PM_EVT_PEER_DATA_UPDATE_SUCCEEDED <debug> peer_manager_handler: Peer data updated in flash: peer_id: 0, data_id: Peer rank, action: Update <debug> peer_manager_handler: Event PM_EVT_PEER_DATA_UPDATE_SUCCEEDED <debug> peer_manager_handler: Peer data updated in flash: peer_id: 0, data_id: Peer rank, action: Update <debug> peer_manager_handler: Event PM_EVT_PEER_DATA_UPDATE_SUCCEEDED <debug> peer_manager_handler: Peer data updated in flash: peer_id: 0, data_id: Peer rank, action: Update <debug> peer_manager_handler: Event PM_EVT_PEER_DATA_UPDATE_SUCCEEDED <debug> peer_manager_handler: Peer data updated in flash: peer_id: 0, data_id: Local database, action: Update <debug> peer_manager_handler: Event PM_EVT_PEER_DATA_UPDATE_SUCCEEDED <debug> peer_manager_handler: Peer data updated in flash: peer_id: 0, data_id: Local database, action: Update <debug> peer_manager_handler: Event PM_EVT_PEER_DATA_UPDATE_SUCCEEDED <debug> peer_manager_handler: Peer data updated in flash: peer_id: 0, data_id: Local database, action: Update <debug> peer_manager_handler: Event PM_EVT_PEER_DATA_UPDATE_SUCCEEDED <debug> peer_manager_handler: Peer data updated in flash: peer_id: 0, data_id: Local database, action: Update <debug> peer_manager_handler: Event PM_EVT_PEER_DATA_UPDATE_SUCCEEDED <debug> peer_manager_handler: Peer data updated in flash: peer_id: 0, data_id: Local database, action: Update <debug> peer_manager_handler: Event PM_EVT_PEER_DATA_UPDATE_SUCCEEDED <debug> peer_manager_handler: Peer data updated in flash: peer_id: 0, data_id: Local database, action: Update <debug> peer_manager_handler: Event PM_EVT_PEER_DATA_UPDATE_SUCCEEDED <debug> peer_manager_handler: Peer data updated in flash: peer_id: 0, data_id: Central address resolution, action: Update <debug> peer_manager_handler: Event PM_EVT_PEER_DATA_UPDATE_SUCCEEDED <debug> peer_manager_handler: Peer data updated in flash: peer_id: 0, data_id: Central address resolution, action: Update <debug> peer_manager_handler: Event PM_EVT_PEER_DATA_UPDATE_SUCCEEDED <debug> peer_manager_handler: Peer data updated in flash: peer_id: 0, data_id: Central address resolution, action: Update <debug> app: pm_whitelist_get returns 1 addr in whitelist and 1 irk whitelist <info> app: Fast advertising with whitelist. <info> app: Disconnected @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ <debug> peer_manager_handler: Connected, securing connection. conn_handle: 0 <info> app: Connected <debug> app: PHY update request. <debug> nrf_ble_gatt: Peer on connection 0x0 requested a data length of 251 bytes. <debug> nrf_ble_gatt: Updating data length to 27 on connection 0x0. <debug> nrf_ble_gatt: Data length updated to 27 on connection 0x0. <debug> nrf_ble_gatt: max_rx_octets: 27 <debug> nrf_ble_gatt: max_tx_octets: 27 <debug> nrf_ble_gatt: max_rx_time: 2120 <debug> nrf_ble_gatt: max_tx_time: 2120 <debug> nrf_ble_gatt: Peer on connection 0x0 requested an ATT MTU of 293 bytes. <debug> nrf_ble_gatt: Updating ATT MTU to 23 bytes (desired: 23) on connection 0x0. <debug> peer_manager_handler: Event PM_EVT_CONN_SEC_PARAMS_REQ <debug> peer_manager_handler: Security parameter request <debug> peer_manager_handler: Event PM_EVT_CONN_SEC_START <debug> peer_manager_handler: Connection security procedure started: role: Peripheral, conn_handle: 0, procedure: Bonding <debug> peer_manager_handler: Event PM_EVT_CONN_SEC_PARAMS_REQ <debug> peer_manager_handler: Security parameter request <debug> peer_manager_handler: Event PM_EVT_CONN_SEC_SUCCEEDED <info> peer_manager_handler: Connection secured: role: Peripheral, conn_handle: 0, procedure: Bonding <info> app: PM_EVT_CONN_SEC_SUCCEEDED Event <debug> peer_manager_handler: Event PM_EVT_PEER_DATA_UPDATE_SUCCEEDED <debug> peer_manager_handler: Peer data updated in flash: peer_id: 0, data_id: Bonding data, action: Update <info> app: New Bond, add the peer to the whitelist if possible <info> app: m_whitelist_peer_cnt 2, MAX_PEERS_WLIST 8 <debug> peer_manager_handler: Event PM_EVT_PEER_DATA_UPDATE_SUCCEEDED <debug> peer_manager_handler: Peer data updated in flash: peer_id: 0, data_id: Peer rank, action: Update <debug> peer_manager_handler: Event PM_EVT_PEER_DATA_UPDATE_SUCCEEDED <debug> peer_manager_handler: Peer data updated in flash: peer_id: 0, data_id: Local database, action: Update <debug> peer_manager_handler: Event PM_EVT_PEER_DATA_UPDATE_SUCCEEDED <debug> peer_manager_handler: Peer data updated in flash: peer_id: 0, data_id: Central address resolution, action: Update <debug> app: pm_whitelist_get returns 1 addr in whitelist and 1 irk whitelist <info> app: Fast advertising with whitelist. <info> app: Disconnected @@@@@@@@@@@@@@@@@@@ Reconect @@@@@@@@@@@@@@@@@@@@@@ <debug> peer_manager_handler: Event PM_EVT_BONDED_PEER_CONNECTED <debug> peer_manager_handler: Previously bonded peer connected: role: Peripheral, conn_handle: 0, peer_id: 0 <debug> peer_manager_handler: Event PM_EVT_PEER_DATA_UPDATE_SUCCEEDED <debug> peer_manager_handler: Peer data updated in flash: peer_id: 0, data_id: Peer rank, action: Update <info> app: PM_EVT_BONDED_PEER_CONNECTED Event <debug> peer_manager_handler: Event PM_EVT_LOCAL_DB_CACHE_APPLIED <debug> peer_manager_handler: Previously stored local DB applied: conn_handle: 0, peer_id: 0 <debug> peer_manager_handler: Connected, securing connection. conn_handle: 0 <info> app: Connected <debug> peer_manager_handler: Event PM_EVT_CONN_SEC_START <debug> peer_manager_handler: Connection security procedure started: role: Peripheral, conn_handle: 0, procedure: Encryption <debug> peer_manager_handler: Event PM_EVT_CONN_SEC_SUCCEEDED <info> peer_manager_handler: Connection secured: role: Peripheral, conn_handle: 0, procedure: Encryption <debug> peer_manager_handler: Event PM_EVT_PEER_DATA_UPDATE_SUCCEEDED <debug> peer_manager_handler: Peer data updated in flash: peer_id: 0, data_id: Peer rank, action: Update <info> app: PM_EVT_CONN_SEC_SUCCEEDED Event <debug> app: PHY update request. <debug> nrf_ble_gatt: Peer on connection 0x0 requested a data length of 251 bytes. <debug> nrf_ble_gatt: Updating data length to 27 on connection 0x0. <debug> nrf_ble_gatt: Data length updated to 27 on connection 0x0. <debug> nrf_ble_gatt: max_rx_octets: 27 <debug> nrf_ble_gatt: max_tx_octets: 27 <debug> nrf_ble_gatt: max_rx_time: 2120 <debug> nrf_ble_gatt: max_tx_time: 2120 <debug> nrf_ble_gatt: Peer on connection 0x0 requested an ATT MTU of 293 bytes. <debug> nrf_ble_gatt: Updating ATT MTU to 23 bytes (desired: 23) on connection 0x0. <debug> peer_manager_handler: Already encrypted, skipping security. <debug> app: pm_whitelist_get returns 1 addr in whitelist and 1 irk whitelist <info> app: Fast advertising with whitelist. <info> app: Disconnected
I don't understand why the app disconnects only the first time and only on apple devices?
Thank you for help,
Regards,
Blaz
Hi,
Could you print the disconnect reason by adding the following code?
case BLE_GAP_EVT_DISCONNECTED:
NRF_LOG_INFO("Disconnected, reason %d.",
p_ble_evt->evt.gap_evt.params.disconnected.reason);
m_conn_handle = BLE_CONN_HANDLE_INVALID;
break;
-Amanda H.
Hi, actually we have discovered with the sniffer that the nRF connect app on Appel is disconnecting itself without any error or failure.
We will start the production with the current version and in march when the product will be launched we will upgrade the firmware through the app. On Monday I will start with the project from scratch wit the template example.
Thank you for your support.
Regards,
Blaz
Hi, actually we have discovered with the sniffer that the nRF connect app on Appel is disconnecting itself without any error or failure.
We will start the production with the current version and in march when the product will be launched we will upgrade the firmware through the app. On Monday I will start with the project from scratch wit the template example.
Thank you for your support.
Regards,
Blaz