Bug 217773 - Bluetooth LE scan doesn't show device name
Summary: Bluetooth LE scan doesn't show device name
Status: RESOLVED PATCH_ALREADY_AVAILABLE
Alias: None
Product: Drivers
Classification: Unclassified
Component: Bluetooth (show other bugs)
Hardware: All Linux
: P3 normal
Assignee: linux-bluetooth@vger.kernel.org
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-08-08 10:09 UTC by TatriX
Modified: 2023-09-08 10:21 UTC (History)
1 user (show)

See Also:
Kernel Version:
Subsystem:
Regression: No
Bisected commit-id:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Description TatriX 2023-08-08 10:09:16 UTC 
Hi!
At some point after kernel 5.9 I started having issues with LE device scanning.
Here's how it used to work:

    $ bluetoothctl
    # power on
    # scan on
     ...
    [NEW] Device 68:71:DD:73:97:D5 Playfinity-2

It successfully finds my device and it's name.
On a newer kernel instead I'm getting no name:

    [NEW] Device 4D:18:19:A8:63:B5 4D-18-19-A8-63-B5

Here's corresponding btmon logs. First from kernel 5.9.12 that can see device's name:

```5.9.12
> HCI Event: LE Meta Event (0x3e) plen 33                  #118 [hci0] 5.607028
      LE Extended Advertising Report (0x0d)
        Num reports: 1
        Entry 0
          Event type: 0x0013
            Props: 0x0013
              Connectable
              Scannable
              Use legacy advertising PDUs
            Data status:  [0;32mComplete [0m
          Legacy PDU Type: ADV_IND (0x0013)
          Address type: Random (0x01)
          Address: 68:71:DD:73:97:D5 (Resolvable)
          Primary PHY: LE 1M
          Secondary PHY: No packets
          SID: no ADI field (0xff)
          TX power: 127 dBm
          RSSI: -54 dBm (0xca)
          Periodic advertising interval: 0.00 msec (0x0000)
          Direct address type: Public (0x00)
          Direct address: 00:00:00:00:00:00 (OUI 00-00-00)
          Data length: 0x07
        02 01 06 03 02 f0 ff                             .......
        Flags: 0x06
          LE General Discoverable Mode
          BR/EDR Not Supported
        16-bit Service UUIDs (partial): 1 entry
          Unknown (0xfff0)
> HCI Event: LE Meta Event (0x3e) plen 49                  #119 [hci0] 5.608029
      LE Extended Advertising Report (0x0d)
        Num reports: 1
        Entry 0
          Event type: 0x001b
            Props: 0x001b
              Connectable
              Scannable
              Scan response
              Use legacy advertising PDUs
            Data status:  [0;32mComplete [0m
          Legacy PDU Type: SCAN_RSP to an ADV_SCAN_IND (0x001b)
          Address type: Random (0x01)
          Address: 68:71:DD:73:97:D5 (Resolvable)
          Primary PHY: LE 1M
          Secondary PHY: No packets
          SID: no ADI field (0xff)
          TX power: 127 dBm
          RSSI: -54 dBm (0xca)
          Periodic advertising interval: 0.00 msec (0x0000)
          Direct address type: Public (0x00)
          Direct address: 00:00:00:00:00:00 (OUI 00-00-00)
          Data length: 0x17
        0d 09 50 6c 61 79 66 69 6e 69 74 79 2d 32 02 0a  ..Playfinity-2..
        00 05 12 50 00 68 00                             ...P.h.
        Name (complete): Playfinity-2
        TX power: 0 dBm
        Peripheral Conn. Interval: 0x0050 - 0x0068
```

And from 6.4.8:

```6.4.8
> HCI Event: LE Meta Event (0x3e) plen 33                  #130 [hci0] 9.180207
      LE Extended Advertising Report (0x0d)
        Num reports: 1
        Entry 0
          Event type: 0x0013
            Props: 0x0013
              Connectable
              Scannable
              Use legacy advertising PDUs
            Data status: �[0;32mComplete�[0m
          Legacy PDU Type: ADV_IND (0x0013)
          Address type: Random (0x01)
          Address: 4D:18:19:A8:63:B5 (Resolvable)
          Primary PHY: LE 1M
          Secondary PHY: No packets
          SID: no ADI field (0xff)
          TX power: 127 dBm
          RSSI: -53 dBm (0xcb)
          Periodic advertising interval: 0.00 msec (0x0000)
          Direct address type: Public (0x00)
          Direct address: 00:00:00:00:00:00 (OUI 00-00-00)
          Data length: 0x07
        02 01 06 03 02 f0 ff                             .......
        Flags: 0x06
          LE General Discoverable Mode
          BR/EDR Not Supported
        16-bit Service UUIDs (partial): 1 entry
          Unknown (0xfff0)
```

I've tried compiling 5.9.12 to see if I can bissect, but it fails to compile with gcc12..

Is it expected that newer kernels can't get device name? Perhaps some additional action is needed fetch it?
 
