Heya,
There's a bunch of corner cases that the autopair plugin doesn't handle
and that we used to handle in gnome-bluetooth with BlueZ 4.x.
1) First is the case of the PS3 BD Remote that will reject
authentication when you try to pair to it. gnome-bluetooth knows not to
pair with it.
> <!-- Sony PlayStation 3 Remote Control -->
> <device oui="00:19:C1:" name="BD Remote Control" pin="NULL"/>
> <device oui="00:1E:3D:" name="BD Remote Control" pin="NULL"/>
> <device oui="00:06:F5:" name="BD Remote Control" pin="NULL"/>
Is there a way to say "we can't actually pair" when the client requested
pairing already? Or is that considered a security problem?
2) The second case is pairing this "funny" keyboard that's the iCade
controller. In gnome-bluetooth, we had special code to generate only
joystick movements for the pairing, rather than hard to determine
buttons, so we'd end up with a 6-digit pin using only 1 through 4.
> <!-- ION iCade Game Controller -->
> <device name="iCade" type="keyboard" pin="ICADE"/>
3) We have a whole list of GPS that don't use present themselves as
anything special apart from the name. Most use "0000", but some use
things like "NAVMAN" or "12345678"
> <!-- http://bugzilla.gnome.org/show_bug.cgi?id=560315#c20 -->
> <device oui="00:02:5B:" name="Pharos iGPS-BT" pin="12345678"/>
>
> <!-- https://bugzilla.gnome.org/show_bug.cgi?id=613698 -->
> <device oui="00:0C:A5:" name="NAVMAN GPS ONE" pin="NAVMAN"/>
4) Audio devices will mostly already be supported by the autopair code
(yay!), though we have a few stragglers, most notably this speaker that
can use random pincode, as long as they're only 4 digits in length:
> <!-- http://bugzilla.gnome.org/show_bug.cgi?id=583651 -->
> <device type="audio" oui="00:1A:80:" name="CMT-DH5BT" pin="max:4"/>
5) Printers are missing from the list, that should be an easy fix.
I'll try and send patches for cases 2 through 4, using a static table in
the autopair plugin. If that's not acceptable, I'll create a new
higher-priority plugin that handles those corner cases.
Cheers
On Tue, Nov 19, 2013 at 5:29 AM, Bastien Nocera <[email protected]> wrote:
> 6) I have a "TomTom Remote" that shows up as a keyboard and uses "0000"
> as its PIN. The problem is that, as per the code in autopair.c we'll
> first show a random pincode then quickly fall back to using "0000":
>> /* For keyboards rejecting the first random code
>> * in less than 500ms, try a fixed code. */
>
> How does ChromeOS present this? Does it wait half a second before
> showing the pincode to enter? Because flashing an unusable pincode on
> the screen before succeeding pairing is pretty rubbish in my opinion...
>
This is at least slightly better than OS X, which would display the
random PIN, and then fail pairing - require you to try again, find the
"Advanced" button, set it to one of three or four user-nonsensical
options, and then enter 0000
I'm not saying we can't do better, of course, I'm just saying that we
can do worse :p
A half-second flash of a 6-digit PIN before falling back to a
four-digit one at least works in all of the corner cases - including
this one.
We actually collect logs via metrics of the devices this happens for,
right now we only know of one keyboard that this gets triggered for (a
Motorola Android Keyboard that's no longer on sale) - the TomTom
Remote makes two - I guess nobody's paired a Chromebook with one yet.
I'm way open to ideas for improving the experience here, just as long
as we keep the "works in the common and corner cases" part ;-)
Scott
--
Scott James Remnant | Chrome OS Systems | [email protected] | Google
On Tue, Nov 19, 2013 at 4:31 AM, Bastien Nocera <[email protected]> wrote:
> 1) First is the case of the PS3 BD Remote that will reject
> authentication when you try to pair to it. gnome-bluetooth knows not to
> pair with it.
>
>> <!-- Sony PlayStation 3 Remote Control -->
>> <device oui="00:19:C1:" name="BD Remote Control" pin="NULL"/>
>> <device oui="00:1E:3D:" name="BD Remote Control" pin="NULL"/>
>> <device oui="00:06:F5:" name="BD Remote Control" pin="NULL"/>
>
> Is there a way to say "we can't actually pair" when the client requested
> pairing already? Or is that considered a security problem?
>
It's perfectly valid for Bluetooth devices to not support pairing, and
return a "Pairing Not Supported" or "Authentication Not Supported"
error when attempted. When I tested a PS3 controller here, it seemed
to do that according to spec.
This is especially true for LE devices, the majority I have don't
support pairing.
While it's a "nice to have" for a UI to know in advance, maintaining
that list of devices would be quite an undertaking, it didn't seem
worth special casing the PS3 Controller. Also that should take the
form of a device property the UI can examine to decide whether or not
to offer pairing. Having the plugin fail pairing with the same error
the device would give anyway didn't seem like a "fix".
> 2) The second case is pairing this "funny" keyboard that's the iCade
> controller. In gnome-bluetooth, we had special code to generate only
> joystick movements for the pairing, rather than hard to determine
> buttons, so we'd end up with a 6-digit pin using only 1 through 4.
>
>> <!-- ION iCade Game Controller -->
>> <device name="iCade" type="keyboard" pin="ICADE"/>
>
Having a BlueZ-UI API just for this one device seems like overkill?
This can be just blacklisted in the autopair plugin, or handled by a
higher priority plugin, so the UI can use its special code, no?
> 3) We have a whole list of GPS that don't use present themselves as
> anything special apart from the name. Most use "0000", but some use
> things like "NAVMAN" or "12345678"
>
>> <!-- http://bugzilla.gnome.org/show_bug.cgi?id=560315#c20 -->
>> <device oui="00:02:5B:" name="Pharos iGPS-BT" pin="12345678"/>
>>
>> <!-- https://bugzilla.gnome.org/show_bug.cgi?id=613698 -->
>> <device oui="00:0C:A5:" name="NAVMAN GPS ONE" pin="NAVMAN"/>
>
These could be handled by extending the plugin, or a higher priority
plugin, - right now I don't think the plugin would deal with them at
all?
> 4) Audio devices will mostly already be supported by the autopair code
> (yay!), though we have a few stragglers, most notably this speaker that
> can use random pincode, as long as they're only 4 digits in length:
>
>> <!-- http://bugzilla.gnome.org/show_bug.cgi?id=583651 -->
>> <device type="audio" oui="00:1A:80:" name="CMT-DH5BT" pin="max:4"/>
>
I'm confused by this one - the device accepts any four-digit PIN?
wouldn't 0000 work? :)
> 5) Printers are missing from the list, that should be an easy fix.
>
Unsurprising, since Chromium OS doesn't support printers ;-)
Scott
--
Scott James Remnant | Chrome OS Systems | [email protected] | Google
On Tue, 2013-11-19 at 13:31 +0100, Bastien Nocera wrote:
> Heya,
>
> There's a bunch of corner cases that the autopair plugin doesn't handle
> and that we used to handle in gnome-bluetooth with BlueZ 4.x.
>
> 1) First is the case of the PS3 BD Remote that will reject
> authentication when you try to pair to it. gnome-bluetooth knows not to
> pair with it.
>
> > <!-- Sony PlayStation 3 Remote Control -->
> > <device oui="00:19:C1:" name="BD Remote Control" pin="NULL"/>
> > <device oui="00:1E:3D:" name="BD Remote Control" pin="NULL"/>
> > <device oui="00:06:F5:" name="BD Remote Control" pin="NULL"/>
>
> Is there a way to say "we can't actually pair" when the client requested
> pairing already? Or is that considered a security problem?
I've left the handling in gnome-bluetooth for this one.
> 2) The second case is pairing this "funny" keyboard that's the iCade
> controller. In gnome-bluetooth, we had special code to generate only
> joystick movements for the pairing, rather than hard to determine
> buttons, so we'd end up with a 6-digit pin using only 1 through 4.
>
> > <!-- ION iCade Game Controller -->
> > <device name="iCade" type="keyboard" pin="ICADE"/>
I've sent a patch for that one.
> 3) We have a whole list of GPS that don't use present themselves as
> anything special apart from the name. Most use "0000", but some use
> things like "NAVMAN" or "12345678"
>
> > <!-- http://bugzilla.gnome.org/show_bug.cgi?id=560315#c20 -->
> > <device oui="00:02:5B:" name="Pharos iGPS-BT" pin="12345678"/>
> >
> > <!-- https://bugzilla.gnome.org/show_bug.cgi?id=613698 -->
> > <device oui="00:0C:A5:" name="NAVMAN GPS ONE" pin="NAVMAN"/>
I will leave those in gnome-bluetooth as well, as autopair will not
handle those.
> 4) Audio devices will mostly already be supported by the autopair code
> (yay!), though we have a few stragglers, most notably this speaker that
> can use random pincode, as long as they're only 4 digits in length:
>
> > <!-- http://bugzilla.gnome.org/show_bug.cgi?id=583651 -->
> > <device type="audio" oui="00:1A:80:" name="CMT-DH5BT" pin="max:4"/>
I will carry on handling this in gnome-bluetooth, as the pincodes aren't
displayed for audio devices. So it will try "0000" which will fail, and
bluetoothd should fall back to asking us for the pincode, which we'll
generate according to this rule.
> 5) Printers are missing from the list, that should be an easy fix.
Sent a patch for that.
There's one case left for me to handle.
6) I have a "TomTom Remote" that shows up as a keyboard and uses "0000"
as its PIN. The problem is that, as per the code in autopair.c we'll
first show a random pincode then quickly fall back to using "0000":
> /* For keyboards rejecting the first random code
> * in less than 500ms, try a fixed code. */
How does ChromeOS present this? Does it wait half a second before
showing the pincode to enter? Because flashing an unusable pincode on
the screen before succeeding pairing is pretty rubbish in my opinion...
Cheers