From: Chris Down <chris@chrisdown.name>
To: linux-bluetooth@vger.kernel.org
Cc: Luiz Augusto von Dentz <luiz.dentz@gmail.com>,
linux-kernel@vger.kernel.org, kernel-team@fb.com,
Jaganath Kanakkassery <jaganath.k.os@gmail.com>
Subject: [PATCH v2] Bluetooth: hci_event: Mask data status from LE ext adv reports
Date: Mon, 21 Jul 2025 16:30:23 +0100 [thread overview]
Message-ID: <aH5dD1V0K7qZIOSJ@chrisdown.name> (raw)
The Event_Type field in an LE Extended Advertising Report uses bits 5
and 6 for data status (e.g. truncation or fragmentation), not the PDU
type itself.
The ext_evt_type_to_legacy() function fails to mask these status bits
before evaluation. This causes valid advertisements with status bits set
(e.g. a truncated non-connectable advertisement, which ends up showing
as PDU type 0x40) to be misclassified as unknown and subsequently
dropped. This is okay for most checks which use bitwise AND on the
relevant event type bits, but it doesn't work for non-connectable types,
which are checked with '== LE_EXT_ADV_NON_CONN_IND' (that is, zero).
In terms of behaviour, first the device sends a truncated report:
> HCI Event: LE Meta Event (0x3e) plen 26
LE Extended Advertising Report (0x0d)
Entry 0
Event type: 0x0040
Data status: Incomplete, data truncated, no more to come
Address type: Random (0x01)
Address: 1D:12:46:FA:F8:6E (Non-Resolvable)
SID: 0x03
RSSI: -98 dBm (0x9e)
Data length: 0x00
Then, a few seconds later, it sends the subsequent complete report:
> HCI Event: LE Meta Event (0x3e) plen 122
LE Extended Advertising Report (0x0d)
Entry 0
Event type: 0x0000
Data status: Complete
Address type: Random (0x01)
Address: 1D:12:46:FA:F8:6E (Non-Resolvable)
SID: 0x03
RSSI: -97 dBm (0x9f)
Data length: 0x60
Service Data: Google (0xfef3)
Data[92]: ...
These devices often send multiple truncated reports per second.
This patch introduces a PDU type mask to ensure only the relevant bits
are evaluated, allowing for the correct translation of all valid
extended advertising packets.
Signed-off-by: Chris Down <chris@chrisdown.name>
Cc: linux-bluetooth@vger.kernel.org
Cc: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
---
include/net/bluetooth/hci.h | 1 +
net/bluetooth/hci_event.c | 7 +++++--
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
index 797992019f9e..c210d699f4da 100644
--- a/include/net/bluetooth/hci.h
+++ b/include/net/bluetooth/hci.h
@@ -2630,6 +2630,7 @@ struct hci_ev_le_conn_complete {
#define LE_EXT_ADV_DIRECT_IND 0x0004
#define LE_EXT_ADV_SCAN_RSP 0x0008
#define LE_EXT_ADV_LEGACY_PDU 0x0010
+#define LE_EXT_ADV_DATA_STATUS_MASK 0x0060
#define LE_EXT_ADV_EVT_TYPE_MASK 0x007f
#define ADDR_LE_DEV_PUBLIC 0x00
diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index 6d6061111ac5..065ad3a39a1a 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -6264,6 +6264,10 @@ static void hci_le_adv_report_evt(struct hci_dev *hdev, void *data,
static u8 ext_evt_type_to_legacy(struct hci_dev *hdev, u16 evt_type)
{
+ u16 pdu_type = evt_type & ~LE_EXT_ADV_DATA_STATUS_MASK;
+ if (!pdu_type)
+ return LE_ADV_NONCONN_IND;
+
if (evt_type & LE_EXT_ADV_LEGACY_PDU) {
switch (evt_type) {
case LE_LEGACY_ADV_IND:
@@ -6295,8 +6299,7 @@ static u8 ext_evt_type_to_legacy(struct hci_dev *hdev, u16 evt_type)
if (evt_type & LE_EXT_ADV_SCAN_IND)
return LE_ADV_SCAN_IND;
- if (evt_type == LE_EXT_ADV_NON_CONN_IND ||
- evt_type & LE_EXT_ADV_DIRECT_IND)
+ if (evt_type & LE_EXT_ADV_DIRECT_IND)
return LE_ADV_NONCONN_IND;
invalid:
--
2.50.0
next reply other threads:[~2025-07-21 15:30 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-21 15:30 Chris Down [this message]
2025-07-21 16:05 ` [v2] Bluetooth: hci_event: Mask data status from LE ext adv reports bluez.test.bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aH5dD1V0K7qZIOSJ@chrisdown.name \
--to=chris@chrisdown.name \
--cc=jaganath.k.os@gmail.com \
--cc=kernel-team@fb.com \
--cc=linux-bluetooth@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luiz.dentz@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox