Pairing passkey , cancel pairing on android side still give access to characteristic

RE: Pairing passkey , cancel pairing on android side still give access to characteristic

Olfox — Wed, 17 Feb 2021 11:25:28 GMT

Ok issue of fast connect /disconnect happens with your app, but also with mine, so may be it is linked to Android ?

I have implemented the reste to check for disconnexion and it works fine :).

We are very busy now with pairing in our app. Do you know if NrfConnect i sable to get from IOs and Android the list of paired devices ?

Because we scan and try to connect to a list of paired succesfully devices saved into our app when we launch it. But imagine user has unpaired with android menu. we try to connect something unpaired. So in running mode , the pop up pairing keys happens to enter 6 digit. But It is on top of our app and we have no way to give the good code to enter to the user...

RE: Pairing passkey , cancel pairing on android side still give access to characteristic

Amanda Hsieh — Wed, 17 Feb 2021 10:20:43 GMT

Hi Florian,

[quote user="Olfox"]Hm so it is "normal" .[/quote]

That is not normal. It is a known issue on our app.

[quote user="Olfox"]

- use a read autorization on characteristic that should generate BLE_GATTS_EVT_RW_AUTHORIZE_REQUEST event in ble_on_ble_evt function, for each trial of reading. I will clear a timeout timer in this event. If timeout timer occurs, i force disconnection.

[/quote]

I think it's a good solution. You could add a timeout in your application to check if you get some activity specific to the app you are using (read or writes to a specific characteristic etc). See my colleague Susheel's answer in this post for the timeout implement.

[quote user="Olfox"]

Rely on the NRF_BLE_CONN_PARAMS_MAX_SUPERVISION_TIMEOUT_DEVIATION that, if i understood should expire after a certain time of inactivity, what is not the case in my application it is set to 65535 so around 11minutes but it never generate any ble event or force disconnect. Do i understand correctly its purpose ? Is there some code to add to manage it ?

[/quote]

All BLE connections have a supervision timeout. If there are no packets within the supervision timeout, the connection will end with the disconnect reason being "timeout". However, the BLE connection will not end, as long as the BLE stack on the phone still works. From your log, the master (phone) still sent the ack. Therefore, it would not disconnect after a supervision timeout.

-Amanda H.

RE: Pairing passkey , cancel pairing on android side still give access to characteristic

Olfox — Tue, 16 Feb 2021 10:39:57 GMT

Hm so it is "normal" . But impossible to let the system running this way, batterie will die very fast, so i need a mecanism to detect if nobody is really connected, else i'm stuck in this state for ever...

SO i see two posibilities:

2 questions here:

1. How to "reload" the timer dynamically when it is running. I see no API funciton to do this and i meet a lot of trouble with stop , change et start timer function when it is already running. As it count from 0 to x , should i just clear a register ot a variable ?

2. Should i call in BLE_GATTS_EVT_RW_AUTHORIZE_REQUEST event ? According tho this schematics, i have to give authorize by answering to Soft Device that it can give access to peer.

Thanks a lot !

RE: Pairing passkey , cancel pairing on android side still give access to characteristic

Amanda Hsieh — Tue, 16 Feb 2021 08:32:16 GMT

Hi Florian,

As I know from other cases, if you connect and disconnect very fast, the app might not send out the disconnection command as expected. From your sniffer log, the phone is actually still in a connection. If the app sends a disconnection command, you should see the opcode in the log as

-Amanda H.

RE: Pairing passkey , cancel pairing on android side still give access to characteristic

Olfox — Fri, 12 Feb 2021 14:15:21 GMT

Yes , i was able to reproduce the problem( it is quiet easy unfortunatly ...) and here is the log. We see that there is no packet exchange anymore once i break the link by exiting my screen on my app.

#define NRF_BLE_CONN_PARAMS_MAX_SUPERVISION_TIMEOUT_DEVIATION 65535

what should happen after 65353 ms ( almost 11 minutes?), because i let it run in this bad deconnexion states and nothing happens.

thank you !

devzone.nordicsemi.com/.../links-keep-connected-on-uC-but-not-in-android-connect-lign20866.pcapng

I can also see in my nrf console after breaking the link this :BLE_GAP_EVT_CONN_PARAM_UPDATE occurs. one time.

