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
Hi Johan,
> > 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).
okay. Then lets add a boolean "LegacyPairing" property and see how far
this helps us with improving the wizard.
Regards
Marcel
Hi Marcel,
On Mon, Dec 01, 2008, Marcel Holtmann wrote:
> 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).
> 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
> 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
Hi Johan,
> 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.
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