5340, Zephyr failure to connect to Polar Heart rate strap; ble wireshark trace

[OwainIncus]

Hi ,

I have compiled in Heart rat relay into my app; can scan and connect to simulator and garmin HR straps; but fail to connect to polar.
My debug log shows...

So security is encryption, no auth and I get an "unspecified" error.

I have done a BLE wireshark trace; but cannot see anything in the trace to indicate the issue.

Would be grateful if someon could look and give me a clue to whats going wrong.

Here is wireshark trace....

polarHrmActiveScanConnectFail.pcapng

Regards,

Owain

[Hung Bui]

Hi Owain, 

Error 9 means BT_SMP_ERR_REPEATED_ATTEMPTS. It could suggest that the peer rejected a new bonding. Have you made sure you have remove bonding information on both sides ? 

In the sniffer trace what I can see is that the central didn't continue to do pairing (sending encryption request) after the Pairing Random is sent. 

Could you check on the connection with garmin HR , did the nRF53 bond to that device ? 
And please also check if the phone can bond to the Polar strap. 

[OwainIncus]

static void securityChanged(struct bt_conn *conn, bt_security_t level,
enum bt_security_err err)

in my v2.7.99-ncs1-1 zephyr  conn.h error 9 says BT_SECURITY_ERR_UNSPECIFIED...

enum bt_security_err {
/** Security procedure successful. */
BT_SECURITY_ERR_SUCCESS,

/** Authentication failed. */
BT_SECURITY_ERR_AUTH_FAIL,

/** PIN or encryption key is missing. */
BT_SECURITY_ERR_PIN_OR_KEY_MISSING,

/** OOB data is not available. */
BT_SECURITY_ERR_OOB_NOT_AVAILABLE,

/** The requested security level could not be reached. */
BT_SECURITY_ERR_AUTH_REQUIREMENT,

/** Pairing is not supported */
BT_SECURITY_ERR_PAIR_NOT_SUPPORTED,

/** Pairing is not allowed. */
BT_SECURITY_ERR_PAIR_NOT_ALLOWED,

/** Invalid parameters. */
BT_SECURITY_ERR_INVALID_PARAM,

/** Distributed Key Rejected */
BT_SECURITY_ERR_KEY_REJECTED,

/** Pairing failed but the exact reason could not be specified. */
BT_SECURITY_ERR_UNSPECIFIED,
};

You can see in the central I deleted bonds before attempting to connect to the Polar *the bond deleted was for the garmin); I have also removed the coin cell from the polar to ensure it has deleted any bonds.
. 
I have made a wireshark trace to Android Nrf toolbox bonding/connecting to the polar; and it is quite different. After connect all feature/phy negotiation occurs before the master proceeds to send pairing information.

Where as in my trace for nrf5340 and zephyr we just see it immediately start to pair after the connect. This does not seem right. What do you think.

polarConnectFromNrfToolbox.pcapng

[Hung Bui]

Hei Owain, 

You are right, the error is from the bt_security_err and it's BT_SECURITY_ERR_UNSPECIFIED not BT_SMP_ERR_REPEATED_ATTEMPTS. 

I'm not so sure why the central didn't send LL_ENC_REQ (0x03) after receiving pairing Random from the peripheral. It's most likely the confirm value didn't match with the random value generated. 
You can have a look at this message sequence chart from Bluetooth Spec v5.2 here: 

My suggestion is to try testing the Polar strap with one of our central HR sample to see if it works. Please try to capture a sniffer trace with that.
Also, I don't know if removing the battery on the strap would make it clear the bond information or not. But if you can use other device to make a new bond/update bond then it should work with the nRF53.

I don't think the order where  you do feature/phy request would affect the pairing process. However, you can control when the central starts the pairing process by choosing when to call bt_conn_set_security()

[OwainIncus]

My code is pretty much the Nordic example.

In the connected callback; if I just do the gatt_discover(); all is is good; my Polar H10 works fine; but if I set the security to L2; I get an error flagged in the security_changed callback for level 0 and error 9.

The same code works fine for a Garmin heartstrap setting security to L2.


We have just been using Garmin straps since I last posted the issue; but now I would like to tackle and get the Polar working.

See attached a wireshark BLE trace of the attempted connection from my 5340 to the Polar; setting security to L2.

Can you see anything in this trace to indicate why the connection would be dropped and the heartstrap starts advertising again?

[OwainIncus]

My code is pretty much the Nordic example.

In the connected callback; if I just do the gatt_discover(); all is is good; my Polar H10 works fine; but if I set the security to L2; I get an error flagged in the security_changed callback for level 0 and error 9.

The same code works fine for a Garmin heartstrap setting security to L2.


