Received-SPF: pass (google.com: best guess record for domain of linux-bluetooth-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Mon, 19 Aug 2019 18:08:13 +0200
From:   Andreas Kemnade <andreas@kemnade.info>
To:     Carey Sonsino <csonsino@gmail.com>
Cc:     Marcel Holtmann <marcel@holtmann.org>,
        Johan Hedberg <johan.hedberg@gmail.com>,
        linux-bluetooth@vger.kernel.org, Sasha Levin <sashal@kernel.org>
Subject: Re: [PATCH 1/1] bluetooth: validate BLE connection interval updates
Message-ID: <20190819180813.04a8e771@kemnade.info>
In-Reply-To: <0cda8242-304e-a073-90d8-63e656e3600c@gmail.com>
References: <f9176553-d4d5-c2e0-ecd7-937cac0d8098@gmail.com>
        <138296C5-49FA-475D-9618-FC8D241B8823@holtmann.org>
        <20190815104419.161177fa@kemnade.info>
        <0cda8242-304e-a073-90d8-63e656e3600c@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Sender: linux-bluetooth-owner@vger.kernel.org
Precedence: bulk

Hi Carey,

On Mon, 19 Aug 2019 07:58:19 -0600
Carey Sonsino <csonsino@gmail.com> wrote:

> This seems like the exact "downside" situation that I described in the=20
> patch writeup.
>=20
> I would still claim that as a Linux system administrator, I should have=20
> control over my system.=A0 If I am operating in a low power environment, =
I=20
> do not want to allow a remote device to apply a setting which causes me=20
> to use more power without any say in the matter.
>=20
In principle I agree here. High connection interval has its downsides,
low connection interval also. Just curios: What are the numbers about
power consumption here? A few mA? I have only compared these values on
peripherals running on low-power SoCs like e.g. the nrf stuff from nordic.
I see around 1 mA difference there with a power consumption besides of that=
=20
usually measured in the =B5A range. Never tested these things on a linux ma=
chine.

The point here is that with this patch there is insufficient control
about this. Yes, there is the debugfs interface.

But if you want to provide a driver to a gatt service living on top of
bluetoothd dbus api? Ask people to not use distribution kernels?
What options do you have?
using the monitor interface to sniff the connection handle and then
call hci_le_conn_update() to set things?

> The connection min/max interval settings are configuration options that=20
> control how my bluetooth device operates.=A0 Why are these down in debugf=
s=20
> anyway?=A0 I think that a much more appropriate fix would be to migrate=20
> some of the BLE configuration options to sysconfdir (some place like=20
> /etc/bluetooth/ble.conf).=A0 That would also help in the persistence of=20
> these configuration settings, which is kind of a pain with the debugfs=20
> mechanism that gets wiped out and recreated on bootup.
>=20
I think that these things should be part of the  dbus api provided
by bluetoothd so that a driver could decide and having defaults outside
of such a dark corner like the debug fs.

> A quicker fix would be to simply set the default connection min interval=
=20
> and connection max interval values to the full range (6, 3200).

Or just maybe a flag allowing such behavior?

> *think* that this could be done by simply updating the values in=20
> hci_core.c, the hci_alloc_dev() function:
>=20
>  =A0=A0=A0 hdev->le_conn_min_interval =3D 0x0018;
>  =A0=A0=A0 hdev->le_conn_max_interval =3D 0x0028;
>=20
> would become:
>=20
>  =A0=A0=A0 hdev->le_conn_min_interval =3D 0x0006;
>  =A0=A0=A0 hdev->le_conn_max_interval =3D 0x0c80;
>=20
> This should allow all devices to negotiate whatever connection interval=20
> they want by default.=A0 If I'm running on a device with debugfs (which I=
=20
> happen to be most of the time), then I can still override these defaults=
=20
> to control my system.
>=20
> Please let me know if you would like me to do any further work towards=20
> resolving this issue.=A0 I'd be happy to test and submit a patch that=20
> changes the default connection min/max interval values- I could probably=
=20
> get that done in the next day or two.=A0 If you would like me to=20
> investigate migrating configuration settings to /etc then I'd be happy=20
> to do that as well, but it might take a bit more effort and time.
>=20
Well, all these things are important, but are new features but there is a
problem:
The kernel patch has gone into the stable trees and from there into distrib=
utions,
so how can these new features flow down the same path.

Regards,
Andreas