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