[bugreport]

[bugreport]

[Serhiy Kachaniuk]

Hi!

My USB bluetooth adapter stopped working with new versions of bluez.
Latest version which works is 4.32.
I initially reported bug for ubuntu package in launchpad here
https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/453885 , but then
i tried also opensuse livecd and problem remained there too, so looks
like it's not ubuntu specific.
jhe at #bluez-devel suggested to me to collect hcidump output on
bluetoothd startup, and then write to this mailinglist. I attached
suggested hcidumps for bluez versions 4.64 and 4.32, and looks like
4.64 stops initialization process after it cannot read parameter
'Default Link Policy Settings' from device.

Can you please take a look at this bug?
Thanks in advance.

Re: [bugreport]

[Fabian Greffrath]

Am 06.05.2010 07:22, schrieb Serhiy Kachaniuk:
> My USB bluetooth adapter stopped working with new versions of bluez.
> Latest version which works is 4.32.
> I initially reported bug for ubuntu package in launchpad here
> https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/453885 , but then
> i tried also opensuse livecd and problem remained there too, so looks
> like it's not ubuntu specific.

Could you please post the output of 'sudo hciconfig -a'? I am 
especially interested in the Name part.

Re: [bugreport]

[Serhiy Kachaniuk]

2010/5/6 Fabian Greffrath:
> Could you please post the output of 'sudo hciconfig -a'? I am especially
> interested in the Name part.
>
For bluez version 4.60 (I'm at work now, i have 4.64 version only at home):
hci0:   Type: USB
       BD Address: 00:1A:7D:0A:C8:8A ACL MTU: 377:10 SCO MTU: 16:0
       UP RUNNING
       RX bytes:664 acl:0 sco:0 events:18 errors:0
       TX bytes:73 acl:0 sco:0 commands:19 errors:0
       Features: 0xff 0xff 0x0d 0x38 0x08 0x08 0x00 0x00
       Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
       Link policy:
       Link mode: SLAVE ACCEPT
Can't read local name on hci0: Connection timed out (110)

And for 4.32:
hci0:   Type: USB
       BD Address: 00:1A:7D:0A:C8:8A ACL MTU: 377:10 SCO MTU: 16:0
       UP RUNNING PSCAN
       RX bytes:1362 acl:0 sco:0 events:46 errors:0
       TX bytes:693 acl:0 sco:0 commands:47 errors:0
       Features: 0xff 0xff 0x0d 0x38 0x08 0x08 0x00 0x00
       Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
       Link policy:
       Link mode: SLAVE ACCEPT
       Name: 'Broadcom BCM2035'
       Class: 0x0a0100
       Service Classes: Networking, Capturing
       Device Class: Computer, Uncategorized
       HCI Ver: 1.1 (0x1) HCI Rev: 0x3 LMP Ver: 1.1 (0x1) LMP Subver: 0x800
       Manufacturer: Broadcom Corporation (15)

Re: [bugreport]

[Serhiy Kachaniuk]

2010/5/6 Fabian Greffrath:
> Could you please post the output of 'sudo hciconfig -a'? I am especially
> interested in the Name part.
>
Interesting moment: when run without sudo with version 4.60 it shows
name, but prints error on getting class of device:

hci0:   Type: USB
        BD Address: 00:1A:7D:0A:C8:8A ACL MTU: 377:10 SCO MTU: 16:0
        UP RUNNING
        RX bytes:3059 acl:0 sco:0 events:70 errors:0
        TX bytes:797 acl:0 sco:0 commands:75 errors:0
        Features: 0xff 0xff 0x0d 0x38 0x08 0x08 0x00 0x00
        Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
        Link policy:
        Link mode: SLAVE ACCEPT
        Name: 'Broadcom BCM2035'
Can't read class of device on hci0: Connection timed out (110)

Re: [bugreport]

[Fabian Greffrath]

Am 06.05.2010 12:01, schrieb Serhiy Kachaniuk:
> Interesting moment: when run without sudo with version 4.60 it shows
> name, but prints error on getting class of device:

Maybe a stupid question, but do you have an application like GNOME's 
bluetooth applet running (that keeps the shared lib in memory) while 
switching bluez versions?

Re: [bugreport]

[Bastien Nocera]

On Thu, 2010-05-06 at 12:05 +0200, Fabian Greffrath wrote:
> Am 06.05.2010 12:01, schrieb Serhiy Kachaniuk:
> > Interesting moment: when run without sudo with version 4.60 it shows
> > name, but prints error on getting class of device:
> 
> Maybe a stupid question, but do you have an application like GNOME's 
> bluetooth applet running (that keeps the shared lib in memory) while 
> switching bluez versions?

gnome-bluetooth doesn't use libbluetooth, and a newly started app would
be using the library that's on disk anyway, not the one in memory if
they were different (you could see that in lsof which would show an
older running application as using the library with a "(deleted)"
comment).

Re: [bugreport]

[Serhiy Kachaniuk]

2010/5/6 Fabian Greffrath:
> Maybe a stupid question, but do you have an application like GNOME's
> bluetooth applet running (that keeps the shared lib in memory) while
> switching bluez versions?
>
Yeah, kbluetooth was running, but switching bluez version implies
bluetoothd restart.
Anyway, here is what i get after terminating kbluetooth and manually
stopping and starting bluetoothd:

First run without sudo:

$ hciconfig -a
hci0:   Type: USB
        BD Address: 00:1A:7D:0A:C8:8A ACL MTU: 377:10 SCO MTU: 16:0
        UP RUNNING
        RX bytes:664 acl:0 sco:0 events:18 errors:0
        TX bytes:73 acl:0 sco:0 commands:19 errors:0
        Features: 0xff 0xff 0x0d 0x38 0x08 0x08 0x00 0x00
        Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
        Link policy:
        Link mode: SLAVE ACCEPT
Can't read local name on hci0: Connection timed out (110)

Second run without sudo:

$ hciconfig -a
hci0:   Type: USB
        BD Address: 00:1A:7D:0A:C8:8A ACL MTU: 377:10 SCO MTU: 16:0
        UP RUNNING
        RX bytes:664 acl:0 sco:0 events:18 errors:0
        TX bytes:77 acl:0 sco:0 commands:20 errors:0
        Features: 0xff 0xff 0x0d 0x38 0x08 0x08 0x00 0x00
        Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
        Link policy:
        Link mode: SLAVE ACCEPT
Can't read local name on hci0: Connection timed out (110)

Third run without sudo, and 'Name:' appears:

$ hciconfig -a
hci0:   Type: USB
        BD Address: 00:1A:7D:0A:C8:8A ACL MTU: 377:10 SCO MTU: 16:0
        UP RUNNING
        RX bytes:664 acl:0 sco:0 events:18 errors:0
        TX bytes:83 acl:0 sco:0 commands:21 errors:0
        Features: 0xff 0xff 0x0d 0x38 0x08 0x08 0x00 0x00
        Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
        Link policy:
        Link mode: SLAVE ACCEPT
        Name: 'Broadcom BCM2035'
Can't read class of device on hci0: Connection timed out (110)


Same result with sudo: first one or two runs didn't get name, but later did

Re: [bugreport]

[Fabian Greffrath]

Am 06.05.2010 12:11, schrieb Bastien Nocera:
> gnome-bluetooth doesn't use libbluetooth, and a newly started app would
> be using the library that's on disk anyway, not the one in memory if
> they were different (you could see that in lsof which would show an
> older running application as using the library with a "(deleted)"
> comment).

Alright, thanks for the clarification. ;)

