linux-kernel - Re: [PATCH] Bluetooth: Do not cancel advertising when starting a scan

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Wed, 18 Mar 2020 12:54:54 +0100
From:   Marcel Holtmann <marcel@...tmann.org>
To:     Emil Lenngren <emil.lenngren@...il.com>
Cc:     Manish Mandlik <mmandlik@...gle.com>,
        Yoni Shavit <yshavit@...omium.org>,
        Alain Michaud <alainm@...omium.org>,
        Miao-chen Chou <mcchou@...omium.org>,
        Bluez mailing list <linux-bluetooth@...r.kernel.org>,
        Dmitry Grinberg <dmitrygr@...gle.com>,
        "David S. Miller" <davem@...emloft.net>,
        Johan Hedberg <johan.hedberg@...il.com>,
        Network Development <netdev@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Jakub Kicinski <kuba@...nel.org>
Subject: Re: [PATCH] Bluetooth: Do not cancel advertising when starting a scan

Hi Emil,

>>> BlueZ cancels adv when starting a scan, but does not cancel a scan when
>>> starting to adv. Neither is required, so this brings both to a
>>> consistent state (of not affecting each other). Some very rare (I've
>>> never seen one) BT 4.0 chips will fail to do both at once. Even this is
>>> ok since the command that will fail will be the second one, and thus the
>>> common sense logic of first-come-first-served is preserved for BLE
>>> requests.
>>> 
>>> Signed-off-by: Dmitry Grinberg <dmitrygr@...gle.com>
>>> Signed-off-by: Manish Mandlik <mmandlik@...gle.com>
>>> ---
>>> 
>>> net/bluetooth/hci_request.c | 17 -----------------
>>> 1 file changed, 17 deletions(-)
>> 
>> patch has been applied to bluetooth-next tree.
>> 
>> If you know the controller that doesn’t support this, can we blacklist that one and just disable advertising (peripheral mode) for that controller.
> 
> Can't the "LE Supported States" be inspected instead to figure out
> what simultaneous capabilities are supported? It seems a bit rough to
> always assume the worst.

if there are not false-positives, then yes, by all means. However my statement still applies. If a controller can do scanning and advertising at the same time, we should just not indicate support for peripheral mode.

Regards

Marcel