RE: Pairing passkey , cancel pairing on android side still give access to characteristic

Amanda Hsieh — Fri, 12 Feb 2021 13:12:27 GMT

I think the only way to find the cause we need an on-air sniffer log. I suspect the case here may be that the phone is actually still in a connection here, or at least the phone think it is in a connection since it may be waiting for an ack on the previous terminate link packet. If the ack is lost, then the phone will need to wait for a supervisor timeout before the next link can be established. The peer device will only send one ack when receiving the terminate link packet before disconnect, this is according to BLE spec.

-Amanda H.

RE: Pairing passkey , cancel pairing on android side still give access to characteristic

Olfox — Fri, 12 Feb 2021 10:52:08 GMT

Thanks Amanda,

I have another issue, when i connect and disconnect very fast , nrf52 connect, start running timer etc .. but doesn't detect the disconnexion. So my system run and consume while nobody is no more connected. The bad thing is that, there is no prossibility at the moment to detect it.

Is there a way to detect a disconnexion even if the BLE _EVT_DISCONNECT has not been set ? I was thinking to use a timer that i reload after each charceteristic reading, and if it times out i force a disconnexion.

I have seen a timer existing in gls example : PM_HANDLER_SEC_DELAY_MS

But it seems to not manage this deconnexion missing detection

RE: Pairing passkey , cancel pairing on android side still give access to characteristic

Amanda Hsieh — Fri, 12 Feb 2021 08:23:51 GMT

Hi Florian,

[quote user="Olfox"]But is there a way to pop up 6 digit windows after connexion and not only when i try to read a characteristic ?[/quote]

You need to add pm_handler_secure_on_connection to ble_evt_handler function to handle the connection? The function is for securing a connection when it is established. You can refer to ble_app_gls on how to use it.

[quote user="Olfox"]How many bounded device can we add in memory before to be full ?[/quote]

See this answer.

[quote user="Olfox"]3. Sould I prepare a way to clean bounded device to avoid being out of memory ?[/quote]

You can use pm_peers_delete() which is a function deleting all data stored for all peers. As for the disconnections, you do this however you like, for example by calling a sd_ble_gap_disconnect event. You can refer to ble_app_gls on how to use it.

[quote user="Olfox"]4. If i do the contrarie, keep bounded in android nrf App, but clear my uC. I try to connect, and this error happen:[/quote]

The error is as expected because the device lost the bond information. You have to delete bond info on the phone.

-Amanda H.

RE: Pairing passkey , cancel pairing on android side still give access to characteristic

Olfox — Thu, 11 Feb 2021 12:58:35 GMT

That was the point !!!

Thanks, now if i click Cancel when pop up arrive, it disconnects the link and i also add all the print for pm_event. When i click cancel i can see PM_EVT_CONN_SEC_FAILED happen and then cnnexion is forced close by nrf52833 so that's good !

I have still few thing that is not perfect:

1. When chip is erased, blank, no bounded device in memory. Android not bounded anymore too. All systeme freshly new. I can connect and see the list of char. Because i protected it, i can't read without pairing by 6 digit code. But is there a way to pop up 6 digit windows after connexion and not only when i try to read a characteristic ?

2.I f i unbound from Android side, for sur, it stay bounded in my nrf52 memory. How many bounded device can we add in memory before to be full ?

3. Sould I prepare a way to clean bounded device to avoid being out of memory ? I have a settings char, can i use it for calling a cleaning bounded device function for example or is there a better native way to do it please ?

4. If i do the contrarie, keep bounded in android nrf App, but clear my uC. I try to connect, and this error happen:

<info> app: 	 PM_EVT_CONN_SEC_START                 	
<info> peer_manager_handler: Connection security failed: role: Peripheral, conn_handle: 0x0, procedure: Encryption, error: 4102
<warning> peer_manager_handler: Disconnecting conn_handle 0.
<info> app: 	 PM_EVT_CONN_SEC_FAILED                	
<info> app: 	  BLE_GAP_EVT_SEC_INFO_REQUEST	
<debug> nrf_sdh_ble: BLE event: 0x11.
<info> app: DISCONNECTED

pop up windows doesn't appear, so i have to unbound in Android and start a fresh new pairing process.

