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

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

Parents
  • 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. 

  • 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

  • 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?




  • Hi Owain, 


    Could you please re-upload the sniffer trace ? 

  • 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. 

Reply
  • 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. 

Children
Related