Bug 7849 - N900 bluetooth device type is detected as "Other" and never more as "Phone" by other bluetooth devices
: N900 bluetooth device type is detected as "Other" and never more as "Phone" b...
Status: RESOLVED FIXED
Product: Connectivity
Bluetooth
: 5.0/(1.2009.44-1)
: N900 Maemo
: Low major with 1 vote (vote)
: 5.0/(2.2009.51-1)
Assigned To: unassigned
: bluetooth-bugs
:
:
:
:
  Show dependency tree
 
Reported: 2010-01-12 13:14 UTC by Iker
Modified: 2011-10-12 17:05 UTC (History)
9 users (show)

See Also:


Attachments
bluez-4.60 debian package (376.38 KB, application/x-deb)
2010-01-14 19:10 UTC, Johan Hedberg
Details
libbluetooth debian package for bluez-4.60 (65.74 KB, application/x-deb)
2010-01-14 19:11 UTC, Johan Hedberg
Details


Note

You need to log in before you can comment on or make changes to this bug.


Description Iker (reporter) 2010-01-12 13:14:36 UTC
SOFTWARE VERSION:
1.2009.44-1

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).

EXPECTED OUTCOME:
The N900 should be detected by the other device (windows, S60, etc) as a
bluetooth "Phone"
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

ACTUAL OUTCOME:
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

REPRODUCIBILITY:
always, however, it seems to happen since I first connected my device to a
laptop and synchronized using PCSuite (using bluetooth).

EXTRA SOFTWARE INSTALLED:
FMRadio, Petrovich.

OTHER COMMENTS:
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)
Comment 1 Iker (reporter) 2010-01-12 13:20:48 UTC
*** Bug 7850 has been marked as a duplicate of this bug. ***
Comment 2 Lucas Maneos 2010-01-13 02:08:53 UTC
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
more permanent.
Comment 3 Lucas Maneos 2010-01-13 02:29:38 UTC
(Changing summary to ASCII quotes to test the theory in bug 7854 comment 3)
Comment 4 Johan Hedberg nokia 2010-01-13 07:13:04 UTC
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?
Comment 5 Iker (reporter) 2010-01-13 12:19:05 UTC
(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 :)

Best regards.
Comment 6 Alan Peery 2010-01-13 13:06:37 UTC
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:
http://talk.maemo.org/showpost.php?p=468084&postcount=19.
Comment 7 Johan Hedberg nokia 2010-01-13 13:40:45 UTC
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.
Comment 8 Iker (reporter) 2010-01-14 18:32:49 UTC
(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.
Comment 9 Johan Hedberg nokia 2010-01-14 19:09:15 UTC
(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.
Comment 10 Johan Hedberg nokia 2010-01-14 19:10:35 UTC
Created an attachment (id=1975) [details]
bluez-4.60 debian package
Comment 11 Johan Hedberg nokia 2010-01-14 19:11:10 UTC
Created an attachment (id=1976) [details]
libbluetooth debian package for bluez-4.60
Comment 12 Johan Hedberg nokia 2010-01-14 19:12:58 UTC
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.
Comment 13 Johan Hedberg nokia 2010-01-14 19:17:48 UTC
One more thing that came to my mind (before you attempt with a newer bluez
version):

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
main.conf.
Comment 14 Iker (reporter) 2010-01-14 19:53:55 UTC
(In reply to comment #13)
> One more thing that came to my mind (before you attempt with a newer bluez
> version):
> 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
> main.conf.

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
(0x58020c).

Thank you very much for the good job!!!
Comment 15 Iker (reporter) 2010-01-14 20:11:13 UTC
OK, after several tests and reboots, it seems that the problem is fixed in the
new firmware. I change the state to FIXED.
Comment 16 Peter T 2010-01-15 00:31:04 UTC
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?

Rgrds

Peter
Comment 17 Johan Hedberg nokia 2010-01-15 09:11:43 UTC
(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.
Comment 18 Peter T 2010-01-22 00:06:55 UTC
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
        Class: 0x5a0100
        Service Classes: Networking, Capturing, Object Transfer, Telephony
        Device Class: Computer, Uncategorized
Nokia-N900-42-11:~#


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
line?

Rgrds

Peter
Comment 19 Rolf Offermanns 2010-02-01 15:32:01 UTC
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
success.

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:
stop bluetoothd
rm /var/lib/bluetooth/*/config
reboot
Enable Bluetooth
cat /var/lib/bluetooth/*/config:
onmode discoverable
mode discoverable
name Nokia N900
class 0x5a0100

Please reopen this bug.
Comment 20 Mario Hock 2010-02-21 05:18:15 UTC
I had the same issue. After installing pc-conneytivity-manager.
Now I have back a:
    Class: 0x5a020c
    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:
(stop bluetoothd)
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!!

rm /var/lib/bluetooth/*/config
(start bluetoothd)

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..
Comment 21 Jamie Thompson 2011-01-12 02:09:04 UTC
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.
Comment 22 Jamie Thompson 2011-01-12 02:47:39 UTC
(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!
Comment 23 Sebastian 2011-10-12 17:04:48 UTC
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.
Comment 24 Andre Klapper maemo.org 2011-10-12 17:05:46 UTC
(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.