Hi Bjorn, On Fri, Aug 3, 2018 at 5:15 PM, Björn Hauffe <bjoern@xxxxxx> wrote: > Hello Folks, > > i hope this is the right place to report this bug. If i try to pair a > Bluetooth 4.0 Keyboard with the bluez daemon and the first try wasn't > successful, the successful try after that won't displayed by the registered > bluetooth Agent (e.g. GUI). The Pin is still displayed by the Bluetooth tool > forever. I think the problem is, that the registered reply method is never > called by the bluez daemon (over D-Bus). I guess you are talking about the method call not reply here, do you have the daemon logs when that happens? Perhaps you are saying the the daemon never calls Cancel so the agent stay in DisplayPasskey forever? > Tested with Bluetooth GUI tool from Ubuntu 18.04.1 and Fedora 28 (Bluez > 5.49). Also tested with a self written D-Bus based pairing agent. > > My hardware for testing: Logitech K850, Microsoft Designer Keyboard > > > Steps to reproduce: > > 1. made a pairing try with a bluetooth 4.0 Keyboard, but let it fail (wrong > pin for example) > > 2. the second pin will displayed by the bluetooth tool > > 3. enter the new displayed pin correct to successful finish the pairing > process > > 4. you can't see that the pairing process is finish, because the GUI will > not show any feedback. What feedback do you expect here, that Paired is set to true? > 5. open bluetoothctl and check that the keyboard is paired. Does the keyboard pairs or not? > > If i miss something, please let me know. > > > Best regards > > Björn > > -- > To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" > in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Luiz Augusto von Dentz -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html