Hi Johan, On Tue, Apr 30, 2013 at 12:23 AM, Johan Hedberg <johan.hedberg@xxxxxxxxx> wrote: > This has been discussed many times in the past but nothing concrete has > been done about it so far. The core spec essentially gives us two > options: either to reject the link or to ask the user if it's ok to > repair (and loose the old key) and then proceed with repairing. We've so > far only implemented the first option. I think that in that the first option is ok if the connection is initiated by the device, since it could be a malicious device with a fake key trying to spam us. But if we reject and ignore the key provided by the device (or the devices doesn't know it), we still need to give the user a way to re-pair the device. I don't like the idea of extending the Device1.Connect() method with pairing related stuff, since some devices (mostly mice) are not normally-connectable and we should not expect the Connect() to work for those devices. Also, if the device supports encryption but don't require it (like keyboards), the way I have to tell BlueZ that I want an encrypted connection is to Pair the device first, and make sure the device is Paired before Connect. We would have to make sure then that Connect() a device reported as Paired does ensure a encrypted even after repair, and also I will require the client to register an agent before calling Connect() just in case the connect requires it... and currently we don't need that. Mac OS have done a good job here, displaying already paired devices in the Bluetooth Setup Assistant when they are in discovery mode. If you attempt to pair to one of those devices it will ask you about un-pairing and re-pairing with that device, and loosing the previous linkkey there (see screenshot here http://goo.gl/fGJ2U ). Only the paired devices that are in discovery are shown there in the list. The problem is that I can't implement such a nice interface with the current BlueZ API, since I don't known when a paired device is replying to the inquiry request or not. BlueZ knows that, but I don't know that from the dbus API. That's why I want to introduce the "Discovering" property. It will be also handy if Device1.Pair() allows me to re-pair the device and only replaces the linkkey if the pairing works. Right now, if the user wants to re-pair a device it has to remove it, wait several seconds until it appears in a discovery session and then call Pair in that new device. This possible, but not as user-friendly as it could be, and the change I'm proposing is backward compatible with the existing users since the only changed behavior is when trying to Pair an already Paired device. Alex. -- 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
