maemo.org Bugzilla – Bug 7849
N900 bluetooth device type is detected as "Other" and never more as "Phone" by other bluetooth devices
Last modified: 2011-10-12 17:05:46 UTC
You need to
before you can comment on or make changes to this bug.
EXACT STEPS LEADING TO PROBLEM:
1. Activate the N900 bluetooth in visible mode.
2. Pair the N900 to another bluetooth device (Windows laptop, S60 device, etc).
The N900 should be detected by the other device (windows, S60, etc) as a
PCSuite detects the N900 in bluetooth mode and connects to it.
Issuing a "hciconfig hci0 class" command in the console, the device class
should be 0x00020c
The N900 is detected as a generic bluetooth device (type "Other")
PCSuite cannot detect the N900 in bluetooth mode because it is a generic
bluetooth device, not a phone.
Issuing a "hciconfig hci0 class" command in the console, the reported device
class is 0x580000
always, however, it seems to happen since I first connected my device to a
laptop and synchronized using PCSuite (using bluetooth).
EXTRA SOFTWARE INSTALLED:
Issuing the command "hciconfig hci0 class 0x00020c" in the console, temporaly
changes the device type and the N900 is correctly identified by Windows or S60
devices and detected by the PCSuite. However, the change is not permanent and
when the N900 bluetooth module is switched off and on again, the device class
is changed to 0x580000. I think I have this problem since I first connected my
N900 to my laptop using bluetooth and synchronized to PCSuite, but I cannot be
sure. It never worked again. I have not installed any devel or test software.
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64;
Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729;
Media Center PC 6.0; OfficeLiveConnector.1.4; OfficeLivePatch.1.3; FDM)
*** Bug 7850 has been marked as a duplicate of this bug. ***
Thanks for reporting this. On 2.2009.51-1 the advertised class is 0x5a020c so
I think this is FIXED already, but I'll let Andre confirm.
In the meantime you can use /etc/bluetooth/main.conf to make your class change
(Changing summary to ASCII quotes to test the theory in bug 7854 comment 3)
Have you edited /etc/bluetooth/main.conf yourself or installed some package
that could change its contents? What is its contents now? Does it have a
different modification date than other files in /etc/bluetooth?
(In reply to comment #4)
> Have you edited /etc/bluetooth/main.conf yourself or installed some package
> that could change its contents? What is its contents now? Does it have a
> different modification date than other files in /etc/bluetooth?
I have seen in the file main.conf contents that the class is 0x00020c. However,
the device still says 0x580000 when issuing "hciconfig hci0 class". It seems
that the device does not use the value configured in that file (you can see the
post http://talk.maemo.org/showthread.php?t=40092 where I present all my
results regarding this problem). In principle, the bluetooth class was right
when I firstly connected the N900 to Win 7 (it was detected as a phone), but
after connecting to the PCSuite and synchronizing, the device class was changed
forever, no way to correct it. I have not installed any app which could change
that file ("ls -l" command returns -rw-r--r-- 1 root root 1926 Jan 1 2000
main.conf), indeed I did not know the existence of that file three days ago :)
I don't think the bug lies with the N900.
The fact that the N900 failed to identify itself as a "phone" isn't the
problem, as its capabilities exceed that of a phone. I *like* my N900 showing
up as a "computer" in Windows 7. The problem lies in PC Suite, and it expecting
the device on the other end to always name itself as a "phone", rather than
supporting a collection of bluetooth functions.
I suspect that there may be discussion on this point, consider checking the
forum thread from my comment onwards:
This looks very much like a race condition bug that took some time to finally
get fixed in BlueZ. Depending on the scheduling of bluetoothd, overall system
load and the time that HCI commands to the Bluetooth chip take to respond the
major and minor device class part of the full 3-byte class of device value
could end up being zero (the part in main.conf is the major/minor values and
the extra stuff that people see added later are the service class bits which
depend on which profiles are enabled). I'd expect the issue to be gone in the
PR1.1 release since it contains quite a recent BlueZ version.
(In reply to comment #7)
> This looks very much like a race condition bug that took some time to finally
> get fixed in BlueZ. Depending on the scheduling of bluetoothd, overall system
> load and the time that HCI commands to the Bluetooth chip take to respond the
> major and minor device class part of the full 3-byte class of device value
> could end up being zero (the part in main.conf is the major/minor values and
> the extra stuff that people see added later are the service class bits which
> depend on which profiles are enabled). I'd expect the issue to be gone in the
> PR1.1 release since it contains quite a recent BlueZ version.
The problem has not been solved in firmware 2.2009.51-1, at least for my device
(updated via WiFi, not NSU). The class is still 0x580000.
(In reply to comment #8)
> The problem has not been solved in firmware 2.2009.51-1, at least for my device
> (updated via WiFi, not NSU). The class is still 0x580000.
Oh, that sucks. Could you still experiment with a few things to see if any of
them solve the issue:
1. Toggle bluetooth off/on
2. Restart bluetoothd with "stop bluetoothd; start bluetoothd" as root
3. hciconfig hci0 reset (as root)
Even if any of the above three work it's just a temporary fix that won't
survive a reboot (but they might give some clues as to where the problem is),
so then there's the following left:
4. Install an even more recent BlueZ. We've right now got 4.60 lined up for a
future update (PR1.1 has 4.56). I'll attach the .deb files for bluez and
libbluetooth in a minute.
Created an attachment (id=1975) [details]
bluez-4.60 debian package
Created an attachment (id=1976) [details]
libbluetooth debian package for bluez-4.60
So the bluez-4.60 packages are now attached. If you have trouble installing
them because of newer library dependencies I had in my build environment that
aren't available in PR1.1 you could try the --force-depends switch to dpkg.
One more thing that came to my mind (before you attempt with a newer bluez
It might be that this config file has a class entry that overrides the one in
(In reply to comment #13)
> One more thing that came to my mind (before you attempt with a newer bluez
> stop bluetoothd
> remove /var/lib/bluetooth/*/config
> start bluetoothd
> It might be that this config file has a class entry that overrides the one in
Great, man!!! This one worked! I did not know about the existence of that
configuration. I'll reconnect again to PCSuite and make sure that nothing
changes but, by the moment, the class is correct even after rebooting
Thank you very much for the good job!!!
OK, after several tests and reboots, it seems that the problem is fixed in the
new firmware. I change the state to FIXED.
I am suffering from the same problem - my TomTom won't recognise the N900 as a
phone. I have tried deleting the /var config file but it gets recreated with a
class of 0x5a0100 if I restart bluetooth. /etc/bluetooth/main.conf has 0x0020c
in it but that is not what is reported by hciconfig hci0 class.
I am on PR1.1 but I still have the problem - am I missing a step here?
(In reply to comment #16)
> I am suffering from the same problem - my TomTom won't recognise the N900 as a
> phone. I have tried deleting the /var config file but it gets recreated with a
> class of 0x5a0100 if I restart bluetooth.
That might be because bluetoothd writes the current class to the file during
exit. I.e. stop bluetoothd *before* removing the file and start it afterwards.
I have done that. Here is a record of my output:
Nokia-N900-42-11:~# stop bluetoothd
bluetoothd (stop) running, process 3359
bluetoothd (stop) pre-stop, (main) process 3359
bluetoothd (stop) stopping, process 3359
bluetoothd (stop) killed, process 3359
bluetoothd (stop) post-stop
bluetoothd (stop) waiting
Nokia-N900-42-11:~# rm /var/lib/bluetooth/*/config
Nokia-N900-42-11:~# start bluetoothd
bluetoothd (start) waiting
bluetoothd (start) starting
bluetoothd (start) pre-start, process 3384
bluetoothd (start) spawned, process 3385
bluetoothd (start) post-start, (main) process 3385
bluetoothd (start) running, process 3385
Nokia-N900-42-11:~# hciconfig hci0 reset
Nokia-N900-42-11:~# hciconfig hci0 class
hci0: Type: UART
BD Address: 00:BD:3A:AC:A0:6C ACL MTU: 1017:4 SCO MTU: 64:1
Service Classes: Networking, Capturing, Object Transfer, Telephony
Device Class: Computer, Uncategorized
The prompt implies that I am on the old firmware version but the about screen
confirms that I have updated to "2.2009.51-1.203.2"
Is there a definitive way of getting the firmware version from the command
Hmm... I am with Peter here. I tried the described steps and whatever I do, the
class remains "0x5a0100"(!). I even installed the 4.60 packages, but still no
I noticed the problem while trying the n900isyncplugin. After a fresh reflash
of the latest PR1.1 firmware the N900 is detected as smartphone, but after
installing a bunch of extras / devel packages it is detected as "computer",
which breaks the isync. I know that I am on my own with devel packages, but I
could use some hints where to look for this problem.
I just tried this:
name Nokia N900
Please reopen this bug.
I had the same issue. After installing pc-conneytivity-manager.
Now I have back a:
Service Classes: Networking, Capturing, Object Transfer, Telephony
Device Class: Phone, Smart phone
Here's what I did:
At first I removed the connectivity manager package in the application manager.
Then I did apt-get autoremove in a root-shell.
Then I discovered the issue with the wrong class. ;-)
Then I tried much things but I think I got the trick:
In /etc/bluetooth/main.conf I changed "#DisablePlugins = network,input,hal" in:
DisablePlugins = network,input,hal (see http://wiki.maemo.org/Bluetooth)
This is very important!!
Btw. hciconfig hci0 class does not work if bluetooth is disabled.
I hope I did not miss something in this post. - It's already quite late here..
I'm still suffering with this on pr1.3.
As soon as I restart bluetoothd, the class goes back to 0x5a0100. I have a
second N900 on pr1.3 which doesn't have this problem, and the /etc/bluetooth
directories are identical.
Removing /var/lib/bluetooth/*/config has no effect - when it's recreated it is
given the incorrect value of 0x510100, *not* 0x51020c.
(In reply to comment #21)
> I'm still suffering with this on pr1.3.
> As soon as I restart bluetoothd, the class goes back to 0x5a0100. I have a
> second N900 on pr1.3 which doesn't have this problem, and the /etc/bluetooth
> directories are identical.
> Removing /var/lib/bluetooth/*/config has no effect - when it's recreated it is
> given the incorrect value of 0x510100, *not* 0x51020c.
D'oh. Sorry guys - they weren't identical, I'd uncommented the disabled plugins
line in main.conf, and it's the 'hal' plugin that was causing this issue.
Sorry for the noise!
Can this be re-opened? I'm on 1.3 and I still suffer this problem. I followed
all the instructions here, but the class still remains stuck on 0x58020c.
Even when I force it with "hciconfig hci0 class 0x51020c", Nokia PC Suite still
doesn't see my N900.
The N900 appears as "Desktop" in Windows XP.
Until recently, the synchronization over Bluetooth worked fine. I don't know
the exact moment when it stopped working, because I had it on automatic
synchronisation and I didn't notice the problem immediately.
Synchronization over USB with Nokia PC Suite still works. Re-flashing the N900
is not something I want to do. Nor do I want to switch to Ovi Suite, which is
even worse than Nokia PC Suite.
(In reply to comment #23)
> Can this be re-opened? I'm on 1.3 and I still suffer this problem.
Feel free to file a new report, however as Nokia does not really work on Maemo
anymore I don't think that it makes any difference.