libusb - double reportmaps in log after power cycle paired device

[gvdhoven]

If i start my app for the first time, and pair with (in this case) Android TV, i get this;

Packet Log: /tmp/hci_dump.pklg
USB Path: 01-05
BTstack up and running on 00:15:83:F6:AA:4A.
LE Connection Complete:
- Connection Interval: 50.00 ms
- Connection Latency: 0
Just Works requested
LE Connection Update:
- Connection Interval: 7.50 ms
- Connection Latency: 0
LE Connection Update:
- Connection Interval: 50.00 ms
- Connection Latency: 0
LE Connection Update:
- Connection Interval: 7.50 ms
- Connection Latency: 0
LE Connection Update:
- Connection Interval: 50.00 ms
- Connection Latency: 0
Report Characteristic Subscribed 1
Boot Keyboard Characteristic Subscribed 1
^CCTRL-C - SIGINT received, shutting down..
Disconnected

At this time i am successfully connected to my device. Notice there is no "Disconnected" at the 3rd line. 1_initial_pairing.zip

When I restart my peripheral i see this:

Packet Log: /tmp/hci_dump.pklg
USB Path: 01-05
Disconnected
BTstack up and running on 00:15:83:F6:AA:4A.
LE Connection Complete:
- Connection Interval: 50.00 ms
- Connection Latency: 0
^CCTRL-C - SIGINT received, shutting down..
Disconnected

So, i see a 'disconnected' at the second line and i see no reportmap subscribed, so i kill the process after some time. 2_restart_no_reportmap.zip

So i restart my app once more, and then i get this:

Packet Log: /tmp/hci_dump.pklg
USB Path: 01-05
Disconnected
BTstack up and running on 00:15:83:F6:AA:4A.
LE Connection Complete:
- Connection Interval: 50.00 ms
- Connection Latency: 0
Just Works requested
LE Connection Update:
- Connection Interval: 7.50 ms
- Connection Latency: 0
LE Connection Update:
- Connection Interval: 50.00 ms
- Connection Latency: 0
Report Characteristic Subscribed 1
Report Characteristic Subscribed 1
Boot Keyboard Characteristic Subscribed 1
Boot Keyboard Characteristic Subscribed 1
^CCTRL-C - SIGINT received, shutting down..
Disconnected

As you can see, i see two reportmaps subscribed for some reason... 3_restart_double_reportmap.zip

Why doesn't a restart always result in a reconnect (e.g. the device shows i am connected, but doesn't do a reportmap subscribe for some reason, it looks like this request is 'cached' somewhere and happes on the 2nd restart, hence the double reportmap callback.

What am i doing wrong? Can you see based on the attached package logs? Is there something in code i am doing wrong (i am just re-using hog_keyboard_demo.c, but then with "Just works" pairing and i added the l2cap_register_packet_handler(&peripheral_packet_handler); from the mouse demo after l2cap_init();.

[gvdhoven]

Update:

USB Path: 01-05
BTstack up and running on 00:15:83:F6:AA:4A.
[BLE HID peripheral]: Client connection complete:
[BLE HID peripheral]: - Connection Interval: 50.00 ms
[BLE HID peripheral]: - Connection Latency: 0
[BLE HID peripheral]: Boot Keyboard Characteristic Subscribed 1
[BLE HID peripheral]: Report Characteristic Subscribed 1
-- (rebooted my main device) --
[BLE HID peripheral]: Client disconnected
[BLE HID peripheral]: Client connection complete:
[BLE HID peripheral]: - Connection Interval: 48.75 ms
[BLE HID peripheral]: - Connection Latency: 0
[BLE HID peripheral]: Boot Keyboard Characteristic Subscribed 1
[BLE HID peripheral]: Report Characteristic Subscribed 1
[BLE HID peripheral]: Report Characteristic Subscribed 1
[BLE HID peripheral]: Boot Keyboard Characteristic Subscribed 1

As you can see, on a reboot i also get the double subscription.

New LOG added

Still running master branch from some time ago, will try to switch to DEV and compare.

[gvdhoven]

DEV (commit: 214bfd6) doesn't give much difference; hci_dump.zip

USB Path: 01-05
Local version information:
- HCI Version    0x0006
- HCI Revision   0x22bb
- LMP Version    0x0006
- LMP Subversion 0x22bb
- Manufacturer 0x000a
BTstack up and running on 00:15:83:F6:AA:4A.
[BLE HID peripheral]: Client connection complete:
[BLE HID peripheral]: - Connection Interval: 48.75 ms
[BLE HID peripheral]: - Connection Latency: 0
[BLE HID peripheral]: Boot Keyboard Characteristic Subscribed 1
[BLE HID peripheral]: Report Characteristic Subscribed 1
-- (rebooted my main device) --
[BLE HID peripheral]: Client disconnected
[BLE HID peripheral]: Client connection complete:
[BLE HID peripheral]: - Connection Interval: 48.75 ms
[BLE HID peripheral]: - Connection Latency: 0
[BLE HID peripheral]: Boot Keyboard Characteristic Subscribed 1
[BLE HID peripheral]: Report Characteristic Subscribed 1
[BLE HID peripheral]: Report Characteristic Subscribed 1
[BLE HID peripheral]: Boot Keyboard Characteristic Subscribed 1
^CCTRL-C - SIGINT received, shutting down..
[BLE HID peripheral]: Offline

Any clue why i get the "Boot Keyboard Characteristic Subscribed" and "Report Characteristic Subscribed" report ?

[gvdhoven]

What i also see in the code is that you have a lot of times this piece of code;

case HIDS_SUBEVENT_BOOT_KEYBOARD_INPUT_REPORT_ENABLE:
  con_handle = hids_subevent_input_report_enable_get_con_handle(packet);

However, (although the actual result of the two functions are the same) you should be using this:

case HIDS_SUBEVENT_BOOT_KEYBOARD_INPUT_REPORT_ENABLE:
  con_handle = hids_subevent_boot_keyboard_input_report_enable_get_con_handle(packet);

[mringwal]

hi! There are two mechanisms that cause 'subscribed' mechanism. The first, and obvious, is the remote device writing to the Characteristic Client Configuration. Then, if you're bonded, the GATT Server is required to store the subscription. For this, BTstack adds entry to the TLV. With that, you get one 'subscribed' right after connect from BTstack's ATT Server, and then maybe another one from the remote device.

BTstack tries to be lean and leaves all state handling and tracking to the user applications. There, you can ignore a second 'subscribed'.

What irritates me a bit is that you only get the 'Report Characteristic Subscribed 1' twice.

[mringwal]

Thanks for the comment on the incorrect getters. Fixed in 31eaaa99.

[gvdhoven]

BTstack tries to be lean and leaves all state handling and tracking to the user applications. There, you can ignore a second 'subscribed'.

The samples currently 'overwrite' the con_handle in that case. Not sure if the current way of how the samples handle it can break e.g. the HID implementation. For now i indeed ignored the second report in my code.

[mringwal]

Hi. Did you get everything working? Do we need to do anything? Btw. we have implemented and tested all hid variants (classic+le, device+host) this year.