Re: bluez-gnome wizard deficiencies make it mostly useless

Re: bluez-gnome wizard deficiencies make it mostly useless

[Jim Carter]

On Wed, 12 Nov 2008, Sebastian Spaeth wrote:

> I see 2 solutions and I would like input in what bluez-gnome devs think:
> 1) Try to pair with random PIN if that fails try "0000", "1234", "1111".
> This would at least cover about 90% of all devices and only special case
> the rest.
> 
> 2) Prepopulate a Random PIN in a field but allow the user to override
> that PIN. After all he should know best what PIN to use.

3)  A little more complicated: if the device class suggests no keyboard,
try the hardwired codes listed above, and in the 10% of cases where that 
fails (or if the device class suggests that there is a keyboard), then pop 
the dialog box for solution #2.  Particularly crappy devices may have a 
problem if pairing fails, so it could be helpful to have an override to 
bypass the hardwired codes even for device classes where they would 
normally be tried.

James F. Carter          Voice 310 825 2897    FAX 310 206 6673
UCLA-Mathnet;  6115 MSA; 520 Portola Plaza; Los Angeles, CA, USA  90095-1555
Email: jimc@math.ucla.edu    http://www.math.ucla.edu/~jimc (q.v. for PGP key)

Re: bluez-gnome wizard deficiencies make it mostly useless

[Bastien Nocera]

On Wed, 2008-11-12 at 11:43 +0100, Sebastian Spaeth wrote:
<snip>
> I caused quite a ruckus in this gnome bug yesterday:
> http://bugzilla.gnome.org/show_bug.cgi?id=560315

You didn't cause a ruckus, people that don't actually read the comments
did.

> Currently the bluez-gnome connection wizard fails invariably for all BT
> devices that don't have a keyboard and are not special cased in source code.

Mice, tablets, keyboards, headsets, hands-free, phones work. Only GPS
devices and mice, and headsets that don't use '0000' as the PIN codes
don't work.

That's not very many, and I managed to pair every single one of my
devices without a problem (and I have quite a lot of them).

> In my case this happens:
> I select the "setup new device" from the bluetooth-applet. Select
> "eGPS-397" which is my BT GPS device. Next, the "connecting" page comes
> up with a brief flash of some "type in random PIN" or something. It
> dissappears within a fraction of a second without giving me the chance
> to interact at all, leading to the page "pairing failed". This makes the
> wizard useless for all BT devices that cannot enter PINs and that are
> not special cased.

We know about that problem. I have a patch in my tree for your
particular GPS device, I'm still waiting for you to file a bug with the
details spelled out.

> Bastien Nocera thinks it would be a bad idea to allow users to enter a
> fixed pin (as a second choice to a default random PIN) via dialog and
> asked to enter a new bug for each device to add it as another special
> case. This is the wrong approach IMHO. Tracking all the devices out
> there and their PINs will be a losing battle and bloat the code. With a
> GPS device product lifecycle of a year, those devices will be outdated
> until the code ships in a Linux distribution.

I didn't say it was a bad idea to allow users to enter a fixed PIN, I
said it would be a bad idea to replace random PINs altogether with
user-provided PINs.

> I see 2 solutions and I would like input in what bluez-gnome devs think:
> 1) Try to pair with random PIN if that fails try "0000", "1234", "1111".
> This would at least cover about 90% of all devices and only special case
> the rest.

That wouldn't work, a lot of devices will get out of pairing mode after
an unsuccesful pairing.

> 2) Prepopulate a Random PIN in a field but allow the user to override
> that PIN. After all he should know best what PIN to use.

That's as bad as making the user enter the PIN themselves.

My solution would be to have a button at the bottom of the device
selection page called "PIN options" (or similar). The button would popup
a dialogue with options:
[X] Automatic PIN selection

[ ] Force a random PIN number

[ ] Use fixed PIN code:
        [X] '0000' (most headsets, mice and GPS devices)
        [ ] '1111'
        [ ] '1234'
        [ ] Custom: ___________

Wording is obviously up for discussion. The code is probably an
afternoon's work for somebody comfortable with GTK+, maybe a bit longer
to get Marcel happy with it ;)

Cheers

Re: bluez-gnome wizard deficiencies make it mostly useless

[Jim Carter]

On Wed, 12 Nov 2008, Bastien Nocera wrote:

> On Wed, 2008-11-12 at 11:43 +0100, Sebastian Spaeth wrote:
> <snip>

> That wouldn't work, a lot of devices will get out of pairing mode after
> an unsuccesful pairing.

It may be just my fumble fingers, but I think with my Motorola HT-820 
headset you have to exit from pairing mode (power cycle) and re-enter if 
you botch the 0000.

> My solution would be to have a button at the bottom of the device
> selection page called "PIN options" (or similar). The button would popup
> a dialogue with options:
> [X] Automatic PIN selection
> 
> [ ] Force a random PIN number
> 
> [ ] Use fixed PIN code:
>         [X] '0000' (most headsets, mice and GPS devices)
>         [ ] '1111'
>         [ ] '1234'
>         [ ] Custom: ___________

Excellent!  But I haven't messed enough with GTK+ to make it happen.

