On Mon, Oct 05, 2020 at 07:14:44PM +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
> 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?
thanks,
greg k-h