Thanks!
Comment 1 Bagas Sanjaya 2023-08-08 13:30:39 UTC 
(In reply to TatriX from comment #0)
> Hi!
> At some point after kernel 5.9 I started having issues with LE device
> scanning.
> Here's how it used to work:
> 
>     $ bluetoothctl
>     # power on
>     # scan on
>      ...
>     [NEW] Device 68:71:DD:73:97:D5 Playfinity-2
> 
> It successfully finds my device and it's name.
> On a newer kernel instead I'm getting no name:
> 
>     [NEW] Device 4D:18:19:A8:63:B5 4D-18-19-A8-63-B5
> 
> Here's corresponding btmon logs. First from kernel 5.9.12 that can see
> device's name:
> 
> ```5.9.12
> > HCI Event: LE Meta Event (0x3e) plen 33                  #118 [hci0]
> 5.607028
>       LE Extended Advertising Report (0x0d)
>         Num reports: 1
>         Entry 0
>           Event type: 0x0013
>             Props: 0x0013
>               Connectable
>               Scannable
>               Use legacy advertising PDUs
>             Data status:  [0;32mComplete [0m
>           Legacy PDU Type: ADV_IND (0x0013)
>           Address type: Random (0x01)
>           Address: 68:71:DD:73:97:D5 (Resolvable)
>           Primary PHY: LE 1M
>           Secondary PHY: No packets
>           SID: no ADI field (0xff)
>           TX power: 127 dBm
>           RSSI: -54 dBm (0xca)
>           Periodic advertising interval: 0.00 msec (0x0000)
>           Direct address type: Public (0x00)
>           Direct address: 00:00:00:00:00:00 (OUI 00-00-00)
>           Data length: 0x07
>         02 01 06 03 02 f0 ff                             .......
>         Flags: 0x06
>           LE General Discoverable Mode
>           BR/EDR Not Supported
>         16-bit Service UUIDs (partial): 1 entry
>           Unknown (0xfff0)
> > HCI Event: LE Meta Event (0x3e) plen 49                  #119 [hci0]
> 5.608029
>       LE Extended Advertising Report (0x0d)
>         Num reports: 1
>         Entry 0
>           Event type: 0x001b
>             Props: 0x001b
>               Connectable
>               Scannable
>               Scan response
>               Use legacy advertising PDUs
>             Data status:  [0;32mComplete [0m
>           Legacy PDU Type: SCAN_RSP to an ADV_SCAN_IND (0x001b)
>           Address type: Random (0x01)
>           Address: 68:71:DD:73:97:D5 (Resolvable)
>           Primary PHY: LE 1M
>           Secondary PHY: No packets
>           SID: no ADI field (0xff)
>           TX power: 127 dBm
>           RSSI: -54 dBm (0xca)
>           Periodic advertising interval: 0.00 msec (0x0000)
>           Direct address type: Public (0x00)
>           Direct address: 00:00:00:00:00:00 (OUI 00-00-00)
>           Data length: 0x17
>         0d 09 50 6c 61 79 66 69 6e 69 74 79 2d 32 02 0a  ..Playfinity-2..
>         00 05 12 50 00 68 00                             ...P.h.
>         Name (complete): Playfinity-2
>         TX power: 0 dBm
>         Peripheral Conn. Interval: 0x0050 - 0x0068
> ```
> 
> And from 6.4.8:
> 
> ```6.4.8
> > HCI Event: LE Meta Event (0x3e) plen 33                  #130 [hci0]
> 9.180207
>       LE Extended Advertising Report (0x0d)
>         Num reports: 1
>         Entry 0
>           Event type: 0x0013
>             Props: 0x0013
>               Connectable
>               Scannable
>               Use legacy advertising PDUs
>             Data status: �[0;32mComplete�[0m
>           Legacy PDU Type: ADV_IND (0x0013)
>           Address type: Random (0x01)
>           Address: 4D:18:19:A8:63:B5 (Resolvable)
>           Primary PHY: LE 1M
>           Secondary PHY: No packets
>           SID: no ADI field (0xff)
>           TX power: 127 dBm
>           RSSI: -53 dBm (0xcb)
>           Periodic advertising interval: 0.00 msec (0x0000)
>           Direct address type: Public (0x00)
>           Direct address: 00:00:00:00:00:00 (OUI 00-00-00)
>           Data length: 0x07
>         02 01 06 03 02 f0 ff                             .......
>         Flags: 0x06
>           LE General Discoverable Mode
>           BR/EDR Not Supported
>         16-bit Service UUIDs (partial): 1 entry
>           Unknown (0xfff0)
> ```
> 
> I've tried compiling 5.9.12 to see if I can bissect, but it fails to compile
> with gcc12..
> 
> Is it expected that newer kernels can't get device name? Perhaps some
> additional action is needed fetch it?
>  

Try using gcc 10 when compiling v5.9.12 kernel, then try reproducing this
regression on v5.10, v5.15, and v6.1. Remember to test the mainline releases,
not stable tree (like v5.10.y). After that, please consult
Documentation/admin-guide/bug-bisect.rst for how to perform bisection with git.
Comment 2 TatriX 2023-09-08 10:21:01 UTC 
It looks like this change: https://github.com/bluez/bluetooth-next/commit/52bf4fd43f759ac4698f041fff2cb27691698265 has fixed it.
Note You need to log in before you can comment on or make changes to this bug.