New property for DeviceFound signals to distinguish EIR devices
Hi,
I think it'd be beneficial to add a new property to the DeviceFound signals so that the UI performing the discovery would know if an Extended Inquiry Result was received and therefore conclude that this is a 2.1 (or newer) device. With the current API this is not really possible, e.g. a device name could be part of the signal because of EIR or it might be there simply because it was cached previously.
The benefit in knowing this "2.1 or newer" information is that the UI could anticipate whether legacy or secure simple pairing will be triggered or not. For us in Maemo we have only had to worry about legacy pairing so far due to 2.0 or older hardware. Because of this we have been able to eliminate the delay in getting a PIN request from the controller and the user responding to it simply by asking the user for the PIN *before* starting the actual pairing procedure. Especially for longer PINs there's a risk of a timeout error on the lower layers and so this delay elimination is a good thing.
Now, that SSP might occur it would be confusing for the user to be presented with a PIN dialog and then a few moments later with e.g. a passkey confirmation dialog for SSP. However, with the new property the UI could make this preliminary PIN entry only occur when it's really needed.
So, what should the new property be called?
* I proposed "SSP" (a boolean) on IRC but Marcel didn't think it's such a good idea since there shouldn't be any artificial coupling between SSP and EIR (since essentially they are two different things even though they typically occur together).
* If SSP isn't good, then how about "EIR" which would also be a boolean
* Another alternative would be to introduce a "Version" property that could be reused also in the Adapter interface to show which core spec version is being used. Another question is should it be numeric or a string? A numeric one would allow easy comparisons but a string would be more flexible and consistent with the rest of the D-Bus API.
Any other suggestions or opinions?
Johan
Marcel Holtmann
maintainerHi Johan,
Quoted 30 lines
I think it'd be beneficial to add a new property to the DeviceFound signals so that the UI performing the discovery would know if an Extended Inquiry Result was received and therefore conclude that this is a 2.1 (or newer) device. With the current API this is not really possible, e.g. a device name could be part of the signal because of EIR or it might be there simply because it was cached previously.
The benefit in knowing this "2.1 or newer" information is that the UI could anticipate whether legacy or secure simple pairing will be triggered or not. For us in Maemo we have only had to worry about legacy pairing so far due to 2.0 or older hardware. Because of this we have been able to eliminate the delay in getting a PIN request from the controller and the user responding to it simply by asking the user for the PIN *before* starting the actual pairing procedure. Especially for longer PINs there's a risk of a timeout error on the lower layers and so this delay elimination is a good thing.
Now, that SSP might occur it would be confusing for the user to be presented with a PIN dialog and then a few moments later with e.g. a passkey confirmation dialog for SSP. However, with the new property the UI could make this preliminary PIN entry only occur when it's really needed.
So, what should the new property be called?
* I proposed "SSP" (a boolean) on IRC but Marcel didn't think it's such a good idea since there shouldn't be any artificial coupling between SSP and EIR (since essentially they are two different things even though they typically occur together).
Quoted 7 lines
* If SSP isn't good, then how about "EIR" which would also be a boolean
* Another alternative would be to introduce a "Version" property that could be reused also in the Adapter interface to show which core spec version is being used. Another question is should it be numeric or a string? A numeric one would allow easy comparisons but a string would be more flexible and consistent with the rest of the D-Bus API.
so I do like the idea of a boolean property. That is pretty simple. So my current proposal would be "LegacyPairing". Since the Simple Pairing should become the default and handles all the use cases right, we only need to detect the cases for the old 2.0 and before devices.
However this has a limitation. We make the assumption that we always get the Extended Inquiry Result. So setting LegacyPairing=True doesn't mean that we are not doing Simple Pairing. It just means that we don't know at this point of time if the remote device supports its. In practice we might not be seeing this, but it is not mandatory for 2.1 devices to enable Extended Inquiry Response.
We could also cache the value since if we do SDP before initiating a dedicated pairing (only fails with Security Mode 3 devices) and then we do get the real value if Simple Pairing is enabled or not.
So while adding it to the DeviceFound properties would be nice, but I think adding it to the actual device properties might make more sense. However right now the wizard is not doing SDP before pairing.
Regards
Marcel
Hi Marcel,
Quoted 11 lines · Marcel Holtmann
so I do like the idea of a boolean property. That is pretty simple. So my current proposal would be "LegacyPairing". Since the Simple Pairing should become the default and handles all the use cases right, we only need to detect the cases for the old 2.0 and before devices.
However this has a limitation. We make the assumption that we always get the Extended Inquiry Result. So setting LegacyPairing=True doesn't mean that we are not doing Simple Pairing. It just means that we don't know at this point of time if the remote device supports its. In practice we might not be seeing this, but it is not mandatory for 2.1 devices to enable Extended Inquiry Response.
I'd be fine with adding a LecacyPairing boolean both to the DeviceFound signal and the Device interface. I don't think the false-positive case is too bad since it shouldn't happen often and the UI can simply fall back to SSP then (which is a potential source of confusion for the user but at least the pairing can proceed).
Quoted 3 lines
We could also cache the value since if we do SDP before initiating a dedicated pairing (only fails with Security Mode 3 devices) and then we do get the real value if Simple Pairing is enabled or not.
The problem is precisely these Security Mode 3 devices. I still see plenty of them when I go to UnplugFests. If we go ahead and try to do SDP with them before dedicated bonding we've already lost the chance to get the PIN from the user before its actually requested by the controler. We could simply reject any PIN request caused by the SDP but that has at least the following issues:
1. it would make the overall procedure longer (and the double connect/auth request could have interop. implications with some devices)
2. it can't be done in a clean way with the existing D-Bus API since there's no direct agent association for CreateDevice like there is for CreatePairedDevice
Quoted 3 lines
So while adding it to the DeviceFound properties would be nice, but I think adding it to the actual device properties might make more sense. However right now the wizard is not doing SDP before pairing.
At least according to the API doc, whatever property is available in the DeviceFound signal should also be available in the Device interface. So if we add this to the DeviceFound signal the rest takes care of itself if we intend to conform to the current API description :)
Johan
Marcel Holtmann
maintainerHi Johan,
Quoted 12 lines
Quoted 11 lines
so I do like the idea of a boolean property. That is pretty simple. So my current proposal would be "LegacyPairing". Since the Simple Pairing should become the default and handles all the use cases right, we only need to detect the cases for the old 2.0 and before devices.
However this has a limitation. We make the assumption that we always get the Extended Inquiry Result. So setting LegacyPairing=True doesn't mean that we are not doing Simple Pairing. It just means that we don't know at this point of time if the remote device supports its. In practice we might not be seeing this, but it is not mandatory for 2.1 devices to enable Extended Inquiry Response.
Quoted 5 lines
I'd be fine with adding a LecacyPairing boolean both to the DeviceFound signal and the Device interface. I don't think the false-positive case is too bad since it shouldn't happen often and the UI can simply fall back to SSP then (which is a potential source of confusion for the user but at least the pairing can proceed).
okay. Then lets add a boolean "LegacyPairing" property and see how far this helps us with improving the wizard.
Regards
Marcel