From: Fabian Greffrath <fabian@greffrath.com>
To: linux-bluetooth@vger.kernel.org
Subject: Detect invalid (i.e. non-UTF-8) device names and fix them during initialization phase
Date: Wed, 05 May 2010 12:11:36 +0200 [thread overview]
Message-ID: <4BE14458.1020908@greffrath.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 1822 bytes --]
Dear Bluez developers,
recently I have experienced a problem with one of my USB bluetooth
dongles: Whenever I plugged it into an USB port, the kernel detected
the device (i.e. reasonable output in dmesg) and the correct kernel
module (i.e. btusb) was loaded, but bluez frontends like
gnome-bluetooth could still not activate the device. The bug that I
reported against this software can be found at:
<https://bugzilla.gnome.org/show_bug.cgi?id=617050>.
It turned out that my USB dongle was the culprit, since it had an
invalid default device name that contained non-UTF-8 characters, as
reported by 'hciconfig -a'. When I changed the device name to
something reasonable via e.g. 'hciconfig hci0 name foobar', I had to
*restart* the bluetoothd daemon afterwards in order to get everything
working as expected. However, when I unplugged the USB dongle and
plugged it back in, the device name was reset to the defective default
again and I had to repeat this procedure.
Since I found it unreasonable to be forced to manually change the
device name and restart the daemon each and every time I plugged my
USB dongle in, I wanted a solution that detected a faulty device name
string during the device initialization phase and instantly fixed it
by writing a converted string back to the device. The attached patch
does exact this and makes my USB dongle work out-of-the-box, despite
its defective default device name.
Please review the patch for integration into Bluez.
Cheers,
Fabian
PS: There is still one open question that I would like to address:
Since I am going to print both the faulty and the fixed device name
strings to stderr via debug(), should I make sure the strings do not
contain any ASCII control characters prior to that? At least this is
what is done in tools/hciconfig.c:442.
[-- Attachment #2: fix_invalid_non-utf-8_device_name.patch --]
[-- Type: text/x-diff, Size: 1064 bytes --]
--- bluez-4.64.orig/plugins/hciops.c
+++ bluez-4.64/plugins/hciops.c
@@ -119,6 +119,7 @@ static void init_device(int index)
struct hci_dev_info di;
pid_t pid;
int dd, err;
+ char name[249];
/* Do initialization in the separate process */
pid = fork();
@@ -143,6 +144,30 @@ static void init_device(int index)
exit(1);
}
+ if (hci_read_local_name(dd, sizeof(name), name, 1000) < 0) {
+ error("Can't read local name on hci%d: %s (%d)\n",
+ index, strerror(errno), errno);
+ exit(1);
+ }
+
+ name[248] = '\0';
+
+ if (!g_utf8_validate(name, -1, NULL)) {
+ char *utf8_name;
+
+ utf8_name = g_convert(name, -1, "UTF-8", "ISO-8859-1", NULL, NULL, NULL);
+ if (utf8_name) {
+ debug("Fix invalid non-UTF-8 device name \"%s\" on hci%d to \"%s\"",
+ name, index, utf8_name);
+ if (hci_write_local_name(dd, utf8_name, 2000) < 0) {
+ error("Can't change local name on hci%d: %s (%d)\n",
+ index, strerror(errno), errno);
+ exit(1);
+ }
+ g_free(utf8_name);
+ }
+ }
+
memset(&dr, 0, sizeof(dr));
dr.dev_id = index;
next reply other threads:[~2010-05-05 10:11 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-05 10:11 Fabian Greffrath [this message]
2010-05-05 10:27 ` Detect invalid (i.e. non-UTF-8) device names and fix them during initialization phase Fabian Greffrath
2010-05-05 15:02 ` Stefan Seyfried
2010-05-05 15:14 ` Fabian Greffrath
2010-05-06 14:42 ` Fabian Greffrath
2010-05-06 15:03 ` Johan Hedberg
2010-05-17 8:39 ` [PATCH] Instantly fix non-UTF-8 local device names during device configuration phase Fabian Greffrath
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4BE14458.1020908@greffrath.com \
--to=fabian@greffrath.com \
--cc=linux-bluetooth@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.