After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 560315 - X3 Micro headset can't pair
X3 Micro headset can't pair
Status: RESOLVED FIXED
Product: gnome-bluetooth
Classification: Core
Component: general
unspecified
Other All
: Normal normal
: ---
Assigned To: gnome-bluetooth-general-maint@gnome.bugs
gnome-bluetooth-general-maint@gnome.bugs
This bug is closed, don't add any mor...
: 560316 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2008-11-11 11:18 UTC by Sebastian Spaeth
Modified: 2009-11-27 18:25 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Adds a modal dialog to confirm the pin (1.76 KB, patch)
2008-11-11 17:02 UTC, thomas
none Details | Review

Description Sebastian Spaeth 2008-11-11 11:18:32 UTC
Please describe the problem:
Please see ubuntu bug https://bugs.launchpad.net/ubuntu/+source/bluez-gnome/+bug/284994/

The bluez-gnome bluetooth wizard requires a random PIN to be entered or tries 1234 hardcoded in the source (recent svn seems to add a few more hardcoded numbers for a few more devices like TomToms).

This fails effectively for all devices that don't have a keyboard and use 0000 (or anything else but 1234), the dialog flashes up "enter pin" and disappears with "pairing failed".

The correct solution is really to offer a dialog in all cases so that people can enter the pin they want. Probably prepoluate the dialog field with a random number but make it still overridable by people.

A big thanks from all bluetooth GPS owners!

Steps to reproduce:


Actual results:


Expected results:


Does this happen every time?


Other information:
Comment 1 Bastien Nocera 2008-11-11 12:49:14 UTC
*** Bug 560316 has been marked as a duplicate of this bug. ***
Comment 2 Bastien Nocera 2008-11-11 13:04:06 UTC
There's nothing using 1234 in the upstream sources. It uses random pincodes for all of the devices, except special-cased ones.

See:
http://git.kernel.org/?p=bluetooth/bluez-gnome.git;a=blob;f=wizard/main.c;h=09209a923e6a68f5586e44811881d1d3490cf2d8;hb=HEAD

For GPS devices, send the output of "hcitool scan" when the device is visible and the pin code to use. File them in separate bugs please.

For the "X3 micro" device (which is really what you should have said in the report instead of trying to discuss the issue, I shouldn't have to go to launchpad to understand what this report is about), send the output of "hcitool scan" when the device is visible, as well as the output of "hcitool inq [bluetooth address]" (should show the class of the device).
Comment 3 thomas 2008-11-11 13:26:37 UTC
I was able to get devices to pair only by hacking the main.c in the wizard file to allow me to override the pin (the hack was if /tmp/wizardpincode exists, use its content to override the random pin).

I have an OBD device that uses 1234, and gps which uses 0000.  I know of no other fixed pincodes, but both of these are used various places.

The current code produces a random pincode, though appears to just call a function (can I point it elsewhere?).  In the ubuntu version at least, there is a series of hacks trying to find headsets which will overwrite the pincode to 0000 if the BT address or function matches.

Instead of the "type this in", it should either have the two above as selectable alternatives, or as was suggested, a numeric field populated wit a random pincode which can be set to anything else before being sent.

What other "more info" is required for this bug?
Comment 4 Sebastian Spaeth 2008-11-11 14:01:51 UTC
1) Sorry for the duplicates. bugzilla.gnome.org hang for about 6 minutes after submission without showing any page, so I repeated the submission.

2) OK, I am sorry it's not 1234, it uses "0000" as default for e.g. headsets while not all headset use "0000". My fault for not looking thorough enough.
74         if (target_type == BLUETOOTH_TYPE_HEADSET ||
75                                 target_type == BLUETOOTH_TYPE_HEADPHONE)
76                 pincode = "0000";

3) I provided the launchpad link for further information about how and where the bug occurred, I hope it was not mandatory to look up to understand what this bug is about. E.g. I don't intent this one to be about the X3 Micro headset (I don't even own a BT headset :-)). The bug is really as follows:
---------------------------------------------------------------------
There is no possibility to enter a specific PIN in the wizard which will make all BT devices fail that use a fixed PIN.

In my specific case, 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 in a fraction of a second without giving me the change to interact leading to the page "pairing failed".

