Bug 217773
Summary: | Bluetooth LE scan doesn't show device name | ||
---|---|---|---|
Product: | Drivers | Reporter: | TatriX (tatrics) |
Component: | Bluetooth | Assignee: | linux-bluetooth (linux-bluetooth) |
Status: | RESOLVED PATCH_ALREADY_AVAILABLE | ||
Severity: | normal | CC: | bagasdotme |
Priority: | P3 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | Subsystem: | ||
Regression: | No | Bisected commit-id: |
Description
TatriX
2023-08-08 10:09:16 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. It looks like this change: https://github.com/bluez/bluetooth-next/commit/52bf4fd43f759ac4698f041fff2cb27691698265 has fixed it. |