Hello
I have a bluetooth headset/headphones. However, I have a problem to connect to
them on one of my machines (while other two machines work well). Downgrading to
version 4.63 helps. In that case, bluetooth outputs something like this (this is
for the HSP profile, the A2DP acts similarly):
bluetoothd[19610]: State changed /org/bluez/19610/hci0/dev_00_19_7F_1B_E8_BE: HEADSET_STATE_DISCONNECTED -> HEADSET_STATE_CONNECTING
bluetoothd[19610]: link_key_request (sba=00:19:86:00:10:FE, dba=00:19:7F:1B:E8:BE)
bluetoothd[19610]: kernel auth requirements = 0x00
bluetoothd[19610]: stored link key type = 0x00
bluetoothd[19610]: adapter_get_device(00:19:7F:1B:E8:BE)
bluetoothd[19610]: Discovered Handsfree service on channel 1
bluetoothd[19610]: /org/bluez/19610/hci0/dev_00_19_7F_1B_E8_BE: Connecting to 00:19:7F:1B:E8:BE channel 1
bluetoothd[19610]: /org/bluez/19610/hci0/dev_00_19_7F_1B_E8_BE: Connected to 00:19:7F:1B:E8:BE
bluetoothd[19610]: Received AT+BRSF=24
bluetoothd[19610]: HFP HF features: "Voice recognition activation" "Remote volume control"
Then, the headphones appear in pulseaudio as a sink and I can hear sound.
While, with 4.64 or anything newer, it outputs this:
bluetoothd[23165]: State changed /org/bluez/23165/hci0/dev_00_19_7F_1B_E8_BE: HEADSET_STATE_DISCONNECTED -> HEADSET_STATE_CONNECTING
bluetoothd[23165]: link_key_request (sba=00:19:86:00:10:FE, dba=00:19:7F:1B:E8:BE)
bluetoothd[23165]: kernel auth requirements = 0x00
bluetoothd[23165]: stored link key type = 0x00
bluetoothd[23165]: adapter_get_device(00:19:7F:1B:E8:BE)
bluetoothd[23165]: Discovered Handsfree service on channel 1
bluetoothd[23165]: /org/bluez/23165/hci0/dev_00_19_7F_1B_E8_BE: Connecting to 00:19:7F:1B:E8:BE channel 1
bluetoothd[23165]: hcid_dbus_bonding_process_complete: status=00
bluetoothd[23165]: adapter_get_device(00:19:7F:1B:E8:BE)
bluetoothd[23165]: hcid_dbus_bonding_process_complete: no pending auth request # Here is really long pause, 1-2 seconds
bluetoothd[23165]: Function not implemented (38)
bluetoothd[23165]: State changed /org/bluez/23165/hci0/dev_00_19_7F_1B_E8_BE: HEADSET_STATE_CONNECTING -> HEADSET_STATE_DISCONNECTED
And nothing appears, no sound, etc.
The string "Function not implemented" is not present anywhere in bluez sources,
so it must come from something else, but I do not know what it is.
I tried bisecting the sources and it seems the problem is introduced in commit
aee26b30bbc24cde464ba1a557c2b258ddec6432 "Make BtIO default security level
MEDIUM". When I compile version with all commits up to master except this one,
it works, so this confirms my problem comes from this commit.
A wild guess is that the machines differ in which adapter they have and that
this one does not support something needed for the medium level security. The
adaptor is "OMEGA MICRO BT140", while the other two computers are laptops and
have some onboard usb connected adaptors (I do not know which ones). Is it
possible? If so, is there a possibility forcing bluez not using the
not-implemented function in a cleaner way than omitting the commit?
Thank you
--
Michal 'vorner' Vaner
Hello
On Mon, Jul 12, 2010 at 02:48:27PM +0200, Michal 'vorner' Vaner wrote:
> I have a bluetooth headset/headphones. However, I have a problem to connect to
> them on one of my machines (while other two machines work well). Downgrading to
> version 4.63 helps. In that case, bluetooth outputs something like this (this is
> for the HSP profile, the A2DP acts similarly):
>
> [ .... Deleted logs .... ]
>
> I tried bisecting the sources and it seems the problem is introduced in commit
> aee26b30bbc24cde464ba1a557c2b258ddec6432 "Make BtIO default security level
> MEDIUM". When I compile version with all commits up to master except this one,
> it works, so this confirms my problem comes from this commit.
>
> A wild guess is that the machines differ in which adapter they have and that
> this one does not support something needed for the medium level security. The
> adaptor is "OMEGA MICRO BT140", while the other two computers are laptops and
> have some onboard usb connected adaptors (I do not know which ones). Is it
> possible? If so, is there a possibility forcing bluez not using the
> not-implemented function in a cleaner way than omitting the commit?
I found out that it works with different dongle on the same computer. Is it bug
in the dongle or something that could be fixed in software too?
Thanks
--
I've already told you more than I know.
Michal 'vorner' Vaner