| Message ID | 20201003135449.GA2691@kroah.com |
|---|---|
| State | New |
| Headers | show |
| Series | Revert "Bluetooth: Update resolving list when updating whitelist" | expand |
Hi Greg, > This reverts commit 0eee35bdfa3b472cc986ecc6ad76293fdcda59e2 as it > breaks all bluetooth connections on my machine. > > Cc: Marcel Holtmann <marcel@holtmann.org> > Cc: Sathish Narsimman <sathish.narasimman@intel.com> > Fixes: 0eee35bdfa3b ("Bluetooth: Update resolving list when updating whitelist") > Signed-off-by: Greg Kroah-Hartman <gregkh@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. When you run btmon does it indicate any errors? Do you have a chance to test net-next and see the LL Privacy there might have addressed this? Regards Marcel
On Sat, Oct 03, 2020 at 05:51:03PM +0200, Marcel Holtmann wrote: > Hi Greg, > > > This reverts commit 0eee35bdfa3b472cc986ecc6ad76293fdcda59e2 as it > > breaks all bluetooth connections on my machine. > > > > Cc: Marcel Holtmann <marcel@holtmann.org> > > Cc: Sathish Narsimman <sathish.narasimman@intel.com> > > Fixes: 0eee35bdfa3b ("Bluetooth: Update resolving list when updating whitelist") > > Signed-off-by: Greg Kroah-Hartman <gregkh@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? > Do you have a chance to test net-next and see the LL Privacy there might have addressed this? Have a specific set of patches I can test? It wouldn't be good to have 5.9-final go out with this not working at all. thanks, greg k-h
Hi Greg, >>> This reverts commit 0eee35bdfa3b472cc986ecc6ad76293fdcda59e2 as it >>> breaks all bluetooth connections on my machine. >>> >>> Cc: Marcel Holtmann <marcel@holtmann.org> >>> Cc: Sathish Narsimman <sathish.narasimman@intel.com> >>> Fixes: 0eee35bdfa3b ("Bluetooth: Update resolving list when updating whitelist") >>> Signed-off-by: Greg Kroah-Hartman <gregkh@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. >> Do you have a chance to test net-next and see the LL Privacy there might have addressed this? > > Have a specific set of patches I can test? It wouldn't be good to have > 5.9-final go out with this not working at all. Of course not, but so far you are the only one reported a problem. Maybe you have some funky hardware in your machine that needs a quirk. Regards Marcel
On Sat, Oct 03, 2020 at 08:33:18PM +0200, Marcel Holtmann wrote: > Hi Greg, > > >>> This reverts commit 0eee35bdfa3b472cc986ecc6ad76293fdcda59e2 as it > >>> breaks all bluetooth connections on my machine. > >>> > >>> Cc: Marcel Holtmann <marcel@holtmann.org> > >>> Cc: Sathish Narsimman <sathish.narasimman@intel.com> > >>> Fixes: 0eee35bdfa3b ("Bluetooth: Update resolving list when updating whitelist") > >>> Signed-off-by: Greg Kroah-Hartman <gregkh@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? thanks, greg k-h
On Sun, Oct 04, 2020 at 12:51:24PM +0200, Greg Kroah-Hartman wrote: > On Sat, Oct 03, 2020 at 08:33:18PM +0200, Marcel Holtmann wrote: > > Hi Greg, > > > > >>> This reverts commit 0eee35bdfa3b472cc986ecc6ad76293fdcda59e2 as it > > >>> breaks all bluetooth connections on my machine. > > >>> > > >>> Cc: Marcel Holtmann <marcel@holtmann.org> > > >>> Cc: Sathish Narsimman <sathish.narasimman@intel.com> > > >>> Fixes: 0eee35bdfa3b ("Bluetooth: Update resolving list when updating whitelist") > > >>> Signed-off-by: Greg Kroah-Hartman <gregkh@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. > And any hints on how to read this file? 'btsnoop' has no man page, and the --help options are pretty sparse :( thanks, greg k-h
On Sun, 2020-10-04 at 12:51 +0200, Greg Kroah-Hartman wrote: > On Sat, Oct 03, 2020 at 08:33:18PM +0200, Marcel Holtmann wrote: > > Hi Greg, > > > > > > > This reverts commit 0eee35bdfa3b472cc986ecc6ad76293fdcda59e2 > > > > > as it > > > > > breaks all bluetooth connections on my machine. > > > > > > > > > > Cc: Marcel Holtmann <marcel@holtmann.org> > > > > > Cc: Sathish Narsimman <sathish.narasimman@intel.com> > > > > > Fixes: 0eee35bdfa3b ("Bluetooth: Update resolving list when > > > > > updating whitelist") > > > > > Signed-off-by: Greg Kroah-Hartman > > > > > <gregkh@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? Use bluetoothctl instead, the Bluetooth Settings from GNOME also run a discovery the whole time the panel is opened, and this breaks a fair number of poor quality adapters. This is worked-around in the most recent version, but using bluetoothctl is a better debugging option in all cases. Cheers
On Sun, Oct 04, 2020 at 02:17:06PM +0200, Bastien Nocera wrote: > On Sun, 2020-10-04 at 12:51 +0200, Greg Kroah-Hartman wrote: > > On Sat, Oct 03, 2020 at 08:33:18PM +0200, Marcel Holtmann wrote: > > > Hi Greg, > > > > > > > > > This reverts commit 0eee35bdfa3b472cc986ecc6ad76293fdcda59e2 > > > > > > as it > > > > > > breaks all bluetooth connections on my machine. > > > > > > > > > > > > Cc: Marcel Holtmann <marcel@holtmann.org> > > > > > > Cc: Sathish Narsimman <sathish.narasimman@intel.com> > > > > > > Fixes: 0eee35bdfa3b ("Bluetooth: Update resolving list when > > > > > > updating whitelist") > > > > > > Signed-off-by: Greg Kroah-Hartman > > > > > > <gregkh@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? > > Use bluetoothctl instead, the Bluetooth Settings from GNOME also run a > discovery the whole time the panel is opened, and this breaks a fair > number of poor quality adapters. This is worked-around in the most > recent version, but using bluetoothctl is a better debugging option in > all cases. Ok, but how do I use that tool? How do I shut down the gnome bluetooth stuff? I need newbie steps here please for what to run and what to show you. thanks, greg k-h
On Sun, 2020-10-04 at 15:18 +0200, Greg Kroah-Hartman wrote: > On Sun, Oct 04, 2020 at 02:17:06PM +0200, Bastien Nocera wrote: > > On Sun, 2020-10-04 at 12:51 +0200, Greg Kroah-Hartman wrote: > > > On Sat, Oct 03, 2020 at 08:33:18PM +0200, Marcel Holtmann wrote: > > > > Hi Greg, > > > > > > > > > > > This reverts commit > > > > > > > 0eee35bdfa3b472cc986ecc6ad76293fdcda59e2 > > > > > > > as it > > > > > > > breaks all bluetooth connections on my machine. > > > > > > > > > > > > > > Cc: Marcel Holtmann <marcel@holtmann.org> > > > > > > > Cc: Sathish Narsimman <sathish.narasimman@intel.com> > > > > > > > Fixes: 0eee35bdfa3b ("Bluetooth: Update resolving list > > > > > > > when > > > > > > > updating whitelist") > > > > > > > Signed-off-by: Greg Kroah-Hartman > > > > > > > <gregkh@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? > > > > Use bluetoothctl instead, the Bluetooth Settings from GNOME also > > run a > > discovery the whole time the panel is opened, and this breaks a > > fair > > number of poor quality adapters. This is worked-around in the most > > recent version, but using bluetoothctl is a better debugging option > > in > > all cases. > > Ok, but how do I use that tool? How do I shut down the gnome > bluetooth > stuff? You close the settings window... > I need newbie steps here please for what to run and what to show you. bluetoothctl connect "bluetooth address" eg. bluetoothctl connect "12:34:56:78:90"
Hi Greg, >>>>> This reverts commit 0eee35bdfa3b472cc986ecc6ad76293fdcda59e2 as it >>>>> breaks all bluetooth connections on my machine. >>>>> >>>>> Cc: Marcel Holtmann <marcel@holtmann.org> >>>>> Cc: Sathish Narsimman <sathish.narasimman@intel.com> >>>>> Fixes: 0eee35bdfa3b ("Bluetooth: Update resolving list when updating whitelist") >>>>> Signed-off-by: Greg Kroah-Hartman <gregkh@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? 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. Regards Marcel
On Sun, Oct 04, 2020 at 03:23:18PM +0200, Bastien Nocera wrote: > On Sun, 2020-10-04 at 15:18 +0200, Greg Kroah-Hartman wrote: > > On Sun, Oct 04, 2020 at 02:17:06PM +0200, Bastien Nocera wrote: > > > On Sun, 2020-10-04 at 12:51 +0200, Greg Kroah-Hartman wrote: > > > > On Sat, Oct 03, 2020 at 08:33:18PM +0200, Marcel Holtmann wrote: > > > > > Hi Greg, > > > > > > > > > > > > > This reverts commit > > > > > > > > 0eee35bdfa3b472cc986ecc6ad76293fdcda59e2 > > > > > > > > as it > > > > > > > > breaks all bluetooth connections on my machine. > > > > > > > > > > > > > > > > Cc: Marcel Holtmann <marcel@holtmann.org> > > > > > > > > Cc: Sathish Narsimman <sathish.narasimman@intel.com> > > > > > > > > Fixes: 0eee35bdfa3b ("Bluetooth: Update resolving list > > > > > > > > when > > > > > > > > updating whitelist") > > > > > > > > Signed-off-by: Greg Kroah-Hartman > > > > > > > > <gregkh@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? > > > > > > Use bluetoothctl instead, the Bluetooth Settings from GNOME also > > > run a > > > discovery the whole time the panel is opened, and this breaks a > > > fair > > > number of poor quality adapters. This is worked-around in the most > > > recent version, but using bluetoothctl is a better debugging option > > > in > > > all cases. > > > > Ok, but how do I use that tool? How do I shut down the gnome > > bluetooth > > stuff? > > You close the settings window... > > > I need newbie steps here please for what to run and what to show you. > > bluetoothctl connect "bluetooth address" > eg. > bluetoothctl connect "12:34:56:78:90" Ok, here that is on a clean 5.9-rc8 release: $ 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 I've attached the trace log from that effort. I'll go try Marcel's proposed patch now as well... thanks, greg k-h
On Sun, Oct 04, 2020 at 06:59:24PM +0200, Marcel Holtmann wrote: > Hi Greg, > > >>>>> This reverts commit 0eee35bdfa3b472cc986ecc6ad76293fdcda59e2 as it > >>>>> breaks all bluetooth connections on my machine. > >>>>> > >>>>> Cc: Marcel Holtmann <marcel@holtmann.org> > >>>>> Cc: Sathish Narsimman <sathish.narasimman@intel.com> > >>>>> Fixes: 0eee35bdfa3b ("Bluetooth: Update resolving list when updating whitelist") > >>>>> Signed-off-by: Greg Kroah-Hartman <gregkh@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 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? :) Anyway, feel free to put: Tested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> on the above patch and hopefully get it to Linus for 5.9-final. thanks, greg k-h
Hi Greg, >>>>>>> This reverts commit 0eee35bdfa3b472cc986ecc6ad76293fdcda59e2 as it >>>>>>> breaks all bluetooth connections on my machine. >>>>>>> >>>>>>> Cc: Marcel Holtmann <marcel@holtmann.org> >>>>>>> Cc: Sathish Narsimman <sathish.narasimman@intel.com> >>>>>>> Fixes: 0eee35bdfa3b ("Bluetooth: Update resolving list when updating whitelist") >>>>>>> Signed-off-by: Greg Kroah-Hartman <gregkh@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. > Anyway, feel free to put: > > Tested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > > on the above patch and hopefully get it to Linus for 5.9-final. Sadly, it is a poor hot-needle fix. Regards Marcel
On Mon, Oct 05, 2020 at 02:19:32PM +0200, Marcel Holtmann wrote: > Hi Greg, > > >>>>>>> This reverts commit 0eee35bdfa3b472cc986ecc6ad76293fdcda59e2 as it > >>>>>>> breaks all bluetooth connections on my machine. > >>>>>>> > >>>>>>> Cc: Marcel Holtmann <marcel@holtmann.org> > >>>>>>> Cc: Sathish Narsimman <sathish.narasimman@intel.com> > >>>>>>> Fixes: 0eee35bdfa3b ("Bluetooth: Update resolving list when updating whitelist") > >>>>>>> Signed-off-by: Greg Kroah-Hartman <gregkh@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 thanks, greg k-h
Hi Greg, >>>>>>>>> This reverts commit 0eee35bdfa3b472cc986ecc6ad76293fdcda59e2 as it >>>>>>>>> breaks all bluetooth connections on my machine. >>>>>>>>> >>>>>>>>> Cc: Marcel Holtmann <marcel@holtmann.org> >>>>>>>>> Cc: Sathish Narsimman <sathish.narasimman@intel.com> >>>>>>>>> Fixes: 0eee35bdfa3b ("Bluetooth: Update resolving list when updating whitelist") >>>>>>>>> Signed-off-by: Greg Kroah-Hartman <gregkh@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. 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. Anyhow, if my suspicion is correct, then I just need to figure out on how we fix this for 5.9-rc8 and also net-next. We might have to have two different patches. Just carrying the revert forward is going to cause some complicated merging and a broken -next. Regards Marcel
On Mon, Oct 05, 2020 at 05:44:48PM +0200, Marcel Holtmann wrote: > Hi Greg, > > >>>>>>>>> This reverts commit 0eee35bdfa3b472cc986ecc6ad76293fdcda59e2 as it > >>>>>>>>> breaks all bluetooth connections on my machine. > >>>>>>>>> > >>>>>>>>> Cc: Marcel Holtmann <marcel@holtmann.org> > >>>>>>>>> Cc: Sathish Narsimman <sathish.narasimman@intel.com> > >>>>>>>>> Fixes: 0eee35bdfa3b ("Bluetooth: Update resolving list when updating whitelist") > >>>>>>>>> Signed-off-by: Greg Kroah-Hartman <gregkh@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. thanks, greg k-h
Hi Greg, >>>>>>>>>>> This reverts commit 0eee35bdfa3b472cc986ecc6ad76293fdcda59e2 as it >>>>>>>>>>> breaks all bluetooth connections on my machine. >>>>>>>>>>> >>>>>>>>>>> Cc: Marcel Holtmann <marcel@holtmann.org> >>>>>>>>>>> Cc: Sathish Narsimman <sathish.narasimman@intel.com> >>>>>>>>>>> Fixes: 0eee35bdfa3b ("Bluetooth: Update resolving list when updating whitelist") >>>>>>>>>>> Signed-off-by: Greg Kroah-Hartman <gregkh@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? 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. Regards Marcel
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 <marcel@holtmann.org> > >>>>>>>>>>> Cc: Sathish Narsimman <sathish.narasimman@intel.com> > >>>>>>>>>>> Fixes: 0eee35bdfa3b ("Bluetooth: Update resolving list when updating whitelist") > >>>>>>>>>>> Signed-off-by: Greg Kroah-Hartman <gregkh@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
On Mon, Oct 05, 2020 at 07:38:35PM +0200, Greg Kroah-Hartman wrote: > 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 <marcel@holtmann.org> > > >>>>>>>>>>> Cc: Sathish Narsimman <sathish.narasimman@intel.com> > > >>>>>>>>>>> Fixes: 0eee35bdfa3b ("Bluetooth: Update resolving list when updating whitelist") > > >>>>>>>>>>> Signed-off-by: Greg Kroah-Hartman <gregkh@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. thanks, greg k-h
Hi Greg, >>>>>>>>>>>>>> This reverts commit 0eee35bdfa3b472cc986ecc6ad76293fdcda59e2 as it >>>>>>>>>>>>>> breaks all bluetooth connections on my machine. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Cc: Marcel Holtmann <marcel@holtmann.org> >>>>>>>>>>>>>> Cc: Sathish Narsimman <sathish.narasimman@intel.com> >>>>>>>>>>>>>> Fixes: 0eee35bdfa3b ("Bluetooth: Update resolving list when updating whitelist") >>>>>>>>>>>>>> Signed-off-by: Greg Kroah-Hartman <gregkh@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 debug/bluetooth/hci0/device_list? 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. 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. 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. Regards Marcel
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 <marcel@holtmann.org> > > >>>>>>>>>>>>>> Cc: Sathish Narsimman <sathish.narasimman@intel.com> > > >>>>>>>>>>>>>> Fixes: 0eee35bdfa3b ("Bluetooth: Update resolving list when updating whitelist") > > >>>>>>>>>>>>>> Signed-off-by: Greg Kroah-Hartman <gregkh@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... thanks, greg k-h
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 <marcel@holtmann.org> > > > >>>>>>>>>>>>>> Cc: Sathish Narsimman <sathish.narasimman@intel.com> > > > >>>>>>>>>>>>>> Fixes: 0eee35bdfa3b ("Bluetooth: Update resolving list when updating whitelist") > > > >>>>>>>>>>>>>> Signed-off-by: Greg Kroah-Hartman <gregkh@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
diff --git a/net/bluetooth/hci_request.c b/net/bluetooth/hci_request.c index e0269192f2e5..75b0a4776f10 100644 --- a/net/bluetooth/hci_request.c +++ b/net/bluetooth/hci_request.c @@ -697,21 +697,6 @@ static void del_from_white_list(struct hci_request *req, bdaddr_t *bdaddr, bt_dev_dbg(req->hdev, "Remove %pMR (0x%x) from whitelist", &cp.bdaddr, cp.bdaddr_type); hci_req_add(req, HCI_OP_LE_DEL_FROM_WHITE_LIST, sizeof(cp), &cp); - - if (use_ll_privacy(req->hdev)) { - struct smp_irk *irk; - - irk = hci_find_irk_by_addr(req->hdev, bdaddr, bdaddr_type); - if (irk) { - struct hci_cp_le_del_from_resolv_list cp; - - cp.bdaddr_type = bdaddr_type; - bacpy(&cp.bdaddr, bdaddr); - - hci_req_add(req, HCI_OP_LE_DEL_FROM_RESOLV_LIST, - sizeof(cp), &cp); - } - } } /* Adds connection to white list if needed. On error, returns -1. */ @@ -732,7 +717,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; } @@ -750,28 +735,6 @@ static int add_to_white_list(struct hci_request *req, cp.bdaddr_type); hci_req_add(req, HCI_OP_LE_ADD_TO_WHITE_LIST, sizeof(cp), &cp); - if (use_ll_privacy(hdev)) { - struct smp_irk *irk; - - irk = hci_find_irk_by_addr(hdev, ¶ms->addr, - params->addr_type); - if (irk) { - struct hci_cp_le_add_to_resolv_list cp; - - cp.bdaddr_type = params->addr_type; - bacpy(&cp.bdaddr, ¶ms->addr); - memcpy(cp.peer_irk, irk->val, 16); - - if (hci_dev_test_flag(hdev, HCI_PRIVACY)) - memcpy(cp.local_irk, hdev->irk, 16); - else - memset(cp.local_irk, 0, 16); - - hci_req_add(req, HCI_OP_LE_ADD_TO_RESOLV_LIST, - sizeof(cp), &cp); - } - } - return 0; } @@ -812,7 +775,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; }
This reverts commit 0eee35bdfa3b472cc986ecc6ad76293fdcda59e2 as it breaks all bluetooth connections on my machine. Cc: Marcel Holtmann <marcel@holtmann.org> Cc: Sathish Narsimman <sathish.narasimman@intel.com> Fixes: 0eee35bdfa3b ("Bluetooth: Update resolving list when updating whitelist") Signed-off-by: Greg Kroah-Hartman <gregkh@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?