[PATCH v3] Bluetooth: Increase LE connection timeout for industrial sensors

[PATCH v3] Bluetooth: Increase LE connection timeout for industrial sensors

[Dajid MOREL]

From: Dajid Morel <dajid.morel@volvo.com>

In an industrial IoT context at Volvo Group, we use TE Connectivity
BLE pressure sensors. These sensors exhibit high latency during
the initial LE connection handshake in noisy RF environments. The
connection systematically fails on Ubuntu Core 22 (BlueZ) because the
connection attempt is aborted too early.

In the v2 thread, it was suggested that userspace (via setsockopt
SO_SNDTIMEO) dictates the connection timeout (defaulting to 40s),
suspecting that userspace was cutting the connection at 2 seconds,
not the kernel.

To verify this, an empirical test was conducted using the following
Python/Bleak script to force the application timeout to 45.0 seconds:

  import asyncio
  from bleak import BleakClient, BleakScanner
  import time

  ADDRESS = "E8:C0:B1:D4:A3:3C"

  async def test_connection():
      device = await BleakScanner.find_device_by_address(ADDRESS, timeout=15.0)
      start_time = time.time()
      try:
          # Forcing 45s timeout in userspace
          async with BleakClient(device, timeout=45.0) as client:
              print(f"Connected in {time.time() - start_time:.2f}s")
      except Exception as e:
          print(f"Failed after {time.time() - start_time:.2f}s: {e}")

  asyncio.run(test_connection())

1. Result on UNMODIFIED Kernel: The userspace script patiently waited
   for the full 45 seconds before raising a TimeoutError. If the kernel
   had actually kept the radio connection attempt alive for those
   45 seconds, the connection would have succeeded around the
   12.5-second mark (as proven by the patched kernel test below).
   The fact that it did not proves that the underlying HCI connection
   attempt was aborted early by the kernel. Userspace was blind to this
   abort and kept waiting in a vacuum.

2. Result on MODIFIED Kernel (with this patch): Using the exact same
   userspace script (45.0s timeout), the connection successfully
   established at the 12.51-second mark.

Conclusion:
This proves that the underlying HCI LE Connection creation is bound by
a strict 2-second timeout derived from `conn_timeout` in `hci_conn.c`,
and that userspace socket options do not override this hardcoded HCI
abort in our stack. The sensor physically takes 12.5 seconds to
handshake, making the 2-second kernel limit a hard blocker.

This patch increases the hardcoded LE connection timeout to 20 seconds
to provide a comfortable margin for handshake retries. 

Note: If the upstream preference is to not hardcode 20 seconds globally,
I would be happy to submit a v4 that exposes this as a configurable
module parameter (e.g., `le_conn_timeout`).

Signed-off-by: Dajid Morel <dajid.morel@volvo.com>
---
 net/bluetooth/hci_conn.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
index d177b7f49..8aeed0962 100644
--- a/net/bluetooth/hci_conn.c
+++ b/net/bluetooth/hci_conn.c
@@ -1131,7 +1131,7 @@ struct hci_conn *hci_connect_le(struct hci_dev *hdev, bdaddr_t *dst,
 
 	conn->dst_type = dst_type;
 	conn->sec_level = BT_SECURITY_LOW;
-	conn->conn_timeout = conn_timeout;
+	conn->conn_timeout = msecs_to_jiffies(20000);
 
 	hci_req_init(&req, hdev);
 
@@ -1301,7 +1301,7 @@ struct hci_conn *hci_connect_le_scan(struct hci_dev *hdev, bdaddr_t *dst,
 	conn->dst_type = dst_type;
 	conn->sec_level = BT_SECURITY_LOW;
 	conn->pending_sec_level = sec_level;
-	conn->conn_timeout = conn_timeout;
+	conn->conn_timeout = msecs_to_jiffies(20000);
 	conn->conn_reason = conn_reason;
 
 	hci_update_background_scan(hdev);
-- 
2.34.1

RE: [v3] Bluetooth: Increase LE connection timeout for industrial sensors

[bluez.test.bot]

[-- Attachment #1: Type: text/plain, Size: 551 bytes --]

This is an automated email and please do not reply to this email.

Dear Submitter,

Thank you for submitting the patches to the linux bluetooth mailing list.
While preparing the CI tests, the patches you submitted couldn't be applied to the current HEAD of the repository.

----- Output -----

error: patch failed: net/bluetooth/hci_conn.c:1131
error: net/bluetooth/hci_conn.c: patch does not apply
hint: Use 'git am --show-current-patch' to see the failed patch

Please resolve the issue and submit the patches again.


---
Regards,
Linux Bluetooth