Intermittent 'Not connectable' devices found - Linux kernel BLE bug?

Question

This is going to be a complicated issue but please bare with me. I want to ask here first before I address the linux-bluetooth mailing list.

I'm working on a Raspberry Pi device that performs periodic BLE discovery and tries to connect to multiple devices. Most of the times this goes fine but especially in BLE heavy environments every now and then it fails because it says that the device is not found. I have been debugging this issue for a few weeks now and it comes down to this:

• Connect to DBus to start the discovery
• Devices are found, interfacesAdded callbacks are made, everything looks fine
• Stop discovery
• Directly some devices are removed by the interfacesRemoved callback
• My code does not get the device it searches for -> unhappy user

What happens under the hood is that DBus removes all devices from it's cache that have been indicated by Bluez as being Not connectable. I.e. there is no use in keeping them around, you can't connect to them anyway. But... this is not true for the device I'm looking for. It is marked as Not connectable incorrectly.

So to chase down the problem I create a btmon dump which shows indeed that the device is reported to be Not connectable after having received a SCAN_RSP:

> HCI Event: LE Meta Event (0x3e) plen 38                  #73 [hci0] 34.359921
      LE Advertising Report (0x02)
        Num reports: 1
        Event type: Scan response - SCAN_RSP (0x04)
        Address type: Public (0x00)
        Address: F4:B8:5E:64:02:55 (Texas Instruments)
        Data length: 26
        Name (complete): BeeWi SmartLite
        Peripheral Conn. Interval: 0x0028 - 0x0050
        TX power: 0 dBm
        RSSI: -42 dBm (0xd6)
@ MGMT Event: Device Found (0x0012) plen 40           {0x0001} [hci0] 34.360057
        LE Address: F4:B8:5E:64:02:55 (Texas Instruments)
        RSSI: -42 dBm (0xd6)
        Flags: 0x00000004
          Not Connectable
        Data length: 26
        Name (complete): BeeWi SmartLite
        Peripheral Conn. Interval: 0x0028 - 0x0050
        TX power: 0 dBm

But all ADV_IND PDU's before that clearly indicate that the device is connectable, it is only after this SCAN_RSP that it is reported as Not connectable:

> HCI Event: LE Meta Event (0x3e) plen 27                  #46 [hci0] 34.152817
      LE Advertising Report (0x02)
        Num reports: 1
        Event type: Connectable undirected - ADV_IND (0x00)
        Address type: Public (0x00)
        Address: F4:B8:5E:64:02:55 (Texas Instruments)
        Data length: 15
        Flags: 0x06
          LE General Discoverable Mode
          BR/EDR Not Supported
        Company: Texas Instruments Inc. (13)
          Data: 06030108b0e408f7
        RSSI: -43 dBm (0xd5)
@ MGMT Event: Device Found (0x0012) plen 31           {0x0001} [hci0] 34.152905
        LE Address: 44:6E:FF:00:0D:65 (Resolvable)
        RSSI: -74 dBm (0xb6)
        Flags: 0x00000000
        Data length: 17
        Flags: 0x1a
          LE General Discoverable Mode
          Simultaneous LE and BR/EDR (Controller)
          Simultaneous LE and BR/EDR (Host)
        TX power: 9 dBm
        Company: Apple, Inc. (76)
          Type: Unknown (16)
          Data: 01188898dc
> HCI Event: LE Meta Event (0x3e) plen 41                  #47 [hci0] 34.156958
      LE Advertising Report (0x02)
        Num reports: 1
        Event type: Connectable undirected - ADV_IND (0x00)
        Address type: Random (0x01)
        Address: FA:BD:8D:12:26:BF (Static)
        Data length: 29
        Name (short): P mesh
        Flags: 0x04
          BR/EDR Not Supported
        128-bit Service UUIDs (partial): 1 entry
          Vendor specific
        RSSI: -47 dBm (0xd1)
@ MGMT Event: Device Found (0x0012) plen 29           {0x0001} [hci0] 34.157030
        LE Address: F4:B8:5E:64:02:55 (Texas Instruments)
        RSSI: -43 dBm (0xd5)
        Flags: 0x00000000
        Data length: 15
        Flags: 0x06
          LE General Discoverable Mode
          BR/EDR Not Supported
        Company: Texas Instruments Inc. (13)
          Data: 06030108b0e408f7

So I am heavily doubting whether the Linux kernel code has a bug in handling the SCAN_RSP. Please look at this part of the kernel: https://github.com/torvalds/linux/blob/48b1320a674e1ff5de2fad8606bee38f724594dc/net/bluetooth/hci_event.c#L6326

It sets the NOT CONNECTABLE flag by default for a SCAN_RSP and will overwrite it with any flags it has received with a previous ADV_IND. But it does not seem to take into account that in BLE heavy environments the previous ADV_IND might be of a totally different device. So every now and then it will enter the first path where it will just report the device with a NOT_CONNECTABLE flag. Or am I missing something here?

Answer 1

So I posted the question on the linux-bluetooth mailing list. As suspected it was an issue in the kernel. A patch has been made.

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