search

zephyrproject-rtos / zephyr

Primary Git Repository for the Zephyr Project. Zephyr is a new generation, scalable, optimized, secure RTOS for multiple hardware architectures.
https://docs.zephyrproject.org
Apache License 2.0
10.55k stars 6.46k forks source link

samples/bluetooth/peripheral_hr: could not connect with reel board #13034

Closed erwango closed 5 years ago

erwango commented 5 years ago

Describe the bug Could not connect to board when running samples/bluetooth/peripheral_hr Works as expected when running samples/bluetooth/peripheral

To Reproduce Steps to reproduce the behavior:

  1. mkdir build; cd build
  2. cmake -DBOARD=reel_board
  3. ninja flash
  4. See error

Expected behavior Connect to board ans see dummy heart rate values.

Impact

Screenshots or console output

Environment (please complete the following information):

Additional context Add any other context about the problem here.

nashif commented 5 years ago

@jhedberg anything that can be done here?

jhedberg commented 5 years ago

I just tried it and get the following repeating itself on the console after a single connect attempt from nRFConnect:

***** Booting Zephyr OS zephyr-v1.13.0-4594-gd6a19afb29 *****
Bluetooth initialized
Advertising successfully started
[00:00:00.007,324] <inf> bt_hci_core: HW Platform: Nordic Semiconductor (0x0002)
[00:00:00.007,354] <inf> bt_hci_core: HW Variant: nRF52x (0x0002)
[00:00:00.007,354] <inf> bt_hci_core: Firmware: Standard Bluetooth controller (0x00) Version 1.13 Build 99
[00:00:00.007,904] <inf> bt_hci_core: Identity: dd:8d:e2:db:34:81 (random)
[00:00:00.007,904] <inf> bt_hci_core: HCI: version 5.0 (0x09) revision 0x0000, manufacturer 0x05f1
[00:00:00.007,904] <inf> bt_hci_core: LMP: version 5.0 (0x09) subver 0xffff
Connected
Disconnected (reason 61)
[00:00:27.218,170] <wrn> bt_ctlr_hci: handle: 0x0000, CSA: 0.
Connected
Disconnected (reason 61)
[00:00:28.128,204] <wrn> bt_ctlr_hci: handle: 0x0000, CSA: 0.
Connected
Disconnected (reason 61)
[00:00:29.034,912] <wrn> bt_ctlr_hci: handle: 0x0000, CSA: 0.
Connected
Disconnected (reason 61)
Connected
[00:00:29.949,981] <wrn> bt_ctlr_hci: handle: 0x0000, CSA: 0.
[00:00:30.851,074] <wrn> bt_ctlr_hci: handle: 0x0000, CSA: 0.
Disconnected (reason 61)
Connected
[00:00:31.771,514] <wDisconnected (reason 61)
rn> bt_ctlr_hci: handle: 0x0000, CSA: 0.
Connected
Disconnected (reason 61)
[00:00:32.680,725] <wrn> bt_ctlr_hci: handle: 0x0000, CSA: 0.
Connected
Disconnected (reason 61)
[00:00:33.594,024] <wrn> bt_ctlr_hci: handle: 0x0000, CSA: 0.
Connected
Disconnected (reason 61)
[00:00:34.601,043] <wrn> bt_ctlr_hci: handle: 0x0000, CSA: 0.

@cvinayak @carlescufi any idea what that controller warning is about?

cvinayak commented 5 years ago

@jhedberg The nRFConnect (seems) not to be using the correct encryption key failing MIC (reason 0x3d or decimal 61). Could you check if you have the same with a phone?

Has there been anything changed in key management in Zephyr, #13083 has similar problem of incorrect key being used in the very first encryption using TK while pairing on second concurrent connection.

jhedberg commented 5 years ago

@cvinayak it's possible either my phone or the reel board flash had some old LTK. Let me clear everything and try again.

jhedberg commented 5 years ago

@cvinayak yep, my phone had an old LTK. After removing it I'm able to connect and receive notifications from the heartrate characteristic just fine. I still get the CSA warning though:

Connected
[00:01:07.779,724] <wrn> bt_ctlr_hci: handle: 0x0000, CSA: 0.

Either way, it seems I cannot reproduce the issue described in this issue. @erwango is it possible you're also experiencing the same thing I did, i.e. some old LTK that wasn't removed?

cvinayak commented 5 years ago

@jhedberg oh, CSA seems a regression. What do you suggestion on the HCI events thats not used by host? Do we need logging? I wanted visible messages outside the INFO level and used WARN during porting. Feel free to or let me know to change to something else.

jhedberg commented 5 years ago

@cvinayak Not completely sure what you mean - the host already has (IIRC) a BT_WARN() for any event it doesn't have a dedicated handler for.

cvinayak commented 5 years ago

@jhedberg Sorry, I mean the ones host has masked out. I guess I have used BT_INFO previously. anyway, we are off topic here, can be taken out side this issue.

erwango commented 5 years ago

@jhedberg , what's LTK?

jhedberg commented 5 years ago

@jhedberg , what's LTK?

Long Term Key. That's the mutually shared encryption key that's created during pairing.

jhedberg commented 5 years ago

@jhedberg , what's LTK?

Long Term Key. That's the mutually shared encryption key that's created during pairing.

E.g. on my iPhone I go to Bluetooth settings, select the device and then select "Forget device" to remove the pairing (i.e. the LTK and any other associated info).

erwango commented 5 years ago

ok, got it working! Txs. Pushed a doc update to get this available to all users.