thanks a lot for your help, at least i progress 🙂

RE: Pairing passkey , cancel pairing on android side still give access to characteristic

Amanda Hsieh — Thu, 11 Feb 2021 12:05:12 GMT

You need pm_handler_disconnect_on_sec_failure() function as the ble_app_gls example to disconnect when the connection could not be secured.

-Amanda H.

RE: Pairing passkey , cancel pairing on android side still give access to characteristic

Olfox — Thu, 11 Feb 2021 11:19:53 GMT

Ha no , i just compare both code and i don't have the same in main. I have this :

static void pm_evt_handler(pm_evt_t const * p_evt)
{
    pm_handler_on_pm_evt(p_evt);
    pm_handler_flash_clean(p_evt);
}

So by going deeper i see there is some check in peer_manager_handler.c , but it doesn't disconnect if it wasn't a mitm connexion like in gls code.

Here is the management in my handler:

void pm_handler_on_pm_evt(pm_evt_t const * p_pm_evt)
{
    pm_handler_pm_evt_log(p_pm_evt);

    if (p_pm_evt->evt_id == PM_EVT_BONDED_PEER_CONNECTED)
    {
        conn_secure(p_pm_evt->conn_handle, false);
    }
    else if (p_pm_evt->evt_id == PM_EVT_ERROR_UNEXPECTED)
    {
        NRF_LOG_ERROR("Asserting.");
        APP_ERROR_CHECK(p_pm_evt->params.error_unexpected.error);
    }
}

At first connect, user has not yet pairing with the code, so will the connexion be closed ?

Thanks a lot , i hope it is the weak point in my system

RE: Pairing passkey , cancel pairing on android side still give access to characteristic

Amanda Hsieh — Thu, 11 Feb 2021 10:11:42 GMT

Hi Florian,

Do you add pm_handler_secure_on_connection to ble_evt_handler function to handle the connection? The function is for securing a connection when it is established. You can refer to ble_app_gls on how to use it.

-Amanda H.

RE: Pairing passkey , cancel pairing on android side still give access to characteristic

Olfox — Tue, 09 Feb 2021 13:34:17 GMT

The same if i fully erased the device, each time it should pop up the passkey window it crash. I notice that it didn't solve the probleme of not poping up the windows after erased memory, i can reach characteristic and error 16 occurs when i try to read the char.

RE: Pairing passkey , cancel pairing on android side still give access to characteristic

Olfox — Tue, 09 Feb 2021 13:29:11 GMT

I did for MITM not for LESC as i thought it was one or the other

#define SEC_PARAM_BOND 1 /**< Perform bonding. */
#define SEC_PARAM_MITM 1 /**< Man In The Middle protection not required. */
#define SEC_PARAM_LESC 0 /**< LE Secure Connections not enabled. */

Si have enable it, but an error 16 happens.

<info> app: CONNECTED
<info> app: In ble_ircam_eeprom_value_update. 

<info> app: Init Ircam and tpms sensors done, Run.
<debug> nrf_sdh_ble: BLE event: 0x3A.
<debug> nrf_ble_gatt: ATT MTU updated to 247 bytes on connection 0x0 (response).
<debug> nrf_sdh_ble: BLE event: 0x12.
<info> app: 	  BLE_GAP_EVT_CONN_PARAM_UPDATE	
<debug> nrf_sdh_ble: BLE event: 0x23.
<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.
<info> app: 	  BLE_GAP_EVT_DATA_LENGTH_UPDATE_REQUEST	
<debug> nrf_sdh_ble: BLE event: 0x24.
<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
<info> app: 	  BLE_GAP_EVT_DATA_LENGTH_UPDATE	
<debug> nrf_sdh_ble: BLE event: 0x12.
<info> app: 	  BLE_GAP_EVT_CONN_PARAM_UPDATE	
<debug> nrf_sdh_ble: BLE event: 0x13.
<error> peer_manager_sm: Could not perform security procedure. smd_params_reply() or smd_link_secure() returned NRF_ERROR_INVALID_ADDR. conn_handle: 0
<error> peer_manager_handler: Unexpected fatal error occurred: error: NRF_ERROR_INVALID_ADDR
<error> peer_manager_handler: Asserting.
<error> app: ERROR 16 [NRF_ERROR_INVALID_ADDR] at C:\nordic\nRF5SDK160098a08e2\components\ble\peer_manager\peer_manager_handler.c:294

