nRF52840 pairing error on one specific device

[fr_adv]

Dear support team and community

After some days where it worked perfectly, our nRF52840 suddently stopped connecting anymore to a Motorola G4 plus running Android 7.1.1.

The same firmware running on a different nRF52840 can pair, bond, and connect well to the same smartphone.

We are running SDK v2.3.0 with ZephyrOS, and are using the default configuration here. The bonding information are saved in the flash memory (CONFIG_BT_SETTINGS=y), and this works perfectly on multiple other devices. For your information, the BT_LL_SOFTDEVICE flag is set in kconfig (I did not set it manually).

The logs with the info level are : 

[00:05:36.819,091] <inf> BLE: Connected via connection (0) at 7C:6B:E3:81:40:AE (random)

[00:05:36.819,335] <inf> BLE: Connection (0) - Initial Tx Power = 3

[00:05:36.819,335] <inf> BLE: Connection parameters: interval 48.75 ms, latency 0 intervals, timeout 20000 ms

[00:05:37.676,055] <inf> BLE: Connection parameters updated: interval 7.50 ms, latency 0 intervals, timeout 20000 ms

[00:05:38.369,720] <inf> BLE: Connection parameters updated: interval 48.75 ms, latency 0 intervals, timeout 20000 ms

[00:05:39.040,924] <inf> BLE: Connection parameters updated: interval 7.50 ms, latency 0 intervals, timeout 20000 ms

[00:05:39.147,399] <inf> BLE: Security changed: 7C:6B:E3:81:40:AE (random) level 2

[00:05:39.222,015] <wrn> bt_smp: SMP does not allow a pairing failure at this point. Known issue. Disconnecting instead.

[00:05:39.222,656] <wrn> bt_att: Not connected

[00:05:39.222,686] <err> bt_conn: not connected!

[00:05:39.222,778] <inf> BLE: Connection parameters updated: interval 48.75 ms, latency 0 intervals, timeout 20000 ms

[00:05:39.284,881] <inf> BLE: Disconnected (reason 22)

The reason In the source code where the bt_smp warning log appears, I can see :

	/* By spec, SMP "pairing process" completes successfully when the last
	 * key to distribute is acknowledged at link-layer.
	 */
	remote_already_completed = (atomic_test_bit(smp->flags, SMP_FLAG_KEYS_DISTR) &&
				    !smp->local_dist && !smp->remote_dist);

	if (atomic_test_bit(smp->flags, SMP_FLAG_PAIRING) ||
	    atomic_test_bit(smp->flags, SMP_FLAG_ENC_PENDING) ||
	    atomic_test_bit(smp->flags, SMP_FLAG_SEC_REQ)) {
		/* reset context and report */
		smp_pairing_complete(smp, reason);
	}

	if (remote_already_completed) {
		LOG_WRN("SMP does not allow a pairing failure at this point. Known issue. "
			"Disconnecting instead.");
		/* We are probably here because we are, as a peripheral, rejecting a pairing based
		 * on the central's identity address information, but that was the last key to
		 * be transmitted. In that case, the pairing process is already completed.
		 * The SMP protocol states that the pairing process is completed the moment the
		 * peripheral link-layer confirmed the reception of the PDU with the last key.
		 */
		bt_conn_disconnect(smp->chan.chan.conn, BT_HCI_ERR_AUTH_FAIL);
		return 0;
	}

I don't understand the meaning of this issue, can you help me with some unlightening ? Would deleting the bonding information for this specific device in the nRF52 flash memory be a fix ? If yes, how to proceed ? 

[Simonr]

Hi

If you're using the nRF Connect SDK (Zephyr RTOS based SDK), you should not look at the Infocenter, as that only documents our products and the nRF5 SDK (bare metal SDK).

The documentation for the nRF Connect SDK can be found here: https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/index.html 

I think you can add a check for the disconnect reason or for this AUTH_FAIL and then if that triggers you can unpair from the device on your end. 

Best regards,

Simon

[fr_adv]

Dear Simon,

Thank you for the link and the answer. The check for the disconnect reason is not sufficient from my point of view, since I always get reason 22 (BT_HCI_ERR_LOCALHOST_TERM_CONN) and there could be several other scenarios leading to the same disconnecting reason that should not trigger an erasure of the bonding informations. 

I cannot successfully find a way to get the AUTH_FAIL error in the disconnection callback. If the security_changed callback was called on this error, I would have access to the error type bt_security_err, but this is not the case here.

Do you know how I could get this AUTH_FAIL status in the disconnect callback ?  Or access any other flag that could help me to address this issue specifically ? I have the feeling this is not possible. 

Best regards,

Aurélien