Re: Unable to connect to Bluetooth LE devices with long advertising times

["Sergio Conde Gómez" <skgsergio@gmail.com>]

Hello Luiz,

El lun, 10 ene 2022 a las 23:07, Luiz Augusto von Dentz
(<luiz.dentz@gmail.com>) escribió:
>
> Hi Sergio,
>
> On Mon, Jan 10, 2022 at 10:31 AM Sergio Conde Gómez <skgsergio@gmail.com> 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