RE: Pairing passkey , cancel pairing on android side still give access to characteristic

Amanda Hsieh — Tue, 09 Feb 2021 13:13:38 GMT

Did you set enable SEC_PARAM_MITM and SEC_PARAM_LESC in peer_manager_init()?

If you use the main.c of hrs example, you need to modify as the following:

#define SEC_PARAM_MITM 1 /**< Man In The Middle protection not required. */
#define SEC_PARAM_LESC 1 /**< LE Secure Connections enabled. */

-Amanda H.

RE: Pairing passkey , cancel pairing on android side still give access to characteristic

Olfox — Tue, 09 Feb 2021 11:20:15 GMT

Here a comparaison between the two console of this two case. Left, first connexion from scratch ( no bounded , nrf52833 erased) where no passkey pop up after connexion, but only when i try to read a char. And the right one, after disconnected and reconnect again where passkey pop up appears after connexion and no more after when reading char.

RE: Pairing passkey , cancel pairing on android side still give access to characteristic

Olfox — Tue, 09 Feb 2021 10:53:03 GMT

So i have tested with BLE_GAP_CONN_SEC_MODE_SET_ENC_WITH_MITM . I still have cancel pairing no impact effect. But i don't have pop up windows for each char. Because i think in flash this phone is memorized .

So i did a test, I erase all my flash. Programm debug bootloader, settings page, Softdevice s113 and run the fw. Scan on android, connect. First, no pop up to enter 6 digit appears. I see all my char. When i try to read, the pop up 6 digit ask for the passkey. If i enter it , i can read the char and three other too.

Now i diconnect and unbound on android side. Re connect. And here pop up window appear ! It was not the case at the first trial, idon't know why. May be because now , it is bounded in my flash, so it ask after connexion . I don't enter the code, and it runs for a while, keeping the connexion but doing nothing on android side ( just a circular row running in loop telling me it is waiting for something indefinitively).

So i disconnect. I re connect, it ask for the paskey, i enter it successfully . I can read my char without re entering passkey.

If i disconnect, and reconnect, now it is succesfully bounded, so no more pop and everything is fine.

Conclusion, there is something not robust at pairing phase when nobody knows each others, and i click cancel.

RE: Pairing passkey , cancel pairing on android side still give access to characteristic

Olfox — Tue, 09 Feb 2021 10:27:54 GMT

Thanks Amanda,

1.does it means 6 digit cancel behavior is normal and that we can't use that to avoid to read characeteristics ?

2.If yes , what is the purpose of this pairing method ?

3. with BLE_GAP_CONN_SEC_MODE_SET_ENC_NO_MITM , is it normal to hav the pop up windows and that we need to re enter each time the 6 digit ?

Thank you !

RE: Pairing passkey , cancel pairing on android side still give access to characteristic

Olfox — Tue, 09 Feb 2021 10:23:26 GMT

Here is my console trace when i click on cancel and wait ( no fast click on characteristic):

<info> app: ADVERTISING ! Wait connexion or TIMEOUT...
<debug> nrf_sdh_ble: BLE event: 0x10.
<info> peer_manager_handler: Peer data updated in flash: peer_id: 0, data_id: Peer rank, action: Update, no change
<debug> nrf_ble_gatt: Requesting to update ATT MTU to 247 bytes on connection 0x0.
<info> app: CONNECTED

<debug> nrf_sdh_ble: BLE event: 0x3A.
<debug> nrf_ble_gatt: ATT MTU updated to 247 bytes on connection 0x0 (response).
<debug> nrf_sdh_ble: BLE event: 0x12.

<info> app: 	  BLE_GAP_EVT_CONN_PARAM_UPDATE	
<debug> nrf_sdh_ble: BLE event: 0x23.
<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.
<info> app: 	  BLE_GAP_EVT_DATA_LENGTH_UPDATE_REQUEST	
<debug> nrf_sdh_ble: BLE event: 0x24.
<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_sdh_ble: BLE event: 0x12.
<info> app: 	  BLE_GAP_EVT_CONN_PARAM_UPDATE	
<debug> nrf_sdh_ble: BLE event: 0x19.
<info> app: 	  BLE_GAP_EVT_AUTH_STATUS	
<debug> nrf_sdh_ble: BLE event: 0x12.
<info> app: 	  BLE_GAP_EVT_CONN_PARAM_UPDATE	
<debug> nrf_sdh_ble: BLE event: 0x11.
<info> app: DISCONNECTED