Re: [bugreport]

[Serhiy Kachaniuk]

2010/5/6 Fabian Greffrath:
> Next stupid question: You know that your adapter requires the
> "bluez-firmware" package?
>

Hum, ubuntu doesn't have such a package, and with bluez 4.32 this
dongle works ok without it... But i can try to install it from
sources.

Re: [bugreport]

[Fabian Greffrath]

Am 06.05.2010 12:32, schrieb Serhiy Kachaniuk:
> Hum, ubuntu doesn't have such a package, and with bluez 4.32 this
> dongle works ok without it... But i can try to install it from
> sources.

There is a Debian package, maybe you should try it out:
<http://packages.debian.org/sid/bluez-firmware>

Re: [bugreport]

[Serhiy Kachaniuk]

2010/5/6 Fabian Greffrath:
> There is a Debian package, maybe you should try it out:
> <http://packages.debian.org/sid/bluez-firmware>
>
Installed it, but no change :(
package installs this files:
/lib/firmware/BCM2033-MD.hex
/lib/firmware/BCM2033-FW.bin
/lib/firmware/STLC2500_R4_00_03.ptc
/lib/firmware/STLC2500_R4_00_06.ssf
/lib/firmware/STLC2500_R4_02_02_WLAN.ssf
/lib/firmware/STLC2500_R4_02_04.ptc

but my adapter's name is Broadcom BCM2035, not BCM2033

Re: [bugreport]

[Serhiy Kachaniuk]

Another interesting discovery: when bluetoothd is stopped and bluez
version is 4.60, hciconfig can show all info and i can scan for
another devices:

$ sudo hciconfig -a
hci0:   Type: USB
        BD Address: 00:1A:7D:0A:C8:8A ACL MTU: 377:10 SCO MTU: 16:0
        UP RUNNING
        RX bytes:1012 acl:0 sco:0 events:29 errors:0
        TX bytes:114 acl:0 sco:0 commands:31 errors:0
        Features: 0xff 0xff 0x0d 0x38 0x08 0x08 0x00 0x00
        Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
        Link policy:
        Link mode: SLAVE ACCEPT
        Name: 'Broadcom BCM2035'
        Class: 0x000000
        Service Classes: Unspecified
        Device Class: Miscellaneous,
        HCI Ver: 1.1 (0x1) HCI Rev: 0x3 LMP Ver: 1.1 (0x1) LMP Subver: 0x800
        Manufacturer: Broadcom Corporation (15)

$ hcitool scan
Scanning ...
        00:1E:DC:9B:FF:C4       HBH-DS205

but afer bluetoothd start problem reappears, hciconfig doesn't show
all info and hcitool scan fails

Re: [bugreport]

[Serhiy Kachaniuk]

2010/5/6 Serhiy Kachaniuk <serzholino@gmail.com>:
> Hi!
>
> My USB bluetooth adapter stopped working with new versions of bluez.
> Latest version which works is 4.32.
> I initially reported bug for ubuntu package in launchpad here
> https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/453885 , but then
> i tried also opensuse livecd and problem remained there too, so looks
> like it's not ubuntu specific.
> jhe at #bluez-devel suggested to me to collect hcidump output on
> bluetoothd startup, and then write to this mailinglist. I attached
> suggested hcidumps for bluez versions 4.64 and 4.32, and looks like
> 4.64 stops initialization process after it cannot read parameter
> 'Default Link Policy Settings' from device.
>
> Can you please take a look at this bug?
> Thanks in advance.
>

Can someone turn this e-mail thread into bluez bugreport? If i
understand correctly, only developers can create bluez bugreports in
trac? Also, if you need any more debugging info, i would be glad to
provide you with any.

Re: [bugreport]

[Vinicius Gomes]

Hi Serhiy,

On Tue, May 11, 2010 at 10:06 AM, Serhiy Kachaniuk <serzholino@gmail.com> wrote:
> 2010/5/6 Serhiy Kachaniuk <serzholino@gmail.com>:
>> Hi!
>>
>> My USB bluetooth adapter stopped working with new versions of bluez.
>> Latest version which works is 4.32.
>> I initially reported bug for ubuntu package in launchpad here
>> https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/453885 , but then
>> i tried also opensuse livecd and problem remained there too, so looks
>> like it's not ubuntu specific.
>> jhe at #bluez-devel suggested to me to collect hcidump output on
>> bluetoothd startup, and then write to this mailinglist. I attached
>> suggested hcidumps for bluez versions 4.64 and 4.32, and looks like
>> 4.64 stops initialization process after it cannot read parameter
>> 'Default Link Policy Settings' from device.
>>
>> Can you please take a look at this bug?
>> Thanks in advance.
>>
>
> Can someone turn this e-mail thread into bluez bugreport? If i
> understand correctly, only developers can create bluez bugreports in
> trac? Also, if you need any more debugging info, i would be glad to
> provide you with any.

This (the mailing list) is the correct place for bug reports.

Someone here in the office has an ancient Bluetooth 1.2 dongle, which
shows a similar problem. Now that you discovered that it is probably a
regression and I can reproduce it, I will try to debug it.

And it looks like that the hcidump logs that you attached in your
first email got lost somehow.

Anyway, I think that the only information missing is your kernel version.


Cheers,
-- 
Vinicius

Re: [bugreport]

[Iain Hibbert]

Serhiy, from your message on the ubuntu bug report

> Maybe the reason is that this dongle doesn't support reading/writing of
> 'Default Link Policy Settings' ?

and this command was introduced in spec version 1.2, and your device
reports

>        HCI Ver: 1.1 (0x1) HCI Rev: 0x3 LMP Ver: 1.1 (0x1) LMP Subver: 0x800

so yes, that is likely the problem as it is too old.

That bluez has no handling for the possibility that the command may not be
supported is possibly a bug or possibly an indication that older devices
are no longer to be supported, I can't really say which.

regards,
iain

Re: [bugreport]

[Serhiy Kachaniuk]

2010/5/11 Vinicius Gomes :
> This (the mailing list) is the correct place for bug reports.
>
> Someone here in the office has an ancient Bluetooth 1.2 dongle, which
> shows a similar problem. Now that you discovered that it is probably a
> regression and I can reproduce it, I will try to debug it.
>
> And it looks like that the hcidump logs that you attached in your
> first email got lost somehow.
They're attached to bugreport on launchpad
for bluez version 4.64 http://launchpadlibrarian.net/47890286/hcidump.txt
for bluez version 4.32 http://launchpadlibrarian.net/47890843/hcidump_old.txt
>
> Anyway, I think that the only information missing is your kernel version.

Kernel version seems irrelevant. Anyway, first version, when i
discovered this problem was 2.6.31. Now i use 2.6.32 and problem
persists.

Re: [bugreport]

[Serhiy Kachaniuk]

2010/5/11 Iain Hibbert:
>
> Serhiy, from your message on the ubuntu bug report
>
>> Maybe the reason is that this dongle doesn't support reading/writing of
>> 'Default Link Policy Settings' ?
>
> and this command was introduced in spec version 1.2, and your device
> reports
>
>>        HCI Ver: 1.1 (0x1) HCI Rev: 0x3 LMP Ver: 1.1 (0x1) LMP Subver: 0x800
>
> so yes, that is likely the problem as it is too old.
>
> That bluez has no handling for the possibility that the command may not be
> supported is possibly a bug or possibly an indication that older devices
> are no longer to be supported, I can't really say which.
>
Yeah, i see that this device is a little buggy, but it worked in
previous version of bluez, so maybe it is possible to make it work
again for current version?

Re: [bugreport]

[Iain Hibbert]

On Tue, 11 May 2010, Serhiy Kachaniuk wrote:

> Yeah, i see that this device is a little buggy, but it worked in
> previous version of bluez, so maybe it is possible to make it work
> again for current version?

I think the problem may be that the kernel itself now relies on setting
the default link policy before accepting connections, so that the link
policy does not need to be set after the connection is complete and there
will be no window of uncertainty.

I am only an observer here, and don't know if this has been done with the
conscious knowledge that older devices will no longer work or if it was a
mistake..  but I can suggest that Bluetooth dongles are cheap, and you
will likely find better connectivity with a 2.x + EDR device anyway..

regards,
iain