Hello,
I'm on kernel version 5.15.13 (shipped by Arch Linux) with bluez 5.63
and I'm unable to connect to Bluetooth LE devices with 5s, 7,5s, 10s
advertising times. As for hardware, I have a PCIe card with an Intel
AC9260 (WiFi + BT combo)[1].
I've been doing some research together with an open-source firmware
developer and some other users for one of the devices, and we found
references of Linux's HCI_LE_AUTOCONN_TIMEOUT
(include/net/bluetooth/hci.h) being too low[2].
Apparently, the Bluetooth Core Specification allows the advertising to
be from 20ms to 10,485s in multiples of 0.625ms (Vol. 6, Part B,
4.4.2.2.1, page 2749 of the Core Specification 5.3), and Linux's
HCI_LE_AUTOCONN_TIMEOUT is set to 4s.
I've recompiled the kernel package on my machine raising it to 20s (no
scientific reason for this number other than being
HCI_LE_CONN_TIMEOUT) and I could connect to them (with the device with
10s advertising time was not successful every time but at least I
could connect). I retested changing the value again to 12s (to cover
the 10,485s, plus some extra with no scientific reasons) and I got
more or less the same results as with the 20s (but was quick testing
this morning, not as in deep as with the 20s).
The connection procedure was just running "bluetoothctl", "scan on",
and when the device is first seen then "connect DEVICE_MAC".
Now, I'm no expert in Bluetooth, BLE, or Linux Kernel, so I might be
doing it wrong or misunderstanding something, but changing the value
made it work. If this timeout is what is making us unable to connect
to these devices, what's the reason for this low timeout outside the
spec? Would be possible to fix it by not changing the devices to a
shorter advertisement time (which impacts battery life)?
Regards,
Sergio Conde.
[1]: https://www.intel.com/content/www/us/en/products/sku/99445/intel-wirelessac-9260/specifications.html
[2]: Full discussion https://github.com/pvvx/ATC_MiThermometer/issues/172
Hi Sergio,
On Mon, Jan 10, 2022 at 10:31 AM Sergio Conde Gómez <[email protected]> wrote:
>
> Hello,
>
> I'm on kernel version 5.15.13 (shipped by Arch Linux) with bluez 5.63
> and I'm unable to connect to Bluetooth LE devices with 5s, 7,5s, 10s
> advertising times. As for hardware, I have a PCIe card with an Intel
> AC9260 (WiFi + BT combo)[1].
>
> I've been doing some research together with an open-source firmware
> developer and some other users for one of the devices, and we found
> references of Linux's HCI_LE_AUTOCONN_TIMEOUT
> (include/net/bluetooth/hci.h) being too low[2].
This used to be even shorted (2s) and has been bumped to 4s, so I do
wonder if we need to allow the full range, that said userspace can set
its own timeout nowadays:
https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/src/main.conf#n199
> Apparently, the Bluetooth Core Specification allows the advertising to
> be from 20ms to 10,485s in multiples of 0.625ms (Vol. 6, Part B,
> 4.4.2.2.1, page 2749 of the Core Specification 5.3), and Linux's
> HCI_LE_AUTOCONN_TIMEOUT is set to 4s.
>
> I've recompiled the kernel package on my machine raising it to 20s (no
> scientific reason for this number other than being
> HCI_LE_CONN_TIMEOUT) and I could connect to them (with the device with
> 10s advertising time was not successful every time but at least I
> could connect). I retested changing the value again to 12s (to cover
> the 10,485s, plus some extra with no scientific reasons) and I got
> more or less the same results as with the 20s (but was quick testing
> this morning, not as in deep as with the 20s).
>
> The connection procedure was just running "bluetoothctl", "scan on",
> and when the device is first seen then "connect DEVICE_MAC".
Have you tried doing a #scan off before #connect <bdaddr>? I wonder if
the device is busy discovering, that said bumping to the maximum
window as default sounds like a good idea. @Marcel Holtmann any
thoughts?
> Now, I'm no expert in Bluetooth, BLE, or Linux Kernel, so I might be
> doing it wrong or misunderstanding something, but changing the value
> made it work. If this timeout is what is making us unable to connect
> to these devices, what's the reason for this low timeout outside the
> spec? Would be possible to fix it by not changing the devices to a
> shorter advertisement time (which impacts battery life)?
>
> Regards,
> Sergio Conde.
>
> [1]: https://www.intel.com/content/www/us/en/products/sku/99445/intel-wirelessac-9260/specifications.html
> [2]: Full discussion https://github.com/pvvx/ATC_MiThermometer/issues/172
--
Luiz Augusto von Dentz
Hello Luiz,
El lun, 10 ene 2022 a las 23:07, Luiz Augusto von Dentz
(<[email protected]>) escribió:
>
> Hi Sergio,
>
> On Mon, Jan 10, 2022 at 10:31 AM Sergio Conde Gómez <[email protected]> wrote:
> >
> > Hello,
> >
> > I'm on kernel version 5.15.13 (shipped by Arch Linux) with bluez 5.63
> > and I'm unable to connect to Bluetooth LE devices with 5s, 7,5s, 10s
> > advertising times. As for hardware, I have a PCIe card with an Intel
> > AC9260 (WiFi + BT combo)[1].
> >
> > I've been doing some research together with an open-source firmware
> > developer and some other users for one of the devices, and we found
> > references of Linux's HCI_LE_AUTOCONN_TIMEOUT
> > (include/net/bluetooth/hci.h) being too low[2].
>
> This used to be even shorted (2s) and has been bumped to 4s, so I do
> wonder if we need to allow the full range, that said userspace can set
> its own timeout nowadays:
>
> https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/src/main.conf#n199
Completely missed it, thanks! What I've discovered after sending my
mail is that I could change it using btmgmt (btmgmt set-sysconfig -v
001b:2:e02e), but having this in the config file is far more
convenient as it persists.
> > Apparently, the Bluetooth Core Specification allows the advertising to
> > be from 20ms to 10,485s in multiples of 0.625ms (Vol. 6, Part B,
> > 4.4.2.2.1, page 2749 of the Core Specification 5.3), and Linux's
> > HCI_LE_AUTOCONN_TIMEOUT is set to 4s.
> >
> > I've recompiled the kernel package on my machine raising it to 20s (no
> > scientific reason for this number other than being
> > HCI_LE_CONN_TIMEOUT) and I could connect to them (with the device with
> > 10s advertising time was not successful every time but at least I
> > could connect). I retested changing the value again to 12s (to cover
> > the 10,485s, plus some extra with no scientific reasons) and I got
> > more or less the same results as with the 20s (but was quick testing
> > this morning, not as in deep as with the 20s).
> >
> > The connection procedure was just running "bluetoothctl", "scan on",
> > and when the device is first seen then "connect DEVICE_MAC".
>
> Have you tried doing a #scan off before #connect <bdaddr>? I wonder if
> the device is busy discovering, that said bumping to the maximum
> window as default sounds like a good idea. @Marcel Holtmann any
> thoughts?
Yes, but even stopping the scan without the timeout increased I can't
connect to devices with advertisement intervals of 7,5s or 10s.
What I'm not sure about is if when I had transient issues connecting
to the 10s device with the timeout increased I was stopping the scan
or not, I guess I can test now easily.
> > Now, I'm no expert in Bluetooth, BLE, or Linux Kernel, so I might be
> > doing it wrong or misunderstanding something, but changing the value
> > made it work. If this timeout is what is making us unable to connect
> > to these devices, what's the reason for this low timeout outside the
> > spec? Would be possible to fix it by not changing the devices to a
> > shorter advertisement time (which impacts battery life)?
> >
> > Regards,
> > Sergio Conde.
> >
> > [1]: https://www.intel.com/content/www/us/en/products/sku/99445/intel-wirelessac-9260/specifications.html
> > [2]: Full discussion https://github.com/pvvx/ATC_MiThermometer/issues/172
>
>
>
> --
> Luiz Augusto von Dentz
--
Sergio Conde