<info> app: try to advertise...
<info> app: ADVERTISING ! Wait connexion or TIMEOUT...

Here the trace if i do nothing when pop up 6 digit happens:

<info> app: try to advertise...
<info> app: ADVERTISING ! Wait connexion or TIMEOUT...
<debug> nrf_sdh_ble: BLE event: 0x10.
<info> peer_manager_handler: Peer data updated in flash: peer_id: 0, data_id: Peer rank, action: Update, no change
<debug> nrf_ble_gatt: Requesting to update ATT MTU to 247 bytes on connection 0x0.
<info> app: CONNECTED

<debug> nrf_sdh_ble: BLE event: 0x3A.
<debug> nrf_ble_gatt: ATT MTU updated to 247 bytes on connection 0x0 (response).
<debug> nrf_sdh_ble: BLE event: 0x12.
<info> app: 	  BLE_GAP_EVT_CONN_PARAM_UPDATE	
<debug> nrf_sdh_ble: BLE event: 0x23.
<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.
<info> app: 	  BLE_GAP_EVT_DATA_LENGTH_UPDATE_REQUEST	
<debug> nrf_sdh_ble: BLE event: 0x24.
<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
<info> app: 	  BLE_GAP_EVT_DATA_LENGTH_UPDATE	
<debug> nrf_sdh_ble: BLE event: 0x12.
<info> app: 	  BLE_GAP_EVT_CONN_PARAM_UPDATE	
<debug> nrf_sdh_ble: BLE event: 0x12.
<info> app: 	  BLE_GAP_EVT_CONN_PARAM_UPDATE	
<debug> nrf_sdh_ble: BLE event: 0x19.
<info> app: 	  BLE_GAP_EVT_AUTH_STATUS	
<debug> nrf_sdh_ble: BLE event: 0x11.
<info> app: DISCONNECTED
<info> app: try to advertise...
<info> app: ADVERTISING ! Wait connexion or TIMEOUT...
<debug> nrf_sdh_ble: BLE event: 0x26.
<debug> app: ADVERTISING TIMEOUT, ADV_SET_TERMINATED :(
<info> app: ACCEL IN LOW POWER

RE: Pairing passkey , cancel pairing on android side still give access to characteristic

Amanda Hsieh — Tue, 09 Feb 2021 10:23:09 GMT

Hi Florian,

[quote user=""]I know i can protect each caracteristic by using : BLE_GAP_CONN_SEC_MODE_SET_ENC_NO_MITM , what i did. [/quote]

BLE_GAP_CONN_SEC_MODE_SET_ENC_NO_MITM will set sec_mode pointed to by ptr to require encryption, but no MITM protection.

I think you can try to set BLE_GAP_CONN_SEC_MODE_SET_ENC_WITH_MITM for your requirement, and this example LE Secure Connections Multirole Example is similar to your case.

-Amanda H.

RE: Pairing passkey , cancel pairing on android side still give access to characteristic

Olfox — Tue, 09 Feb 2021 09:46:00 GMT

I have added code in main to print all ble GAP event that occurs.

static void ble_evt_handler(ble_evt_t const * p_ble_evt, void * p_context)
{
uint32_t err_code = NRF_SUCCESS;

switch (p_ble_evt->header.evt_id)
{

case BLE_GAP_EVT_CONN_PARAM_UPDATE : NRF_LOG_INFO ( " BLE_GAP_EVT_CONN_PARAM_UPDATE " ) ; break ;
case BLE_GAP_EVT_SEC_PARAMS_REQUEST : NRF_LOG_INFO ( " BLE_GAP_EVT_SEC_PARAMS_REQUEST " ) ; break ;
case BLE_GAP_EVT_SEC_INFO_REQUEST : NRF_LOG_INFO ( " BLE_GAP_EVT_SEC_INFO_REQUEST " ) ; break ;
case BLE_GAP_EVT_PASSKEY_DISPLAY : NRF_LOG_INFO ( " BLE_GAP_EVT_PASSKEY_DISPLAY " ) ; break ;
case BLE_GAP_EVT_KEY_PRESSED : NRF_LOG_INFO ( " BLE_GAP_EVT_KEY_PRESSED " ) ; break ;
case BLE_GAP_EVT_AUTH_KEY_REQUEST : NRF_LOG_INFO ( " BLE_GAP_EVT_AUTH_KEY_REQUEST " ) ; break ;
case BLE_GAP_EVT_LESC_DHKEY_REQUEST : NRF_LOG_INFO ( " BLE_GAP_EVT_LESC_DHKEY_REQUEST " ) ; break ;
case BLE_GAP_EVT_AUTH_STATUS : NRF_LOG_INFO ( " BLE_GAP_EVT_AUTH_STATUS " ) ; break ;
case BLE_GAP_EVT_CONN_SEC_UPDATE : NRF_LOG_INFO ( " BLE_GAP_EVT_CONN_SEC_UPDATE " ) ; break ;
case BLE_GAP_EVT_RSSI_CHANGED : NRF_LOG_INFO ( " BLE_GAP_EVT_RSSI_CHANGED " ) ; break ;
case BLE_GAP_EVT_SEC_REQUEST : NRF_LOG_INFO ( " BLE_GAP_EVT_SEC_REQUEST " ) ; break ;
case BLE_GAP_EVT_SCAN_REQ_REPORT : NRF_LOG_INFO ( " BLE_GAP_EVT_SCAN_REQ_REPORT " ) ; break ;
case BLE_GAP_EVT_PHY_UPDATE : NRF_LOG_INFO ( " BLE_GAP_EVT_PHY_UPDATE " ) ; break ;
case BLE_GAP_EVT_DATA_LENGTH_UPDATE_REQUEST : NRF_LOG_INFO ( " BLE_GAP_EVT_DATA_LENGTH_UPDATE_REQUEST " ) ; break ;
case BLE_GAP_EVT_DATA_LENGTH_UPDATE : NRF_LOG_INFO ( " BLE_GAP_EVT_DATA_LENGTH_UPDATE " ) ; break ;

When i click in pop up windows on Cancel, i catch BLE_GAP_EVT_AUTH_STATUS. This flag is treated by this piece of code in security_dispatcher.c :

/**@brief Function for processing the @ref BLE_GAP_EVT_AUTH_STATUS event from the SoftDevice.
 *
 * @param[in]  p_gap_evt  The event from the SoftDevice.
 */
static void auth_status_process(ble_gap_evt_t const * p_gap_evt)
{
    switch (p_gap_evt->params.auth_status.auth_status)
    {
        case BLE_GAP_SEC_STATUS_SUCCESS:
            auth_status_success_process(p_gap_evt);
            break;

        default:
            auth_status_failure_process(p_gap_evt);
#if PM_RA_PROTECTION_ENABLED
            ast_auth_error_notify(p_gap_evt->conn_handle);
#endif // PM_RA_PROTECTION_ENABLED
            break;
    }
}

I note that a piece of code is disabled because PM_RA_PROTECTION_ENABLED is cleared to 0 in my sdk_config.h , what avoid re pairing.

So it could be the source of my issue ? because i already paired this phone once, it is in my autorized list in the nrf52833 and then even if i cancel it works ?

I have enabled this flag but same behavior of the app.

So is it to me to manage via BLE_GAP_EVT_AUTH_STATUS, and try to ask for a new pairing code, or close connextion may be ? How it done usually. I find this strange that by default this case is not cover, it is a basic security fault in this state, i hope it comes from my code.

RE: Pairing passkey , cancel pairing on android side still give access to characteristic

Olfox — Tue, 09 Feb 2021 08:09:50 GMT

Here is a capture on android of the problem. I first connect, and click cancel on 6digit input windows, then i clicke fast to read characteristic. Once read, i'm still connecting, passkey has been totaly by passed... Second try i input the correct pas kay, and i get same result than without ( what i want in fact ):

devzone.nordicsemi.com/.../20210209_2D00_085252_2D00_720x1280.mp4