CODEWITHSUNDEEP
linuxbluetoothbluez
vagrant4ever
vagrant4ever

Reputation: 35

Bluez 5 Unknown Connection Identifier

I have a Raspberry Pi 3 running the latest Raspbian, and I have upgraded bluez from 5.23. to 5.43. I am attempting to connect to BLE devices that advertise at 2 second interval. I wrote some code based on gatttool and attempted to connect to these devices. I run into the LE connect request being cancelled after 2 seconds. Thus I get a LE Connection Complete messages with a status of 0x02 (Unknown Connection Identifier)

From my research I ran across this from about 15 months ago in the archives,

https://www.spinics.net/lists/linux-bluetooth/msg65434.html

However after following the threads, I did not see if a resolution was found.

I have ran tests with my code, the gatttool utility and well as using bluetoothctl. I see the same type of activity in btmon that is listed below:


 HCI Command: LE Set Scan Parameters (0x08|0x000b) plen 7                              [hci0] 21:45:51.917070
        Type: Passive (0x00)
        Interval: 60.000 msec (0x0060)
        Window: 30.000 msec (0x0030)
        Own address type: Public (0x00)
        Filter policy: Ignore not in white list (0x01)
> HCI Event: Command Complete (0x0e) plen 4                                             [hci0] 21:45:51.917819
      LE Set Scan Parameters (0x08|0x000b) ncmd 1
        Status: Success (0x00)
 HCI Event: Command Complete (0x0e) plen 4                                             [hci0] 21:45:51.918357
      LE Set Scan Enable (0x08|0x000c) ncmd 1
        Status: Success (0x00)
> HCI Event: LE Meta Event (0x3e) plen 27                                               [hci0] 21:45:52.597503
      LE Advertising Report (0x02)
        Num reports: 1
        Event type: Connectable undirected - ADV_IND (0x00)
        Address type: Random (0x01)
        Address: D3:67:2D:D1:46:46 (Static)
        Data length: 15
        Flags: 0x06
          LE General Discoverable Mode
          BR/EDR Not Supported
        Company: FedEx Services (321)
          Data: 070a111080d28004
        RSSI: -63 dBm (0xc1)
 HCI Event: Command Complete (0x0e) plen 4                                             [hci0] 21:45:52.599626
      LE Set Scan Enable (0x08|0x000c) ncmd 1
        Status: Success (0x00)
 HCI Event: Command Status (0x0f) plen 4                                               [hci0] 21:45:52.600508
      LE Create Connection (0x08|0x000d) ncmd 1
        Status: Success (0x00)
 HCI Event: Command Complete (0x0e) plen 4                                             [hci0] 21:45:54.684146
      LE Create Connection Cancel (0x08|0x000e) ncmd 1
        Status: Success (0x00)
> HCI Event: LE Meta Event (0x3e) plen 19                                               [hci0] 21:45:54.684361
      LE Connection Complete (0x01)
        Status: Unknown Connection Identifier (0x02)
        Handle: 64
        Role: Master (0x00)
        Peer address type: Random (0x01)
        Peer address: D3:67:2D:D1:46:46 (Static)
        Connection interval: 67.50 msec (0x0036)
        Connection latency: 0.00 msec (0x0000)
        Supervision timeout: 420 msec (0x002a)
        Master clock accuracy: 0x00
@ Connect Failed: D3:67:2D:D1:46:46 (2) status 0x02

It looks like there is a 2 second timeout somewhere in the code, perhaps kernel side.

One thing to note is if I use hcitool to connect, I am able to connect most all of the time. I know this is not the L2CAP layer, but I can see that I am able to connect.

Also, if I change the advertising interval of the BLE devices to 1 second. I can connect just fine. (Reason for 2 sec advertising interval is power savings)

Has anyone recently ran into this issue, and if so has there been any resolution?

Thanks

Upvotes: 2

Views: 3253

Answers (2)

abyrvalg
abyrvalg

Reputation: 567

As Troy E. Lanes noted, this is due to a short HCI_LE_AUTOCONN_TIMEOUT defined in the kernel. If the timeout expired after LE Create Connection command is sent, the host sends command LE Create Connection Cancel.

But you can change timeout value without recompiling the kernel. I made a tool to change LE autoconnect timeout https://gist.github.com/mironovdm/cb7f47e8d898e9a3977fc888d990e8a9

Upvotes: 0

Troy E. Lanes
Troy E. Lanes

Reputation: 132

Having the same issue. Reducing the advertisement interval, as you've noted, from 10s to 0.5s does fix the issue. I, also, need a longer interval to conserve battery. I know that using an older build of Raspbian ( 2016-03-18-raspbian-jessie kernel 4.1.19-v7+ #858 SMP, bluez 5.23 ) works fine, however, I have yet to get a newer build to work.

UPDATE After discovering this post: https://www.spinics.net/lists/linux-bluetooth/msg67800.html I changed the following values in include/net/bluetooth/hci.h: 

#define HCI_LE_CONN_TIMEOUT msecs_to_jiffies(22000) /* 22 seconds WAS 2 seconds */
#define HCI_LE_AUTOCONN_TIMEOUT msecs_to_jiffies(22000) /* 22 seconds WAS 2 seconds */

recompiled, and all is working now with a 10.24 second broadcast interval from my device on the latest version of Raspbian kernel 4.4.50 with bluez 5.45. Hope this helps.

Upvotes: 4

Related Questions