My device:
	00:11:67:80:6E:B7	eGPS-397
	00:11:67:80:6E:B7	clock offset: 0x546f	class: 0x000000
is using "0000" as fixed PIN.
-------------------------------------------------------------------------

Thanks, I hope I managed to express myself better now.
spaetz
Comment 5 Bastien Nocera 2008-11-11 14:15:44 UTC
(In reply to comment #3)
<snip>
> I have an OBD device that uses 1234, and gps which uses 0000.  I know of no
> other fixed pincodes, but both of these are used various places.
<snip>
> What other "more info" is required for this bug?

File separate bugs for your GPS device and OBD device. Provide the information as mentioned in comment 2.

I still need the info for the X3 Micro headset as mentioned in comment 2 as well.

(In reply to comment #4)
<snip>
> In my specific case, 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
> in a fraction of a second without giving me the change to interact leading to
> the page "pairing failed".

GPS devices suck, and most of them don't follow the quite new "Location" class, instead giving completely bogus data, or data of no use (as seen in the output below). So we need to hardcode their PIN codes in the code.

In the future, we might move the special casing to a file, so no recompilation is necessary.

> My device:
>         00:11:67:80:6E:B7       eGPS-397
>         00:11:67:80:6E:B7       clock offset: 0x546f    class: 0x000000
> is using "0000" as fixed PIN.

Easy to fix. Please file a separate bug with that information.

That bug will stay open for when somebody provides the information about the X3 Micro. I don't want this bug to become the one and all of "my device doesn't pair" problems for Ubuntu.
Comment 6 Matthias Urlichs 2008-11-11 14:43:53 UTC
Forgive me if this is a stupid question, but what the hell is wrong with *asking* the user for the PIN?

You might want to offer "try standard PIN 0000", "try standard PIN 1234", and "enter custom PIN: " buttons/fields. 

Hardcoding these devices in the source code is a losing battle.
Comment 7 Bastien Nocera 2008-11-11 14:56:43 UTC
(In reply to comment #6)
> Forgive me if this is a stupid question, but what the hell is wrong with
> *asking* the user for the PIN?
> 
> You might want to offer "try standard PIN 0000", "try standard PIN 1234", and
> "enter custom PIN: " buttons/fields. 

Because if we don't force users to use random PIN codes, they'll always enter the same "easy" PIN codes.

> Hardcoding these devices in the source code is a losing battle.

We'll try to move the definitions to a separate file. Crappy devices will always need quirks. They're crappy...

If you want to discuss that, mail the mailing-list, this isn't a forum...

(And FWIW, you might want to tone down the language a tad).
Comment 8 thomas 2008-11-11 15:07:54 UTC
You cannot possibly code every device, and is the new Gnome policy to have the user have to open a terminal and use VIM on some obscure configuration file or submit patches to get their hardware to work?

I have a half dozen devices, and more if I just look in the bluetooth GPS units available - every one of them will be different.  Do you really want several hundred if not thousand bug reports filed, one for each device?

Bluetooth was originally NOT designed to work the way you want, nor is there a way to fix every device out there.  The devices might be "crappy" but you have to handle them, not try to force every user who has one to use your crappy handling for the crappy devices.

No other system I know of tries to hardcode every special case device.  Even my Nokia tablet - which runs linux and uses Gtk/Hildon pops up a box with a suggested pin, with a pair/cancel button (it would be an extra panel in the wizard).  So the default is the random pincode, but the user has to specifically select and type to change it.  That (or a menu with options) is what I've had to do everywhere else I've had to enter pins.

It cannot be fixed for all cases in any other way.

But if you prefer the thousand bug reports, I can try to go to the various bluetooth GPS, headset, and other sites and see if I can put some automatic web script that will give a boilerplate with device type and bluetooth address and create one here automatically.
Comment 9 Bastien Nocera 2008-11-11 15:22:58 UTC
Good god. Can't you read? Explanations are above. One more comment that's not related to the X3 Micro headset and I'll get the person blocked from bugzilla.

If you want to discuss other means of entering PIN codes, discuss it on the mailing-list. This is getting us nowhere.
Comment 10 Matthias Urlichs 2008-11-11 15:41:53 UTC
Sorry, but if an approach to solving a bug is considered to be wrong, the discussion why that is so isn't misplaced when it happens to be conducted in the bug.

Threatening people to get them kicked off Bugzilla isn't getting us anywhere either.

I can virtually guarantee that every Linux distributoun out there will add something like the approach Thomas has suggested -- rather than field "I can't pair with my device" bugs for every device out there which happens to (a) not use 0000 and (b) lacks a keyboard.
Comment 11 Bastien Nocera 2008-11-11 15:52:27 UTC
I'm going to say this nicely once more. If you have the details about the X3 Micro headset, put them in this bug.

If you have thoughts about how PIN codes should be entered, discuss them on the mailing-list. Most bluez-gnome developers don't read Bugzilla, and given the complete disregard for instructions given on here, it doesn't surprise me.
Comment 12 thomas 2008-11-11 17:02:30 UTC
Created attachment 122433 [details] [review]
Adds a modal dialog to confirm the pin

This fixes it comprehensively for me, but this is my first non-python approach for GTK.

diff -Bbur bluez-gnome-1.8/wizard/main.c bluez-gnome-1.8-tz/wizard/main.c
--- bluez-gnome-1.8/wizard/main.c	2008-10-04 14:32:56.000000000 -0500
+++ bluez-gnome-1.8-tz/wizard/main.c	2008-11-11 10:54:13.000000000 -0600
@@ -56,6 +56,34 @@
 
 static GtkTreeSelection *search_selection = NULL;
 
+static GtkWidget *pinentry, *pindialog;
+static char usepincode[32];
+void clicked()
+{
+  char *text;
+
+  text = gtk_entry_get_text( GTK_ENTRY(pinentry));
+  strcpy( usepincode, text );
+  gtk_widget_destroy( pindialog );
+}
+
+static void run_pin_dialog()
+{
+  GtkWidget *label, *button;
+    
+  pindialog = gtk_dialog_new();
+  label = gtk_label_new ("Passkey for Pairing");
+  pinentry = gtk_entry_new ();
+  gtk_entry_set_text( GTK_ENTRY(pinentry),target_pincode );
+  button = gtk_button_new_with_label("Pair");
+  gtk_signal_connect_object(GTK_OBJECT (button), "clicked", clicked , NULL);
+  gtk_container_add (GTK_CONTAINER (GTK_DIALOG(pindialog)->action_area), button);
+  gtk_container_add (GTK_CONTAINER (GTK_DIALOG(pindialog)->vbox), label);
+  gtk_container_add (GTK_CONTAINER (GTK_DIALOG(pindialog)->vbox), pinentry);
+  gtk_widget_show_all (pindialog);
+  gtk_dialog_run( GTK_DIALOG(pindialog) );
+}
+
 static gboolean pincode_callback(DBusGMethodInvocation *context,
 					DBusGProxy *device, gpointer user_data)
 {
@@ -72,12 +100,19 @@
 				target_type == BLUETOOTH_TYPE_HEADPHONE)
 		pincode = "0000";
 
+
+	target_pincode = pincode;
+
+	strcpy( usepincode, pincode );
+
+	run_pin_dialog();
+
 	text = g_strdup_printf(_("Please enter the following PIN code: %s"),
-								pincode);
+								usepincode);
 	gtk_label_set_markup(GTK_LABEL(label_passkey), text);
 	g_free(text);
 
-	dbus_g_method_return(context, pincode);
+	dbus_g_method_return(context, usepincode);
 
 	return TRUE;
 }
Comment 13 Bastien Nocera 2008-11-11 17:25:26 UTC
Patches go in as attachments, and your patch's indentation is all wrong. And I'll say it again:
DISCUSSIONS ABOUT PIN CODE OPTIONS SHOULD GO ON THE MAILING-LIST.

If you want to post your patch somewhere, file a new bug.
Comment 14 Sebastian Spaeth 2008-11-12 07:59:20 UTC
As the original bug reporter I take the freedom to close this bug as invalid.
I reported the bug, but I don't own or know anything about a X3 Micro headset so it's certainly invalid from my point of view.

Bastien, I am seriously sorry that you had to endure so many comments and I wish to thank you for replying so quickly to each of them. However, hardcoding devices -separate file or not- *is* going to be a losing battle. I disagree with your judgment that these devices are broken, they have no keyboard and no display so it would be very hard to enter a random pin on them.

I agree that bugzilla is not the right place to discuss development if the developers disagree with the proposed approach and I will take up this issue in the development mailing list. Thanks for listening, see you on the list.
Comment 15 Jonathan Ernst 2008-11-13 08:12:50 UTC
I have been able to get the requested informations from the original (Ubuntu) bug reporter : 

hcitool scan
Scanning ...
    [bdaddr]    X3 micro

hcitool inq [bdaddr]
Inquiring ...
    [bdaddr]    clock offset: 0x39fc    class: 0x200404

The correct pin is 1234.
Comment 16 Bastien Nocera 2008-11-29 16:00:09 UTC
$ ./class-to-type 0x200404
Networking (LAN, Ad hoc, ...)
Telephony (Cordless telephony, Modem, Headset service, ...)
Audio/Video (headset,speaker,stereo, video display, vcr.....
	Wearable Headset Device

Headset with special handling.
Comment 17 brock 2008-12-07 07:21:24 UTC
root@greyhound:/home/brock# hcitool scan
Scanning ...
	00:0D:B5:37:A4:C2	BT-GPS-37A4C2
root@greyhound:/home/brock# hcitool inq 00:0D:B5:37:A4:C2
Inquiring ...
	00:0D:B5:37:A4:C2	clock offset: 0x0570	class: 0x001f00

Bluetooth Data Logger
Comment 18 brock 2008-12-07 07:22:16 UTC
Oops, my bad on #17 PIN = 0000
Comment 19 Jonathan Ernst 2008-12-07 12:06:45 UTC
(In reply to comment #17)
> root@greyhound:/home/brock# hcitool scan
> Scanning ...
>         00:0D:B5:37:A4:C2       BT-GPS-37A4C2


This bug is not about this device, but about the X3 Micro headset.

I have opened a Bug #563554 for your specific device.

Comment 20 Patrick Falso 2008-12-14 16:54:41 UTC
[root@bilbo-lin pfalso]# hcitool scan
Scanning ...
	00:02:5B:00:A5:A5	Pharos iGPS-BT
[root@bilbo-lin pfalso]# hcitool inq 00:02:5B:00:A5:A5
Inquiring ...
	00:02:5B:00:A5:A5	clock offset: 0x3ad2	class: 0x001f00
[root@bilbo-lin pfalso]# 

Pin = 12345678

========================================================================

[root@bilbo-lin pfalso]# hcitool scan
Scanning ...
	00:12:5A:6B:55:55	Microsoft Bluetooth Notebook Mouse 5000
[root@bilbo-lin pfalso]# hcitool inq 00:12:5A:6B:55:55
Inquiring ...
	00:12:5A:6B:55:55	clock offset: 0x21a6	class: 0x002580
[root@bilbo-lin pfalso]# 

pin = 0000
Comment 21 Jonathan Ernst 2008-12-14 18:29:09 UTC
Come on people, please take 10 seconds to read at least the last message of the bug before posting unrelated informations.

@Patrcick, please open a new bug for your specific devices, this bug is about X3 Micro Headset
Comment 22 Bastien Nocera 2009-02-25 14:51:05 UTC
Reassigning to bluez-gnome fork, gnome-bluetooth.
Comment 24 Bassem JARKAS 2009-11-27 18:06:39 UTC
I have Pharos BT GPS II which is not included in the database.
here are the information:

bassem@bassem-laptop:~$ hcitool scan
Scanning ...
	00:12:6F:00:6C:FD	Pharos BT GPS II
bassem@bassem-laptop:~$ hcitool inq 00:12:6F:00:6C:FD
Inquiring ...
	00:12:6F:00:6C:FD	clock offset: 0x57d6	class: 0x001f00
Comment 25 Bastien Nocera 2009-11-27 18:25:19 UTC
(In reply to comment #24)
> I have Pharos BT GPS II which is not included in the database.
> here are the information:
> 
> bassem@bassem-laptop:~$ hcitool scan
> Scanning ...
>     00:12:6F:00:6C:FD    Pharos BT GPS II
> bassem@bassem-laptop:~$ hcitool inq 00:12:6F:00:6C:FD
> Inquiring ...
>     00:12:6F:00:6C:FD    clock offset: 0x57d6    class: 0x001f00

Create a new bug please, this one is closed.