On Wed, Oct 07, 2020 at 03:40:25PM +0200, Greg Kroah-Hartman wrote:
> On Wed, Oct 07, 2020 at 03:23:21PM +0200, Greg Kroah-Hartman wrote:
> > On Mon, Oct 05, 2020 at 08:58:33PM +0200, Marcel Holtmann wrote:
> > > Hi Greg,
> > >
> > > >>>>>>>>>>>>>> This reverts commit
> > > >>>>>>>>>>>>>> 0eee35bdfa3b472cc986ecc6ad76293fdcda59e2 as it
> > > >>>>>>>>>>>>>> breaks all bluetooth connections on my machine.
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> Cc: Marcel Holtmann <mar...@holtmann.org>
> > > >>>>>>>>>>>>>> Cc: Sathish Narsimman <sathish.narasim...@intel.com>
> > > >>>>>>>>>>>>>> Fixes: 0eee35bdfa3b ("Bluetooth: Update resolving list
> > > >>>>>>>>>>>>>> when updating whitelist")
> > > >>>>>>>>>>>>>> Signed-off-by: Greg Kroah-Hartman
> > > >>>>>>>>>>>>>> <gre...@linuxfoundation.org>
> > > >>>>>>>>>>>>>> ---
> > > >>>>>>>>>>>>>> net/bluetooth/hci_request.c | 41
> > > >>>>>>>>>>>>>> ++-----------------------------------
> > > >>>>>>>>>>>>>> 1 file changed, 2 insertions(+), 39 deletions(-)
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> This has been bugging me for since 5.9-rc1, when all
> > > >>>>>>>>>>>>>> bluetooth devices
> > > >>>>>>>>>>>>>> stopped working on my desktop system. I finally got the
> > > >>>>>>>>>>>>>> time to do
> > > >>>>>>>>>>>>>> bisection today, and it came down to this patch.
> > > >>>>>>>>>>>>>> Reverting it on top of
> > > >>>>>>>>>>>>>> 5.9-rc7 restored bluetooth devices and now my input
> > > >>>>>>>>>>>>>> devices properly
> > > >>>>>>>>>>>>>> work.
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> As it's almost 5.9-final, any chance this can be merged
> > > >>>>>>>>>>>>>> now to fix the
> > > >>>>>>>>>>>>>> issue?
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> can you be specific what breaks since our guys and I also
> > > >>>>>>>>>>>>> think the
> > > >>>>>>>>>>>>> ChromeOS guys have been testing these series of patches
> > > >>>>>>>>>>>>> heavily.
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> My bluetooth trackball does not connect at all. With this
> > > >>>>>>>>>>>> reverted, it
> > > >>>>>>>>>>>> all "just works".
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> Same I think for a Bluetooth headset, can check that again
> > > >>>>>>>>>>>> if you really
> > > >>>>>>>>>>>> need me to, but the trackball is reliable here.
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>> When you run btmon does it indicate any errors?
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> How do I run it and where are the errors displayed?
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> you can do btmon -w trace.log and just let it run like
> > > >>>>>>>>>>> tcdpump.
> > > >>>>>>>>>>
> > > >>>>>>>>>> Ok, attached.
> > > >>>>>>>>>>
> > > >>>>>>>>>> The device is not connecting, and then I open the gnome
> > > >>>>>>>>>> bluetooth dialog
> > > >>>>>>>>>> and it scans for devices in the area, but does not connect to
> > > >>>>>>>>>> my
> > > >>>>>>>>>> existing devices at all.
> > > >>>>>>>>>>
> > > >>>>>>>>>> Any ideas?
> > > >>>>>>>>>
> > > >>>>>>>>> the trace file is from -rc7 or from -rc7 with this patch
> > > >>>>>>>>> reverted?
> > > >>>>>>>>>
> > > >>>>>>>>> I asked, because I see no hint that anything goes wrong.
> > > >>>>>>>>> However I have a suspicion if you bisected it to this patch.
> > > >>>>>>>>>
> > > >>>>>>>>> diff --git a/net/bluetooth/hci_request.c
> > > >>>>>>>>> b/net/bluetooth/hci_request.c
> > > >>>>>>>>> index e0269192f2e5..94c0daa9f28d 100644
> > > >>>>>>>>> --- a/net/bluetooth/hci_request.c
> > > >>>>>>>>> +++ b/net/bluetooth/hci_request.c
> > > >>>>>>>>> @@ -732,7 +732,7 @@ static int add_to_white_list(struct
> > > >>>>>>>>> hci_request *req,
> > > >>>>>>>>> return -1;
> > > >>>>>>>>>
> > > >>>>>>>>> /* White list can not be used with RPAs */
> > > >>>>>>>>> - if (!allow_rpa && !use_ll_privacy(hdev) &&
> > > >>>>>>>>> + if (!allow_rpa &&
> > > >>>>>>>>> hci_find_irk_by_addr(hdev, ¶ms->addr,
> > > >>>>>>>>> params->addr_type)) {
> > > >>>>>>>>> return -1;
> > > >>>>>>>>> }
> > > >>>>>>>>> @@ -812,7 +812,7 @@ static u8 update_white_list(struct
> > > >>>>>>>>> hci_request *req)
> > > >>>>>>>>> }
> > > >>>>>>>>>
> > > >>>>>>>>> /* White list can not be used with RPAs */
> > > >>>>>>>>> - if (!allow_rpa && !use_ll_privacy(hdev) &&
> > > >>>>>>>>> + if (!allow_rpa &&
> > > >>>>>>>>> hci_find_irk_by_addr(hdev, &b->bdaddr,
> > > >>>>>>>>> b->bdaddr_type)) {
> > > >>>>>>>>> return 0x00;
> > > >>>>>>>>> }
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>> If you just do the above, does thing work for you again?
> > > >>>>>>>>
> > > >>>>>>>> Corrupted white-space issues aside, yes, it works!
> > > >>>>>>>
> > > >>>>>>> I just pasted it from a different terminal ;)
> > > >>>>>>>
> > > >>>>>>>> I am running 5.9-rc8 with just this change on it and my tracball
> > > >>>>>>>> works
> > > >>>>>>>> just fine.
> > > >>>>>>>>
> > > >>>>>>>>> My suspicion is that the use_ll_privacy check is the wrong one
> > > >>>>>>>>> here. It only checks if hardware feature is available, not if
> > > >>>>>>>>> it is also enabled.
> > > >>>>>>>>
> > > >>>>>>>> How would one go about enabling such a hardware feature if they
> > > >>>>>>>> wanted
> > > >>>>>>>> to? :)
> > > >>>>>>>
> > > >>>>>>> I need to understand what is going wrong for you. I have a
> > > >>>>>>> suspicion,
> > > >>>>>>> but first I need to understand what kind of device you have. I
> > > >>>>>>> hope
> > > >>>>>>> the trace file is enough.
> > > >>>>>>
> > > >>>>>> If you need any other information, just let me know, this is a USB
> > > >>>>>> Bluetooth controller from Intel:
> > > >>>>>>
> > > >>>>>> $ lsusb | grep Blue
> > > >>>>>> Bus 009 Device 002: ID 8087:0029 Intel Corp. AX200 Bluetooth
> > > >>>>>>
> > > >>>>>> And the output of usb-devices for it:
> > > >>>>>> T: Bus=09 Lev=01 Prnt=01 Port=04 Cnt=01 Dev#= 2 Spd=12 MxCh= > > > >>>>>> 0
> > > >>>>>> D: Ver= 2.01 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
> > > >>>>>> P: Vendor=8087 ProdID=0029 Rev=00.01
> > > >>>>>> C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
> > > >>>>>> I: If#=0x0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01
> > > >>>>>> Driver=btusb
> > > >>>>>> I: If#=0x1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01
> > > >>>>>> Driver=btusb
> > > >>>>>
> > > >>>>> I already figured out that it is one of our controllers. The trace
> > > >>>>> file gives it away.
> > > >>>>>
> > > >>>>> So my suspicion is that the device you want to connect to uses RPA
> > > >>>>> (aka random addresses). And we added support for resolving them in
> > > >>>>> the firmware. Your hardware does support that, but the host side is
> > > >>>>> not fully utilizing it and thus your device is filtered out.
> > > >>>>
> > > >>>> Dude, get an email client that line-wraps :)
> > > >>>>
> > > >>>>> If I am not mistaken, then the use_ll_privacy() check in these two
> > > >>>>> specific places need to be replaced with LL Privacy Enabled check.
> > > >>>>> And then the allow_rpa condition will do its job as expected.
> > > >>>>>
> > > >>>>> We can confirm this if you send me a trace with the patch applied.
> > > >>>>
> > > >>>> Want me to disconnect the device and then reconnect it using
> > > >>>> bluetootctl? I'll go do that now...
> > > >>>>
> > > >>>> Ok, it's attached, I did:
> > > >>>>
> > > >>>> $ bluetoothctl disconnect F1:85:91:79:73:70
> > > >>>> Attempting to disconnect from F1:85:91:79:73:70
> > > >>>> [CHG] Device F1:85:91:79:73:70 ServicesResolved: no
> > > >>>> Successful disconnected
> > > >>>>
> > > >>>> And then the gnome bluetooth daemon (or whatever it has) reconnected
> > > >>>> it
> > > >>>> automatically, so you can see the connection happen, and some
> > > >>>> movements
> > > >>>> in the log.
> > > >>>>
> > > >>>> If there's anything else you need, just let me know.
> > > >>>
> > > >>> so the trace file indicates that you are using static addresses and
> > > >>> not RPAs. Now I am confused.
> > > >>>
> > > >>> What is the content of
> > > >>> /sys/kernel/debug/bluetooth/hci0/identity_resolving_keys?
> > > >>
> > > >> f1:85:91:79:73:70 (type 1) f02567096e8537e5dac1cadf548fa750
> > > >> 00:00:00:00:00:00
> > > >
> > > > I rebooted, and the same value was there.
> > > >
> > > >>> The only way I can explain this if you have an entry in that file,
> > > >>> but the device is not using it.
> > > >>>
> > > >>> If you have btmgmt (from bluez.git) you can try "./tools/btmgmt irks”
> > > >>> to clear that list and try again.
> > > >>
> > > >> Ok, I did that, and reconnected, this is still with the kernel that has
> > > >> the patch. Want me to reboot to a "clean" 5.9-rc8?
> > > >
> > > > I rebooted into a clean 5.9-rc8 and the device does not connect.
> > > >
> > > > So I did the following to trace this:
> > > >
> > > > $ sudo btmgmt irks
> > > > Identity Resolving Keys successfully loaded
> > > > $ sudo cat /sys/kernel/debug/bluetooth/hci0/identity_resolving_keys
> > > > $ bluetoothctl connect F1:85:91:79:73:70
> > > > Attempting to connect to F1:85:91:79:73:70
> > > > Failed to connect: org.bluez.Error.Failed
> > > >
> > > > and ran another btmon session to see this, it is attached.
> > >
> > > this is confusing and makes no sense :(
> > >
> > > What is the content of debug/bluetooth/hci0/whitelist and
> >
> > # cat white_list
> > f1:85:91:79:73:70 (type 1)
> >
> > > debug/bluetooth/hci0/device_list?
> >
> > # cat device_list
> > 2c:41:a1:4d:f2:2c (type 0)
> > f1:85:91:79:73:70 (type 1) 3
> >
> > > The only way I can explain this is that somehow the whitelist filter
> > > doesn’t
> > > get programmed correctly and thus the scan will not find your device. Why
> > > this points to use_ll_privacy() is totally unclear to me.
> > >
> > > Btw. reboots won’t help since bluetoothd will restore from settings. You
> > > need to go into the files in /var/lib/bluetooth/ and look for an entry of
> > > IdentityResolvingKey for your device and remove it and then restart
> > > bluetoothd.
> >
> > I see that entry in there, let me remove it...
> >
> > > You can run btmon and will even show you what bluetoothd loads during
> > > start.
> > >
> > > Can you try to do systemctl stop bluetooth, then start btmon and then
> > > systemctl start bluetooth. It should reprogram the controller and I could
> > > see the complete trace on how it sets up your hardware.
> >
> > Ok, I remove the entry for IdentityResolvingKey and restarted bluetoothd
> > and now it works on a clean 5.9-rc8!
> >
> > I'll stop it again and run the monitor and attach it below when it
> > starts back up.
> >
> > Ah, I did just that, and it did not connect this time. Attached is the
> > trace. No IdentityResolvingKey entries anywhere...
> >
> > > If this really breaks for your, it should have been broken for weeks for
> > > everybody. So this is the part that is confusing to me. And my original
> > > suspicion turned out to be wrong.
> >
> > Some bluetoothd interaction?
>
> Ok, rebooting to 5.9-rc8 again, all works fine. Restarting bluetoothd a
> few times, and then it stops working on the 2nd restart.
>
> Logging out of GNOME and then back in, it's working again.
>
> Ugh. Don't know what to say now, but 5.9-rc8 is working for me. I
> guess. Watch out for this with users when 5.9 is released if they end
> up with the same problem.
>
> Let me do a jump back to 5.8 and then to 5.9 and see if that changes
> anything...
And in 5.8.14 the "restart bluetoothd a bunch of times causes problems"
is the same thing here, and logging out and then back into GNOME solves
it.
So that's not 5.9-rc specific.
Anything else you want me to try?
thanks,
greg k-h
