MIME-Version: 1.0
References: <CAGjK+HS2o8P4wPb869vaJoP6Fm-EMHmguhVKEyBX=nGoBchDKw@mail.gmail.com>
In-Reply-To: <CAGjK+HS2o8P4wPb869vaJoP6Fm-EMHmguhVKEyBX=nGoBchDKw@mail.gmail.com>
From:   Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Date:   Mon, 10 Jan 2022 14:07:00 -0800
Message-ID: <CABBYNZLdam79JAKNC-VN6joZZUvwhTceOpe7b9zS1zbGJeHJ_w@mail.gmail.com>
Subject: Re: Unable to connect to Bluetooth LE devices with long advertising times
To:     =?UTF-8?Q?Sergio_Conde_G=C3=B3mez?= <skgsergio@gmail.com>,
        Marcel Holtmann <marcel@holtmann.org>
Cc:     "linux-bluetooth@vger.kernel.org" <linux-bluetooth@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

Hi Sergio,

On Mon, Jan 10, 2022 at 10:31 AM Sergio Conde G=C3=B3mez <skgsergio@gmail.c=
om> 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-wir=
elessac-9260/specifications.html
> [2]: Full discussion https://github.com/pvvx/ATC_MiThermometer/issues/172


--=20
Luiz Augusto von Dentz