GNOME Bugzilla – Bug 560315
X3 Micro headset can't pair
Last modified: 2009-11-27 18:25:19 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:
*** Bug 560316 has been marked as a duplicate of this bug. ***
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).
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?
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
(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.
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.
(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).
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.
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.
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.
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.
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; }
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.
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.
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.
$ ./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.
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
Oops, my bad on #17 PIN = 0000
(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.
[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
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
Reassigning to bluez-gnome fork, gnome-bluetooth.
X3 micro fixed in gnome-bluetooth: http://svn.gnome.org/viewvc/gnome-bluetooth?view=revision&revision=319 Pharos GPS fixed in: http://svn.gnome.org/viewvc/gnome-bluetooth?view=revision&revision=362
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
(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.