Default bleak timeout (10s) while getting GATT services - leads to Transport error: connection timeout

[RubenIxorigue]

Hi there,

I’ve been testing the new 0.17.0 build and noticed that we’re consistently hitting Transport error: connection timeout.

To better understand what was happening, I collected detailed logs, since the Windows embedded .exe version of 0.13.0 does not exhibit this behavior in our environment.

From what we can see, in 0.17.0 the BLE stack appears to be enforcing a default 10-second timeout during GATT service discovery, even when --timeout 120 is provided. The timeout value does not seem to be propagated to the GATT discovery phase after the device is already connected.

This behavior was not present in 0.13.0, as shown in the logs. In our case, GATT service discovery after a successful connection can take up to ~110 seconds in a clean environment, which 0.13.0 handled correctly.

Both versions tested are the embedded Windows .exe builds.

Please let me know if you’d like us to provide additional logs or test a specific build or configuration.

0.17.0

0.13.0

[RubenIxorigue]

We use 0.13.0 as our baseline, since it has proven to be the most stable release in production, having been used to upgrade thousands of devices in our environment.

The only limitations we’ve encountered with 0.13.0 are:

the lack of image erase support, and

occasional cases where bleak gets stuck in a loop after every X devices.

The upgrade + permanent confirmation feature introduced in 0.17.0 is excellent and extremely valuable for us, but unfortunately we are seeing BLE connection timeouts and instability during GATT discovery in this version, which we do not experience with 0.13.0.

[RubenIxorigue]

I think I fixed it by adding the timeout part to smpclient/transport/ble.py

if type(device) is BLEDevice:
self._client = BleakClient(
device,
services=(str(SMP_SERVICE_UUID),),
disconnected_callback=self._set_disconnected_event,
timeout=timeout_s, # <--- FIX HERE
)

[JPHutchins]

I think I fixed it by adding the timeout part to smpclient/transport/ble.py

if type(device) is BLEDevice:
self._client = BleakClient(
device,
services=(str(SMP_SERVICE_UUID),),
disconnected_callback=self._set_disconnected_event,
timeout=timeout_s, # <--- FIX HERE
)

I'm thinking about whether the timeout should be for the entire connection routine, or for each step. It could be misleading to specify a timeout of 120s that could run for 240s since it uses the timeout twice.

[RubenIxorigue]

From a user perspective, I think the most intuitive behavior is:

--timeout represents the maximum wall-clock time for the entire connection routine (connect → GATT discovery → ready).

Internally, individual steps can consume portions of that budget, but the total elapsed time must never exceed the specified timeout.

Right now, the problem we’re seeing is that:

The timeout is effectively being applied per step (or partially ignored in GATT discovery),

Which means a user can specify --timeout 120 and still hit an early failure (~10 s) or potentially exceed the expected wall-clock duration if the timeout is reused.

I agree it would be misleading if --timeout 120 could result in ~240 s total runtime.

A possible approach that avoids ambiguity could be:

Treat --timeout as a global deadline (monotonic timer),

Pass the remaining time budget to each phase (connect, service discovery, SMP handshake),

Fail as soon as the remaining budget reaches zero.

This keeps the CLI contract simple and predictable while still allowing slow environments (like long GATT discovery on Windows) to succeed when explicitly allowed.

[JPHutchins]

Agreed, this sounds good! I know you're wanting to ditch Windows ASAP, but do you have any theories about why GATT discovery would take so long? We've faced similar issues in the past, and these are cases where a customer SW is provided for Windows, so the peripheral must work with Windows.

Perhaps I could bring it up with the Bleak team.

Windows BLE caching is tricky, but we'll expose that to end users ASAP so that they can decide whether to refresh GATT or not based on their requirements.

[JPHutchins]

There's the scan, the connect, the GATT scan, and the start notify: https://github.com/intercreate/smpclient/blob/main/smpclient/transport/ble.py#L80-L137

[RubenIxorigue]

Definitely. Regarding the slowness, our theory is that it’s primarily caused by Windows defaulting to very conservative Connection Intervals combined with a small MTU.

When you have a large GATT table, the OS has to make many sequential requests. If the interval is long (e.g., 50ms+) and the packet size is small, the total time adds up linearly. We are seeing that forcing the peripheral to request a connection parameter update (lower interval, higher bandwidth) immediately upon connection helps significantly.

It would be great to hear the Bleak team's take on this, although I know they are limited by what the Windows Bluetooth stack exposes.

[RubenIxorigue]

We’ve identified the root cause and made a firmware update on our side that significantly improves the DFU behavior.

We now increase the BLE advertising parameters when the device is preparing for DFU (similar to a dedicated DFU mode). With this change, once the device is discovered, the connection is immediate and the GATT services are retrieved instantly. This strongly suggests that the previously low advertising / aggressive low-power configuration on the device was the main factor behind the slow and unreliable GATT discovery.

By adjusting the firmware parameters (higher advertising rate, enabling mcumgr params, and increasing the MTU to better utilize BLE throughput), the device is now typically discovered within ~2–3 seconds, and GATT discovery happens right away.

Next step on our side is to push the MTU to the maximum supported value and evaluate the throughput impact. Based on early observations, we expect transfer speeds to improve significantly (potentially close to a 10× increase), which would bring the total DFU time down to the 5–10 second range.

This aligns well with what we were seeing on Windows and confirms that firmware-side BLE parameters play a critical role in DFU robustness and performance.