We have just been using Garmin straps since I last posted the issue; but now I would like to tackle and get the Polar working.

See attached a wireshark BLE trace of the attempted connection from my 5340 to the Polar; setting security to L2.

Can you see anything in this trace to indicate why the connection would be dropped and the heartstrap starts advertising again?

[Hung Bui]

Hi Owain, 

Could you please re-upload the sniffer trace ? 

[OwainIncus]

novaToPolar.pcap.pcapng

[OwainIncus]

Hi Hung,

is this one OK?

[Hung Bui]

Hi Owain, 

Yes I can see the new trace now. 
The new trace shows the exact same situation compared to the last one you sent back in May last year. The nRF5 didn't send the pairing confirm and then the slave disconnected. 
I don't know why the central worked that way. 

As I suggested earlier, have you tried to use the central_hr example we have in the SDK to see if it work ? 

Your central code, does it work with other HR strap ? Did it do bonding with other strap ? 

I would need to see how you configure the central , to see if there is any issue with security configuration. 

[OwainIncus]

I just took another trace to be sure. Yes that is the trace.
Here the debug log ones sees for such a sequence.....

033[1;32mnovaPro>\033[mbt central heart connect 0
\033[1;32mnovaPro>\033[m\033[8D\033[J[00:03:24.080,566] \033[0m<inf> app: Updated MTU: TX: 23 RX: 23 bytes
\033[0m
\033[1;32mnovaPro>\033[m\033[8D\033[J\033[1;32mnovaPro>\033[m\033[8D\033[J[00:03:24.080,932] \033[0m<inf> app: Central connected to F0:C9:75:7D:CB:FF (random)
\033[0m
\033[1;32mnovaPro>\033[m\033[8D\033[J\033[1;32mnovaPro>\033[m\033[8D\033[J[00:03:24.080,993] \033[0m<inf> app: security is currently 1
\033[0m
\033[1;32mnovaPro>\033[m\033[8D\033[J\033[1;32mnovaPro>\033[m\033[8D\033[J[00:03:24.082,550] \033[0m<inf> app: security set to BT_SECURITY_L2
\033[0m
\033[1;32mnovaPro>\033[m\033[8D\033[J\033[1;32mnovaPro>\033[m\033[8D\033[J[00:03:24.086,486] \033[0m<inf> app: System got EVENT_BLE_PERIPHERAL_CONNECTED\033[0m
\033[1;32mnovaPro>\033[m\033[8D\033[J\033[1;32mnovaPro>\033[m\033[8D\033[J[00:03:40.088,104] \033[0m<inf> app: Pairing failed: F0:C9:75:7D:CB:FF (random) reason: 9
\033[0m
\033[1;32mnovaPro>\033[m\033[8D\033[J\033[1;32mnovaPro>\033[m\033[8D\033[J[00:03:40.088,348] \033[0m<inf> app: Security failed: F0:C9:75:7D:CB:FF (random) level 1 err 9
\033[0m
\033[1;32mnovaPro>\033[m\033[8D\033[J\033[1;32mnovaPro>\033[m\033[8D\033[J[00:03:40.088,409] \033[1;31m<err> bt_gatt_dm: Discover failed, error: -128.\033[0m
\033[1;32mnovaPro>\033[m\033[8D\033[J\033[1;32mnovaPro>\033[m\033[8D\033[J[00:03:40.088,470] \033[0m<inf> app: Could not start the discovery procedure, error code: -128
\033[0m
\033[1;32mnovaPro>\033[m\033[8D\033[J\033[1;32mnovaPro>\033[m\033[8D\033[J[00:03:40.094,299] \033[0m<inf> app: Peripheral disconnected (reason 0x08)
\033[0m
\033[1;32mnovaPro>\033[m\033[8D\033[J\033[1;32mnovaPro>\033[m\033[8D\033[J[00:03:40.105,041] \033[0m<inf> app: System got EVENT_BLE_PERIPHERAL_DISCONNECTED\033[0m
\0

What we see here is in the connected() callback; where I check the security level before sayng I wish to set the L2.

Then 16 seconds later we see the securityChanged() callback with the level 1 error 9; followed by we drop into try and do the gatt_disover().

Looking into the bluetooth trace (I am not that familiar with these low level BLE protocols); packet 2568 at time 23.20s the slave sends the master a "SMP receved pairing random"; after which we just see empty PDU's tll approx 41s when the connection is dropped and the heartstrap starts advertising again.


So what is Noridic BT stack doing in those 16 seconds where the connencton is up; but t has not reported the success or failure; till the end of the 16 seconds where the error is reported?

I will try and get a better trace.

[OwainIncus]

Hi Hung,

I attached the config yesterday. Yeah all works fine with the Gamin strap; bonded ok.