Linux bluetooth development
 help / color / mirror / Atom feed
From: Valentin Kindschi <valentin.kindschi@fiveco.ch>
To: <linux-bluetooth@vger.kernel.org>
Cc: <marcel@holtmann.org>, <johan.hedberg@gmail.com>,
	<luiz.dentz@gmail.com>, <linux-kernel@vger.kernel.org>,
	Valentin Kindschi <valentin.kindschi@fiveco.ch>,
	<stable@vger.kernel.org>
Subject: [PATCH v3 2/2] Bluetooth: hci_event: keep HCI_LE_ADV set if the host cancelled
Date: Mon, 17 Aug 2026 17:02:40 +0200	[thread overview]
Message-ID: <20260817150240.520181-3-valentin.kindschi@fiveco.ch> (raw)
In-Reply-To: <20260817150240.520181-1-valentin.kindschi@fiveco.ch>

le_conn_complete_evt() clears HCI_LE_ADV before looking at the event
status, on the premise stated in its comment that all controllers stop
advertising when a connection is created.

That premise fails for Unknown Connection Identifier (0x02), which is
what an HCI_LE_Connection_Complete carries after the host issued
LE Create Connection Cancel: no connection was created and the
controller never stopped advertising. Clearing the flag there makes the
host believe advertising is off while the controller has it on.

Other non-zero statuses must keep clearing it. Advertising Timeout
(0x3c) in particular means the controller gave up advertising on its
own, so the flag has to go; leaving it set would make the
"already advertising" shortcut in hci_schedule_adv_instance_sync() skip
the HCI commands and silently stop advertising altogether.

With legacy advertising the disagreement is self-sustaining. On the next
software rotation tick hci_enable_advertising_sync() runs:

  - hci_disable_advertising_sync() returns early without sending
    anything, because HCI_LE_ADV is clear;
  - LE Set Advertising Parameters is then sent while the controller is
    still advertising, and is correctly rejected with Command Disallowed
    (0x0c);
  - the function returns before LE Set Advertising Enable, so nothing
    re-sets HCI_LE_ADV.

hci_schedule_adv_instance_sync() re-arms adv_instance_expire every
HCI_DEFAULT_ADV_DURATION (2 s) and its "already advertising" shortcut
tests HCI_LE_ADV, which can no longer become true, so the command is
retried every 2 s indefinitely:

  Bluetooth: hci0: Opcode 0x2006 failed: -16

Captured on a BCM43455 (no LE Extended Advertising) after a central
connection attempt timed out and was cancelled:

  LE Set Advertising Parameters (0x2006)   Success
  LE Set Advertising Enable     (0x200a)   Success        HCI_LE_ADV set
  LE Create Connection Cancel   (0x200e)   Success
  LE Connection Complete                   Unknown Conn Id  <- flag cleared
  LE Set Advertising Parameters (0x2006)   Command Disallowed  [+2.033 s]
  LE Set Advertising Parameters (0x2006)   Command Disallowed  [+2.016 s]
  ...

Keep the flag only for the host-cancelled case.

Fixes: fbd96c151cdc ("Bluetooth: Fix clearing HCI_LE_ADV for LE connections")
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-opus-5 btmon
Signed-off-by: Valentin Kindschi <valentin.kindschi@fiveco.ch>
---
Changes in v2:
- Rebased onto bluetooth-next; no functional change.
  v1's hci_event.c context lacked the hci_store_wake_reason() call
  present in mainline, so the hunk did not apply.

 net/bluetooth/hci_event.c | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -5720,10 +5720,12 @@ static void le_conn_complete_evt(struct hci_dev *hdev, u8 status,
 	hci_dev_lock(hdev);
 	hci_store_wake_reason(hdev, bdaddr, bdaddr_type);
 
-	/* All controllers implicitly stop advertising in the event of a
-	 * connection, so ensure that the state bit is cleared.
+	/* Advertising stops when a connection is created, and when the
+	 * controller gives up advertising on its own. It keeps advertising
+	 * when the host cancelled an outgoing connection.
 	 */
-	hci_dev_clear_flag(hdev, HCI_LE_ADV);
+	if (status != HCI_ERROR_UNKNOWN_CONN_ID)
+		hci_dev_clear_flag(hdev, HCI_LE_ADV);
 
 	/* Check for existing connection:
 	 *
--
2.34.1

  parent reply	other threads:[~2026-08-17 15:03 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-17 15:02 [PATCH v3 0/2] Bluetooth: fix endless adv params retry after a cancelled connection Valentin Kindschi
2026-08-17 15:02 ` [PATCH v3 1/2] Bluetooth: hci_conn: re-enable advertising only for peripheral role Valentin Kindschi
2026-08-17 15:49   ` Bluetooth: fix endless adv params retry after a cancelled connection bluez.test.bot
2026-08-17 15:02 ` Valentin Kindschi [this message]
2026-08-17 16:11   ` [PATCH v3 2/2] Bluetooth: hci_event: keep HCI_LE_ADV set if the host cancelled Luiz Augusto von Dentz
2026-08-17 16:31     ` Valentin Kindschi
2026-08-17 16:42       ` Luiz Augusto von Dentz

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=20260817150240.520181-3-valentin.kindschi@fiveco.ch \
    --to=valentin.kindschi@fiveco.ch \
    --cc=johan.hedberg@gmail.com \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luiz.dentz@gmail.com \
    --cc=marcel@holtmann.org \
    --cc=stable@vger.kernel.org \
    /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