James F. Carter          Voice 310 825 2897    FAX 310 206 6673
UCLA-Mathnet;  6115 MSA; 520 Portola Plaza; Los Angeles, CA, USA  90095-1555
Email: jimc@math.ucla.edu    http://www.math.ucla.edu/~jimc (q.v. for PGP key)

Re: bluez-gnome wizard deficiencies make it mostly useless

[Sebastian Spaeth]

Bastien Nocera wrote:
> You didn't cause a ruckus, people that don't actually read the comments
> did.
:-)

> Mice, tablets, keyboards, headsets, hands-free, phones work. Only GPS
> devices and mice, and headsets that don't use '0000' as the PIN codes
> don't work.

-Nahh, if you read some of the descriptions in the downstream Ubuntu bug
there are many devices that fail: the Ubuntu bug lists gps, headsets,
keyboards, modems, printer as failing, so currently it's more than a few
devices.

-A whole range of headsets seems to compute a fixed PIN based on their
serial number, so hardcoding wouldn't work at all.

-For some devices the random PIN seems generated on the device: "[my]
bluetooth headset generates a random PIN code each time it is put in
pairing mode (has an LCD display)"

> We know about that problem. I have a patch in my tree for your
> particular GPS device, I'm still waiting for you to file a bug with the
> details spelled out.

This GPS device is a no-brand thing that is 2 years old and probably not
even sold anymore. Is it really worth adding special cases for such
niche products? I'd rather this were done in a way that helped all those
devices rather than just mine. (But yes, I'll file a bug on my device,
thanks :-))

> I didn't say it was a bad idea to allow users to enter a fixed PIN, I
> said it would be a bad idea to replace random PINs altogether with
> user-provided PINs.

Sorry, I understood your "Because if we don't force users to use random
PIN codes, they'll always enter
the same "easy" PIN codes." as 'don't ever allow people to enter
nonrandom codes'. But I am happy that this was a misunderstanding.

>> I see 2 solutions and I would like input in what bluez-gnome devs think:
>> 1) Try to pair with random PIN if that fails try "0000", "1234", "1111".
>> This would at least cover about 90% of all devices and only special case
>> the rest.
> That wouldn't work, a lot of devices will get out of pairing mode after
> an unsuccesful pairing.

OK this is not feasible then. I'll happily admit I don't know a lot
about bluetooth, I just want it to get to work :-)

> My solution would be to have a button at the bottom of the device
> selection page called "PIN options" (or similar). The button would popup
> a dialogue with options:
> [X] Automatic PIN selection
> 
> [ ] Force a random PIN number
> 
> [ ] Use fixed PIN code:
>         [X] '0000' (most headsets, mice and GPS devices)
>         [ ] '1111'
>         [ ] '1234'
>         [ ] Custom: ___________

This would work just as well for me. I don't think the selection of
"0000" "1111" "1234" is needed, it makes the dialog quite wordy and
long. Why not just:

 [X] Automatic PIN selection
 [ ] Force a random PIN number
 [ ] Use fixed PIN code: ___________
     (many devices use 0000 or 1234)

I don't really get the difference between "automatic" and "force
random". I take it that automatic would include the special casing as is
done now, while random would only ever do random numbers?

I'd just go for:

 [X] Random PIN
 [ ] Use fixed PIN code: ___________ (prepopulate with 0000?)

and don't try to keep a list of special cases in code. Yes it does mean
that everyone needs to enter "0000" the first time the use their headset
but it makes things easy and transparent.

Will your solution work for above mentioned headsets that generate a PIN
on the headset and display it there?

> Wording is obviously up for discussion. The code is probably an
> afternoon's work for somebody comfortable with GTK+, maybe a bit longer
> to get Marcel happy with it ;)

I've never done anything GTK beyond following the GTK tutorials and my C
is quite rusty by now. If you want me to, I could try my luck, but I'd
rather if someone more proficient went for it first :-).

spaetz

bluez-gnome wizard deficiencies make it mostly useless

[Sebastian Spaeth]

I caused quite a ruckus in this gnome bug yesterday:
http://bugzilla.gnome.org/show_bug.cgi?id=560315

Currently the bluez-gnome connection wizard fails invariably for all BT
devices that don't have a keyboard and are not special cased in source code.

In my case this happens:
I select the "setup new device" from the bluetooth-applet. Select
"eGPS-397" which is my BT GPS device. Next, the "connecting" page comes
up with a brief flash of some "type in random PIN" or something. It
dissappears within a fraction of a second without giving me the chance
to interact at all, leading to the page "pairing failed". This makes the
wizard useless for all BT devices that cannot enter PINs and that are
not special cased.

Bastien Haddess thinks it would be a bad idea to allow users to enter a
fixed pin (as a second choice to a default random PIN) via dialog and
asked to enter a new bug for each device to add it as another special
case. This is the wrong approach IMHO. Tracking all the devices out
there and their PINs will be a losing battle and bloat the code. With a
GPS device product lifecycle of a year, those devices will be outdated
until the code ships in a Linux distribution.

I see 2 solutions and I would like input in what bluez-gnome devs think:
1) Try to pair with random PIN if that fails try "0000", "1234", "1111".
This would at least cover about 90% of all devices and only special case
the rest.

2) Prepopulate a Random PIN in a field but allow the user to override
that PIN. After all he should know best what PIN to use.

Thanks.
spaetz