I'd like to provide some feedback regarding a Samsung WEP475 headset
which fails to connect to linux specifically.
The USB bluetooth adapter is a Model: Belkin BLUETOOTH USB +EDR ADAPTER
v2.1 UHE which successfully interconnects with 2 Jabra and 1 Plantronics
headsets, plus a Nokia E71 phone. Samsung WEP475 successfully connects
to a Windows XP machine and to the Nokia E71.
Using Opensuse 11.4 with custom kernel 3.0 currently, (also fails with
2.6.38), bluez 4.96 and bluedevil manager.
Symptoms are that bluedevil sees the headset in pairing mode and
correctly retrieves the name WEP475, connected button flashes green and
then returns to grey (not connected). WEP475 led changes to connected
status but bluedevil shows headset not connected and headset does not work.
With bluetoothd in debug mode, I get the following transactions in
/var/log/messages:
Aug 4 06:22:51 linux-xxxx bluetoothd[13227]:
plugins/hciops.c:conn_complete() status 0x00
Aug 4 06:22:51 linux-xxxx bluetoothd[13227]:
src/adapter.c:adapter_get_device() 00:---:47
Aug 4 06:22:51 linux-xxxx bluetoothd[13227]:
plugins/hciops.c:remote_features_information() hci0 status 0
Aug 4 06:22:51 linux-xxxx bluetoothd[13227]:
plugins/hciops.c:remote_name_information() hci0 status 0
Aug 4 06:22:51 linux-xxxx bluetoothd[13227]:
audio/headset.c:headset_set_channel() Discovered Handsfree service on
channel 2
Aug 4 06:22:51 linux-xxxx bluetoothd[13227]:
audio/headset.c:rfcomm_connect() /org/bluez/13226/hci0/dev_00_---_47:
Connecting to 00:---:47 channel 2
Aug 4 06:22:51 linux-xxxx bluetoothd[13227]:
plugins/hciops.c:link_key_request() hci0 dba 00:---:47
Aug 4 06:22:51 linux-xxxx bluetoothd[13227]:
plugins/hciops.c:get_auth_info() hci0 dba 00:---:47
Aug 4 06:22:51 linux-xxxx bluetoothd[13227]:
plugins/hciops.c:link_key_request() kernel auth requirements = 0x04
Aug 4 06:22:51 linux-xxxx bluetoothd[13227]:
plugins/hciops.c:link_key_request() Matching key found
Aug 4 06:22:51 linux-xxxx bluetoothd[13227]:
plugins/hciops.c:link_key_request() link key type 0x04
Aug 4 06:22:51 linux-xxxx bluetoothd[13227]:
plugins/hciops.c:auth_complete() hci0 status 0
Aug 4 06:22:51 linux-xxxx bluetoothd[13227]:
plugins/hciops.c:bonding_complete() status 0x00
Aug 4 06:22:51 linux-xxxx bluetoothd[13227]:
src/event.c:btd_event_bonding_complete() status 0x00
Aug 4 06:22:51 linux-xxxx bluetoothd[13227]:
src/adapter.c:adapter_get_device() 00:---:47
Aug 4 06:22:51 linux-xxxx bluetoothd[13227]:
src/device.c:device_bonding_complete() bonding (nil) status 0x00
Aug 4 06:22:52 linux-xxxx bluetoothd[13227]: Permission denied (13)
Aug 4 06:22:52 linux-xxxx bluetoothd[13227]:
audio/headset.c:headset_set_state() State changed
/org/bluez/13226/hci0/dev_00_---_47: HEADSET_STATE_CONNECTING ->
HEADSET_STATE_DISCONNECTED
Aug 4 06:22:52 linux-xxxx bluetoothd[13227]:
plugins/hciops.c:disconn_complete() handle 11 status 0x00
Aug 4 06:22:52 linux-xxxx bluetoothd[13227]:
src/event.c:btd_event_disconn_complete()
Aug 4 06:22:52 linux-xxxx bluetoothd[13227]:
src/adapter.c:adapter_remove_connection()
I have tried clearing the contents of /var/lib/bluetooth/ forcing the
system to recreate, but no difference.
--
---
Colin Beckingham
On 08/08/2011 09:53 AM, Peter Hurley wrote:
> On Mon, 2011-08-08 at 09:31 -0400, Colin Beckingham wrote:
>>
>> On 08/08/2011 08:38 AM, Peter Hurley wrote:
>>> On Sat, 2011-08-06 at 13:22 -0400, Colin Beckingham wrote:
>>>> On 08/06/2011 12:50 PM, Peter Hurley wrote:
>>>>> On Sat, 2011-08-06 at 11:33 -0400, Colin Beckingham wrote:
>>>>>> Hi Peter:
>>>>>>
>>>>> ...<snip>...
>>>>>> I ran # hciconfig hci0 sspmode 1 to force the adapter into a secure attempt.
>>>>>>
>>>>>> I downloaded and installed the latest hcidump which identifies itself
>>>>>> (hcidump -v) as 2.0 even though it is marked as 2.1 version on the webpage.
>>>>>>
>>>>>> Made another attempt to connect, here is the syslog
>>>>>>
>>>>>> # tail -n 100 /var/log/messages | grep bluetoothd
>>>>>> Aug 6 05:15:39 linux-c96h bluetoothd[1246]: Audio connection got
>>>>>> disconnected
>>>>>> Aug 6 11:23:29 linux-c96h bluetoothd[1246]: Rejecting request: remote
>>>>>> device can't provide MITM
>>>>>> Aug 6 11:23:56 linux-c96h bluetoothd[1246]: Discovery session
>>>>>> 0x7f801d0a6ca0 with :1.4178 activated
>>>>>> Aug 6 11:24:01 linux-c96h bluetoothd[1246]: Stopping discovery
>>>>>> Aug 6 11:24:13 linux-c96h bluetoothd[1246]: Permission denied (13)
>>>>>>
>>>>>> and a binary hcidump is attached.
>>>>>
>>>>> Hi Colin,
>>>>>
>>>>> That makes a lot more sense!
>>>>>
>>>>> Would you please repeat the experiment with bluetoothd in debug mode,
>>>>> though? That would give me a lot more information to work with about how
>>>>> bluetoothd got to that point.
>>>>>
>>>>> As before, please capture hcidump binary at the same time. Also please
>>>>> include every bluetoothd syslog message starting from the start of the
>>>>> experiment.
>>>>>
>>>>> I appreciate your patience helping me to track down this bug.
>>>>>
>>>>> Regards,
>>>>> Peter Hurley
>>>>
>>>> Sorry, forgot to set bluetoothd in debug mode.
>>>>
>>>> Attached are my latest logs, 2 files, wep475a.*. Note in the syslog that
>>>> the first entry is timestamped way before the experiment was launched,
>>>> so the log should have everything that bluetoothd wrote for the current
>>>> experiment.
>>>
>>> Hi Colin,
>>>
>>> Well, the new logs did not recreate the "Rejecting request: remote
>>> device can't provide MITM". However, they did show 2 things:
>>>
>>> 1. The host controller has a race condition bug which has been seen
>>> before (see this thread
>>> http://comments.gmane.org/gmane.linux.bluez.kernel/14286 for the really
>>> technical discussion)
>>>
>>> That's why the initial attempt by the device at connecting an RFCOMM
>>> channel is rejected (@ 13:13:02.533713).
>>>
>>> Nevertheless, the headset is found anyway and Bluez connects to the
>>> headset. After establishing an insecure SDP link, Bluez attempts to open
>>> an RFCOMM channel to the device, and
>>>
>>> 2. the kernel attempts to connect the RFCOMM channel prior to the link
>>> being encrypted, so the device rejects the connection.
>>>
>>> There were some last minute changes to 3.0 final that directly impacts
>>> how this is supposed to work. However, even with those changes it's
>>> unclear to me how #2 is happening.
>>>
>>> Would you be willing to run the same experiment as before but with the
>>> kernel bluetooth module enabled for debug output? If your kernel is
>>> configured for dynamic debug (Kernel hacking/Enable dynamic printk()
>>> support => Y), doing this is trivial:
>>> # sudo su
>>> # echo -n "module bluetooth +p"
>>> > /sys/kernel/debug/dynamic_debug/control
>>> < perform experiment>
>>> # echo -n "module bluetooth -p"
>>> > /sys/kernel/debug/dynamic_debug/control
>>>
>>> Regards,
>>> Peter Hurley
>>
>> Peter, before I do this, let me just verify that my kernel is set up
>> right. I checked for dynamic printk and I am not clear that I have the
>> setting needed. Here is what my .config tells me for dynamic and printk
>> separately.
>>
>> > cat .config | grep DYNAMIC
>> CONFIG_NETCONSOLE_DYNAMIC=y
>> CONFIG_DVB_DYNAMIC_MINORS=y
>> CONFIG_SND_DYNAMIC_MINORS=y
>> # CONFIG_USB_DYNAMIC_MINORS is not set
>> CONFIG_HAVE_DYNAMIC_FTRACE=y
>> CONFIG_DYNAMIC_DEBUG=y
> ^^^^^^^^
>
> This is the one and it's set correctly.
>
>> > cat .config | grep PRINTK
>> CONFIG_PRINTK=y
>> CONFIG_SND_VERBOSE_PRINTK=y
>> CONFIG_PRINTK_TIME=y
>> # CONFIG_BOOT_PRINTK_DELAY is not set
>> CONFIG_EARLY_PRINTK=y
>> CONFIG_EARLY_PRINTK_DBGP=y
>>
>> Could you confirm that I am ok to go?
>
> BTW, I just figured out how the kernel does the wrong thing now. If you
> want to wait on running this experiment, that's fine with me. I can
> contact you if someone wants proof that this happens.
>
> ~Peter
OK, Peter, I will put a hold on this. Let me know if you need further input.
--
---
Colin Beckingham
T24gTW9uLCAyMDExLTA4LTA4IGF0IDA5OjMxIC0wNDAwLCBDb2xpbiBCZWNraW5naGFtIHdyb3Rl
Og0KPiANCj4gT24gMDgvMDgvMjAxMSAwODozOCBBTSwgUGV0ZXIgSHVybGV5IHdyb3RlOg0KPiA+
IE9uIFNhdCwgMjAxMS0wOC0wNiBhdCAxMzoyMiAtMDQwMCwgQ29saW4gQmVja2luZ2hhbSB3cm90
ZToNCj4gPj4gT24gMDgvMDYvMjAxMSAxMjo1MCBQTSwgUGV0ZXIgSHVybGV5IHdyb3RlOg0KPiA+
Pj4gT24gU2F0LCAyMDExLTA4LTA2IGF0IDExOjMzIC0wNDAwLCBDb2xpbiBCZWNraW5naGFtIHdy
b3RlOg0KPiA+Pj4+IEhpIFBldGVyOg0KPiA+Pj4+DQo+ID4+PiAuLi48c25pcD4uLi4NCj4gPj4+
PiBJIHJhbiAjIGhjaWNvbmZpZyBoY2kwIHNzcG1vZGUgMSB0byBmb3JjZSB0aGUgYWRhcHRlciBp
bnRvIGEgc2VjdXJlIGF0dGVtcHQuDQo+ID4+Pj4NCj4gPj4+PiBJIGRvd25sb2FkZWQgYW5kIGlu
c3RhbGxlZCB0aGUgbGF0ZXN0IGhjaWR1bXAgd2hpY2ggaWRlbnRpZmllcyBpdHNlbGYNCj4gPj4+
PiAoaGNpZHVtcCAtdikgYXMgMi4wIGV2ZW4gdGhvdWdoIGl0IGlzIG1hcmtlZCBhcyAyLjEgdmVy
c2lvbiBvbiB0aGUgd2VicGFnZS4NCj4gPj4+Pg0KPiA+Pj4+IE1hZGUgYW5vdGhlciBhdHRlbXB0
IHRvIGNvbm5lY3QsIGhlcmUgaXMgdGhlIHN5c2xvZw0KPiA+Pj4+DQo+ID4+Pj4gIyB0YWlsIC1u
IDEwMCAvdmFyL2xvZy9tZXNzYWdlcyB8IGdyZXAgYmx1ZXRvb3RoZA0KPiA+Pj4+IEF1ZyAgNiAw
NToxNTozOSBsaW51eC1jOTZoIGJsdWV0b290aGRbMTI0Nl06IEF1ZGlvIGNvbm5lY3Rpb24gZ290
DQo+ID4+Pj4gZGlzY29ubmVjdGVkDQo+ID4+Pj4gQXVnICA2IDExOjIzOjI5IGxpbnV4LWM5Nmgg
Ymx1ZXRvb3RoZFsxMjQ2XTogUmVqZWN0aW5nIHJlcXVlc3Q6IHJlbW90ZQ0KPiA+Pj4+IGRldmlj
ZSBjYW4ndCBwcm92aWRlIE1JVE0NCj4gPj4+PiBBdWcgIDYgMTE6MjM6NTYgbGludXgtYzk2aCBi
bHVldG9vdGhkWzEyNDZdOiBEaXNjb3Zlcnkgc2Vzc2lvbg0KPiA+Pj4+IDB4N2Y4MDFkMGE2Y2Ew
IHdpdGggOjEuNDE3OCBhY3RpdmF0ZWQNCj4gPj4+PiBBdWcgIDYgMTE6MjQ6MDEgbGludXgtYzk2
aCBibHVldG9vdGhkWzEyNDZdOiBTdG9wcGluZyBkaXNjb3ZlcnkNCj4gPj4+PiBBdWcgIDYgMTE6
MjQ6MTMgbGludXgtYzk2aCBibHVldG9vdGhkWzEyNDZdOiBQZXJtaXNzaW9uIGRlbmllZCAoMTMp
DQo+ID4+Pj4NCj4gPj4+PiBhbmQgYSBiaW5hcnkgaGNpZHVtcCBpcyBhdHRhY2hlZC4NCj4gPj4+
DQo+ID4+PiBIaSBDb2xpbiwNCj4gPj4+DQo+ID4+PiBUaGF0IG1ha2VzIGEgbG90IG1vcmUgc2Vu
c2UhDQo+ID4+Pg0KPiA+Pj4gV291bGQgeW91IHBsZWFzZSByZXBlYXQgdGhlIGV4cGVyaW1lbnQg
d2l0aCBibHVldG9vdGhkIGluIGRlYnVnIG1vZGUsDQo+ID4+PiB0aG91Z2g/IFRoYXQgd291bGQg
Z2l2ZSBtZSBhIGxvdCBtb3JlIGluZm9ybWF0aW9uIHRvIHdvcmsgd2l0aCBhYm91dCBob3cNCj4g
Pj4+IGJsdWV0b290aGQgZ290IHRvIHRoYXQgcG9pbnQuDQo+ID4+Pg0KPiA+Pj4gQXMgYmVmb3Jl
LCBwbGVhc2UgY2FwdHVyZSBoY2lkdW1wIGJpbmFyeSBhdCB0aGUgc2FtZSB0aW1lLiBBbHNvIHBs
ZWFzZQ0KPiA+Pj4gaW5jbHVkZSBldmVyeSBibHVldG9vdGhkIHN5c2xvZyBtZXNzYWdlIHN0YXJ0
aW5nIGZyb20gdGhlIHN0YXJ0IG9mIHRoZQ0KPiA+Pj4gZXhwZXJpbWVudC4NCj4gPj4+DQo+ID4+
PiBJIGFwcHJlY2lhdGUgeW91ciBwYXRpZW5jZSBoZWxwaW5nIG1lIHRvIHRyYWNrIGRvd24gdGhp
cyBidWcuDQo+ID4+Pg0KPiA+Pj4gUmVnYXJkcywNCj4gPj4+IFBldGVyIEh1cmxleQ0KPiA+Pg0K
PiA+PiBTb3JyeSwgZm9yZ290IHRvIHNldCBibHVldG9vdGhkIGluIGRlYnVnIG1vZGUuDQo+ID4+
DQo+ID4+IEF0dGFjaGVkIGFyZSBteSBsYXRlc3QgbG9ncywgMiBmaWxlcywgd2VwNDc1YS4qLiBO
b3RlIGluIHRoZSBzeXNsb2cgdGhhdA0KPiA+PiB0aGUgZmlyc3QgZW50cnkgaXMgdGltZXN0YW1w
ZWQgd2F5IGJlZm9yZSB0aGUgZXhwZXJpbWVudCB3YXMgbGF1bmNoZWQsDQo+ID4+IHNvIHRoZSBs
b2cgc2hvdWxkIGhhdmUgZXZlcnl0aGluZyB0aGF0IGJsdWV0b290aGQgd3JvdGUgZm9yIHRoZSBj
dXJyZW50DQo+ID4+IGV4cGVyaW1lbnQuDQo+ID4NCj4gPiBIaSBDb2xpbiwNCj4gPg0KPiA+IFdl
bGwsIHRoZSBuZXcgbG9ncyBkaWQgbm90IHJlY3JlYXRlIHRoZSAiUmVqZWN0aW5nIHJlcXVlc3Q6
IHJlbW90ZQ0KPiA+IGRldmljZSBjYW4ndCBwcm92aWRlIE1JVE0iLiBIb3dldmVyLCB0aGV5IGRp
ZCBzaG93IDIgdGhpbmdzOg0KPiA+DQo+ID4gMS4gVGhlIGhvc3QgY29udHJvbGxlciBoYXMgYSBy
YWNlIGNvbmRpdGlvbiBidWcgd2hpY2ggaGFzIGJlZW4gc2Vlbg0KPiA+IGJlZm9yZSAoc2VlIHRo
aXMgdGhyZWFkDQo+ID4gaHR0cDovL2NvbW1lbnRzLmdtYW5lLm9yZy9nbWFuZS5saW51eC5ibHVl
ei5rZXJuZWwvMTQyODYgZm9yIHRoZSByZWFsbHkNCj4gPiB0ZWNobmljYWwgZGlzY3Vzc2lvbikN
Cj4gPg0KPiA+IFRoYXQncyB3aHkgdGhlIGluaXRpYWwgYXR0ZW1wdCBieSB0aGUgZGV2aWNlIGF0
IGNvbm5lY3RpbmcgYW4gUkZDT01NDQo+ID4gY2hhbm5lbCBpcyByZWplY3RlZCAoQCAxMzoxMzow
Mi41MzM3MTMpLg0KPiA+DQo+ID4gTmV2ZXJ0aGVsZXNzLCB0aGUgaGVhZHNldCBpcyBmb3VuZCBh
bnl3YXkgYW5kIEJsdWV6IGNvbm5lY3RzIHRvIHRoZQ0KPiA+IGhlYWRzZXQuIEFmdGVyIGVzdGFi
bGlzaGluZyBhbiBpbnNlY3VyZSBTRFAgbGluaywgQmx1ZXogYXR0ZW1wdHMgdG8gb3Blbg0KPiA+
IGFuIFJGQ09NTSBjaGFubmVsIHRvIHRoZSBkZXZpY2UsIGFuZA0KPiA+DQo+ID4gMi4gdGhlIGtl
cm5lbCBhdHRlbXB0cyB0byBjb25uZWN0IHRoZSBSRkNPTU0gY2hhbm5lbCBwcmlvciB0byB0aGUg
bGluaw0KPiA+IGJlaW5nIGVuY3J5cHRlZCwgc28gdGhlIGRldmljZSByZWplY3RzIHRoZSBjb25u
ZWN0aW9uLg0KPiA+DQo+ID4gVGhlcmUgd2VyZSBzb21lIGxhc3QgbWludXRlIGNoYW5nZXMgdG8g
My4wIGZpbmFsIHRoYXQgZGlyZWN0bHkgaW1wYWN0cw0KPiA+IGhvdyB0aGlzIGlzIHN1cHBvc2Vk
IHRvIHdvcmsuIEhvd2V2ZXIsIGV2ZW4gd2l0aCB0aG9zZSBjaGFuZ2VzIGl0J3MNCj4gPiB1bmNs
ZWFyIHRvIG1lIGhvdyAjMiBpcyBoYXBwZW5pbmcuDQo+ID4NCj4gPiBXb3VsZCB5b3UgYmUgd2ls
bGluZyB0byBydW4gdGhlIHNhbWUgZXhwZXJpbWVudCBhcyBiZWZvcmUgYnV0IHdpdGggdGhlDQo+
ID4ga2VybmVsIGJsdWV0b290aCBtb2R1bGUgZW5hYmxlZCBmb3IgZGVidWcgb3V0cHV0PyAgSWYg
eW91ciBrZXJuZWwgaXMNCj4gPiBjb25maWd1cmVkIGZvciBkeW5hbWljIGRlYnVnIChLZXJuZWwg
aGFja2luZy9FbmFibGUgZHluYW1pYyBwcmludGsoKQ0KPiA+IHN1cHBvcnQgPT4gIFkpLCBkb2lu
ZyB0aGlzIGlzIHRyaXZpYWw6DQo+ID4gIyBzdWRvIHN1DQo+ID4gIyBlY2hvIC1uICJtb2R1bGUg
Ymx1ZXRvb3RoICtwIg0KPiA+ICAgICAgICAgICAgICAgICAgICAgID4gIC9zeXMva2VybmVsL2Rl
YnVnL2R5bmFtaWNfZGVidWcvY29udHJvbA0KPiA+IDwgIHBlcmZvcm0gZXhwZXJpbWVudD4NCj4g
PiAjIGVjaG8gLW4gIm1vZHVsZSBibHVldG9vdGggLXAiDQo+ID4gICAgICAgICAgICAgICAgICAg
ICAgPiAgL3N5cy9rZXJuZWwvZGVidWcvZHluYW1pY19kZWJ1Zy9jb250cm9sDQo+ID4NCj4gPiBS
ZWdhcmRzLA0KPiA+IFBldGVyIEh1cmxleQ0KPiANCj4gUGV0ZXIsIGJlZm9yZSBJIGRvIHRoaXMs
IGxldCBtZSBqdXN0IHZlcmlmeSB0aGF0IG15IGtlcm5lbCBpcyBzZXQgdXAgDQo+IHJpZ2h0LiBJ
IGNoZWNrZWQgZm9yIGR5bmFtaWMgcHJpbnRrIGFuZCBJIGFtIG5vdCBjbGVhciB0aGF0IEkgaGF2
ZSB0aGUgDQo+IHNldHRpbmcgbmVlZGVkLiBIZXJlIGlzIHdoYXQgbXkgLmNvbmZpZyB0ZWxscyBt
ZSBmb3IgZHluYW1pYyBhbmQgcHJpbnRrIA0KPiBzZXBhcmF0ZWx5Lg0KPiANCj4gID4gY2F0IC5j
b25maWcgfCBncmVwIERZTkFNSUMNCj4gQ09ORklHX05FVENPTlNPTEVfRFlOQU1JQz15DQo+IENP
TkZJR19EVkJfRFlOQU1JQ19NSU5PUlM9eQ0KPiBDT05GSUdfU05EX0RZTkFNSUNfTUlOT1JTPXkN
Cj4gIyBDT05GSUdfVVNCX0RZTkFNSUNfTUlOT1JTIGlzIG5vdCBzZXQNCj4gQ09ORklHX0hBVkVf
RFlOQU1JQ19GVFJBQ0U9eQ0KPiBDT05GSUdfRFlOQU1JQ19ERUJVRz15DQogIF5eXl5eXl5eDQoN
ClRoaXMgaXMgdGhlIG9uZSBhbmQgaXQncyBzZXQgY29ycmVjdGx5Lg0KDQo+ICA+IGNhdCAuY29u
ZmlnIHwgZ3JlcCBQUklOVEsNCj4gQ09ORklHX1BSSU5USz15DQo+IENPTkZJR19TTkRfVkVSQk9T
RV9QUklOVEs9eQ0KPiBDT05GSUdfUFJJTlRLX1RJTUU9eQ0KPiAjIENPTkZJR19CT09UX1BSSU5U
S19ERUxBWSBpcyBub3Qgc2V0DQo+IENPTkZJR19FQVJMWV9QUklOVEs9eQ0KPiBDT05GSUdfRUFS
TFlfUFJJTlRLX0RCR1A9eQ0KPiANCj4gQ291bGQgeW91IGNvbmZpcm0gdGhhdCBJIGFtIG9rIHRv
IGdvPw0KDQpCVFcsIEkganVzdCBmaWd1cmVkIG91dCBob3cgdGhlIGtlcm5lbCBkb2VzIHRoZSB3
cm9uZyB0aGluZyBub3cuIElmIHlvdQ0Kd2FudCB0byB3YWl0IG9uIHJ1bm5pbmcgdGhpcyBleHBl
cmltZW50LCB0aGF0J3MgZmluZSB3aXRoIG1lLiBJIGNhbg0KY29udGFjdCB5b3UgaWYgc29tZW9u
ZSB3YW50cyBwcm9vZiB0aGF0IHRoaXMgaGFwcGVucy4NCg0KflBldGVyDQo=
On 08/08/2011 08:38 AM, Peter Hurley wrote:
> On Sat, 2011-08-06 at 13:22 -0400, Colin Beckingham wrote:
>> On 08/06/2011 12:50 PM, Peter Hurley wrote:
>>> On Sat, 2011-08-06 at 11:33 -0400, Colin Beckingham wrote:
>>>> Hi Peter:
>>>>
>>> ...<snip>...
>>>> I ran # hciconfig hci0 sspmode 1 to force the adapter into a secure attempt.
>>>>
>>>> I downloaded and installed the latest hcidump which identifies itself
>>>> (hcidump -v) as 2.0 even though it is marked as 2.1 version on the webpage.
>>>>
>>>> Made another attempt to connect, here is the syslog
>>>>
>>>> # tail -n 100 /var/log/messages | grep bluetoothd
>>>> Aug 6 05:15:39 linux-c96h bluetoothd[1246]: Audio connection got
>>>> disconnected
>>>> Aug 6 11:23:29 linux-c96h bluetoothd[1246]: Rejecting request: remote
>>>> device can't provide MITM
>>>> Aug 6 11:23:56 linux-c96h bluetoothd[1246]: Discovery session
>>>> 0x7f801d0a6ca0 with :1.4178 activated
>>>> Aug 6 11:24:01 linux-c96h bluetoothd[1246]: Stopping discovery
>>>> Aug 6 11:24:13 linux-c96h bluetoothd[1246]: Permission denied (13)
>>>>
>>>> and a binary hcidump is attached.
>>>
>>> Hi Colin,
>>>
>>> That makes a lot more sense!
>>>
>>> Would you please repeat the experiment with bluetoothd in debug mode,
>>> though? That would give me a lot more information to work with about how
>>> bluetoothd got to that point.
>>>
>>> As before, please capture hcidump binary at the same time. Also please
>>> include every bluetoothd syslog message starting from the start of the
>>> experiment.
>>>
>>> I appreciate your patience helping me to track down this bug.
>>>
>>> Regards,
>>> Peter Hurley
>>
>> Sorry, forgot to set bluetoothd in debug mode.
>>
>> Attached are my latest logs, 2 files, wep475a.*. Note in the syslog that
>> the first entry is timestamped way before the experiment was launched,
>> so the log should have everything that bluetoothd wrote for the current
>> experiment.
>
> Hi Colin,
>
> Well, the new logs did not recreate the "Rejecting request: remote
> device can't provide MITM". However, they did show 2 things:
>
> 1. The host controller has a race condition bug which has been seen
> before (see this thread
> http://comments.gmane.org/gmane.linux.bluez.kernel/14286 for the really
> technical discussion)
>
> That's why the initial attempt by the device at connecting an RFCOMM
> channel is rejected (@ 13:13:02.533713).
>
> Nevertheless, the headset is found anyway and Bluez connects to the
> headset. After establishing an insecure SDP link, Bluez attempts to open
> an RFCOMM channel to the device, and
>
> 2. the kernel attempts to connect the RFCOMM channel prior to the link
> being encrypted, so the device rejects the connection.
>
> There were some last minute changes to 3.0 final that directly impacts
> how this is supposed to work. However, even with those changes it's
> unclear to me how #2 is happening.
>
> Would you be willing to run the same experiment as before but with the
> kernel bluetooth module enabled for debug output? If your kernel is
> configured for dynamic debug (Kernel hacking/Enable dynamic printk()
> support => Y), doing this is trivial:
> # sudo su
> # echo -n "module bluetooth +p"
> > /sys/kernel/debug/dynamic_debug/control
> < perform experiment>
> # echo -n "module bluetooth -p"
> > /sys/kernel/debug/dynamic_debug/control
>
> Regards,
> Peter Hurley
Peter, before I do this, let me just verify that my kernel is set up
right. I checked for dynamic printk and I am not clear that I have the
setting needed. Here is what my .config tells me for dynamic and printk
separately.
> cat .config | grep DYNAMIC
CONFIG_NETCONSOLE_DYNAMIC=y
CONFIG_DVB_DYNAMIC_MINORS=y
CONFIG_SND_DYNAMIC_MINORS=y
# CONFIG_USB_DYNAMIC_MINORS is not set
CONFIG_HAVE_DYNAMIC_FTRACE=y
CONFIG_DYNAMIC_DEBUG=y
> cat .config | grep PRINTK
CONFIG_PRINTK=y
CONFIG_SND_VERBOSE_PRINTK=y
CONFIG_PRINTK_TIME=y
# CONFIG_BOOT_PRINTK_DELAY is not set
CONFIG_EARLY_PRINTK=y
CONFIG_EARLY_PRINTK_DBGP=y
Could you confirm that I am ok to go?
--
---
Colin Beckingham
T24gU2F0LCAyMDExLTA4LTA2IGF0IDEzOjIyIC0wNDAwLCBDb2xpbiBCZWNraW5naGFtIHdyb3Rl
Og0KPiBPbiAwOC8wNi8yMDExIDEyOjUwIFBNLCBQZXRlciBIdXJsZXkgd3JvdGU6DQo+ID4gT24g
U2F0LCAyMDExLTA4LTA2IGF0IDExOjMzIC0wNDAwLCBDb2xpbiBCZWNraW5naGFtIHdyb3RlOg0K
PiA+PiBIaSBQZXRlcjoNCj4gPj4NCj4gPiAuLi48c25pcD4uLi4NCj4gPj4gSSByYW4gIyBoY2lj
b25maWcgaGNpMCBzc3Btb2RlIDEgdG8gZm9yY2UgdGhlIGFkYXB0ZXIgaW50byBhIHNlY3VyZSBh
dHRlbXB0Lg0KPiA+Pg0KPiA+PiBJIGRvd25sb2FkZWQgYW5kIGluc3RhbGxlZCB0aGUgbGF0ZXN0
IGhjaWR1bXAgd2hpY2ggaWRlbnRpZmllcyBpdHNlbGYNCj4gPj4gKGhjaWR1bXAgLXYpIGFzIDIu
MCBldmVuIHRob3VnaCBpdCBpcyBtYXJrZWQgYXMgMi4xIHZlcnNpb24gb24gdGhlIHdlYnBhZ2Uu
DQo+ID4+DQo+ID4+IE1hZGUgYW5vdGhlciBhdHRlbXB0IHRvIGNvbm5lY3QsIGhlcmUgaXMgdGhl
IHN5c2xvZw0KPiA+Pg0KPiA+PiAjIHRhaWwgLW4gMTAwIC92YXIvbG9nL21lc3NhZ2VzIHwgZ3Jl
cCBibHVldG9vdGhkDQo+ID4+IEF1ZyAgNiAwNToxNTozOSBsaW51eC1jOTZoIGJsdWV0b290aGRb
MTI0Nl06IEF1ZGlvIGNvbm5lY3Rpb24gZ290DQo+ID4+IGRpc2Nvbm5lY3RlZA0KPiA+PiBBdWcg
IDYgMTE6MjM6MjkgbGludXgtYzk2aCBibHVldG9vdGhkWzEyNDZdOiBSZWplY3RpbmcgcmVxdWVz
dDogcmVtb3RlDQo+ID4+IGRldmljZSBjYW4ndCBwcm92aWRlIE1JVE0NCj4gPj4gQXVnICA2IDEx
OjIzOjU2IGxpbnV4LWM5NmggYmx1ZXRvb3RoZFsxMjQ2XTogRGlzY292ZXJ5IHNlc3Npb24NCj4g
Pj4gMHg3ZjgwMWQwYTZjYTAgd2l0aCA6MS40MTc4IGFjdGl2YXRlZA0KPiA+PiBBdWcgIDYgMTE6
MjQ6MDEgbGludXgtYzk2aCBibHVldG9vdGhkWzEyNDZdOiBTdG9wcGluZyBkaXNjb3ZlcnkNCj4g
Pj4gQXVnICA2IDExOjI0OjEzIGxpbnV4LWM5NmggYmx1ZXRvb3RoZFsxMjQ2XTogUGVybWlzc2lv
biBkZW5pZWQgKDEzKQ0KPiA+Pg0KPiA+PiBhbmQgYSBiaW5hcnkgaGNpZHVtcCBpcyBhdHRhY2hl
ZC4NCj4gPg0KPiA+IEhpIENvbGluLA0KPiA+DQo+ID4gVGhhdCBtYWtlcyBhIGxvdCBtb3JlIHNl
bnNlIQ0KPiA+DQo+ID4gV291bGQgeW91IHBsZWFzZSByZXBlYXQgdGhlIGV4cGVyaW1lbnQgd2l0
aCBibHVldG9vdGhkIGluIGRlYnVnIG1vZGUsDQo+ID4gdGhvdWdoPyBUaGF0IHdvdWxkIGdpdmUg
bWUgYSBsb3QgbW9yZSBpbmZvcm1hdGlvbiB0byB3b3JrIHdpdGggYWJvdXQgaG93DQo+ID4gYmx1
ZXRvb3RoZCBnb3QgdG8gdGhhdCBwb2ludC4NCj4gPg0KPiA+IEFzIGJlZm9yZSwgcGxlYXNlIGNh
cHR1cmUgaGNpZHVtcCBiaW5hcnkgYXQgdGhlIHNhbWUgdGltZS4gQWxzbyBwbGVhc2UNCj4gPiBp
bmNsdWRlIGV2ZXJ5IGJsdWV0b290aGQgc3lzbG9nIG1lc3NhZ2Ugc3RhcnRpbmcgZnJvbSB0aGUg
c3RhcnQgb2YgdGhlDQo+ID4gZXhwZXJpbWVudC4NCj4gPg0KPiA+IEkgYXBwcmVjaWF0ZSB5b3Vy
IHBhdGllbmNlIGhlbHBpbmcgbWUgdG8gdHJhY2sgZG93biB0aGlzIGJ1Zy4NCj4gPg0KPiA+IFJl
Z2FyZHMsDQo+ID4gUGV0ZXIgSHVybGV5DQo+IA0KPiBTb3JyeSwgZm9yZ290IHRvIHNldCBibHVl
dG9vdGhkIGluIGRlYnVnIG1vZGUuDQo+IA0KPiBBdHRhY2hlZCBhcmUgbXkgbGF0ZXN0IGxvZ3Ms
IDIgZmlsZXMsIHdlcDQ3NWEuKi4gTm90ZSBpbiB0aGUgc3lzbG9nIHRoYXQgDQo+IHRoZSBmaXJz
dCBlbnRyeSBpcyB0aW1lc3RhbXBlZCB3YXkgYmVmb3JlIHRoZSBleHBlcmltZW50IHdhcyBsYXVu
Y2hlZCwgDQo+IHNvIHRoZSBsb2cgc2hvdWxkIGhhdmUgZXZlcnl0aGluZyB0aGF0IGJsdWV0b290
aGQgd3JvdGUgZm9yIHRoZSBjdXJyZW50IA0KPiBleHBlcmltZW50Lg0KDQpIaSBDb2xpbiwNCg0K
V2VsbCwgdGhlIG5ldyBsb2dzIGRpZCBub3QgcmVjcmVhdGUgdGhlICJSZWplY3RpbmcgcmVxdWVz
dDogcmVtb3RlDQpkZXZpY2UgY2FuJ3QgcHJvdmlkZSBNSVRNIi4gSG93ZXZlciwgdGhleSBkaWQg
c2hvdyAyIHRoaW5nczoNCg0KMS4gVGhlIGhvc3QgY29udHJvbGxlciBoYXMgYSByYWNlIGNvbmRp
dGlvbiBidWcgd2hpY2ggaGFzIGJlZW4gc2Vlbg0KYmVmb3JlIChzZWUgdGhpcyB0aHJlYWQNCmh0
dHA6Ly9jb21tZW50cy5nbWFuZS5vcmcvZ21hbmUubGludXguYmx1ZXoua2VybmVsLzE0Mjg2IGZv
ciB0aGUgcmVhbGx5DQp0ZWNobmljYWwgZGlzY3Vzc2lvbikNCg0KVGhhdCdzIHdoeSB0aGUgaW5p
dGlhbCBhdHRlbXB0IGJ5IHRoZSBkZXZpY2UgYXQgY29ubmVjdGluZyBhbiBSRkNPTU0NCmNoYW5u
ZWwgaXMgcmVqZWN0ZWQgKEAgMTM6MTM6MDIuNTMzNzEzKS4NCg0KTmV2ZXJ0aGVsZXNzLCB0aGUg
aGVhZHNldCBpcyBmb3VuZCBhbnl3YXkgYW5kIEJsdWV6IGNvbm5lY3RzIHRvIHRoZQ0KaGVhZHNl
dC4gQWZ0ZXIgZXN0YWJsaXNoaW5nIGFuIGluc2VjdXJlIFNEUCBsaW5rLCBCbHVleiBhdHRlbXB0
cyB0byBvcGVuDQphbiBSRkNPTU0gY2hhbm5lbCB0byB0aGUgZGV2aWNlLCBhbmQNCg0KMi4gdGhl
IGtlcm5lbCBhdHRlbXB0cyB0byBjb25uZWN0IHRoZSBSRkNPTU0gY2hhbm5lbCBwcmlvciB0byB0
aGUgbGluaw0KYmVpbmcgZW5jcnlwdGVkLCBzbyB0aGUgZGV2aWNlIHJlamVjdHMgdGhlIGNvbm5l
Y3Rpb24uDQoNClRoZXJlIHdlcmUgc29tZSBsYXN0IG1pbnV0ZSBjaGFuZ2VzIHRvIDMuMCBmaW5h
bCB0aGF0IGRpcmVjdGx5IGltcGFjdHMNCmhvdyB0aGlzIGlzIHN1cHBvc2VkIHRvIHdvcmsuIEhv
d2V2ZXIsIGV2ZW4gd2l0aCB0aG9zZSBjaGFuZ2VzIGl0J3MNCnVuY2xlYXIgdG8gbWUgaG93ICMy
IGlzIGhhcHBlbmluZy4NCg0KV291bGQgeW91IGJlIHdpbGxpbmcgdG8gcnVuIHRoZSBzYW1lIGV4
cGVyaW1lbnQgYXMgYmVmb3JlIGJ1dCB3aXRoIHRoZQ0Ka2VybmVsIGJsdWV0b290aCBtb2R1bGUg
ZW5hYmxlZCBmb3IgZGVidWcgb3V0cHV0PyAgSWYgeW91ciBrZXJuZWwgaXMNCmNvbmZpZ3VyZWQg
Zm9yIGR5bmFtaWMgZGVidWcgKEtlcm5lbCBoYWNraW5nL0VuYWJsZSBkeW5hbWljIHByaW50aygp
DQpzdXBwb3J0ID0+IFkpLCBkb2luZyB0aGlzIGlzIHRyaXZpYWw6DQojIHN1ZG8gc3UNCiMgZWNo
byAtbiAibW9kdWxlIGJsdWV0b290aCArcCINCiAgICAgICAgICAgICAgICAgICAgPiAvc3lzL2tl
cm5lbC9kZWJ1Zy9keW5hbWljX2RlYnVnL2NvbnRyb2wNCjwgcGVyZm9ybSBleHBlcmltZW50ID4N
CiMgZWNobyAtbiAibW9kdWxlIGJsdWV0b290aCAtcCINCiAgICAgICAgICAgICAgICAgICAgPiAv
c3lzL2tlcm5lbC9kZWJ1Zy9keW5hbWljX2RlYnVnL2NvbnRyb2wNCg0KUmVnYXJkcywNClBldGVy
IEh1cmxleQ0K
On 08/06/2011 12:50 PM, Peter Hurley wrote:
> On Sat, 2011-08-06 at 11:33 -0400, Colin Beckingham wrote:
>> Hi Peter:
>>
> ...<snip>...
>> I ran # hciconfig hci0 sspmode 1 to force the adapter into a secure attempt.
>>
>> I downloaded and installed the latest hcidump which identifies itself
>> (hcidump -v) as 2.0 even though it is marked as 2.1 version on the webpage.
>>
>> Made another attempt to connect, here is the syslog
>>
>> # tail -n 100 /var/log/messages | grep bluetoothd
>> Aug 6 05:15:39 linux-c96h bluetoothd[1246]: Audio connection got
>> disconnected
>> Aug 6 11:23:29 linux-c96h bluetoothd[1246]: Rejecting request: remote
>> device can't provide MITM
>> Aug 6 11:23:56 linux-c96h bluetoothd[1246]: Discovery session
>> 0x7f801d0a6ca0 with :1.4178 activated
>> Aug 6 11:24:01 linux-c96h bluetoothd[1246]: Stopping discovery
>> Aug 6 11:24:13 linux-c96h bluetoothd[1246]: Permission denied (13)
>>
>> and a binary hcidump is attached.
>
> Hi Colin,
>
> That makes a lot more sense!
>
> Would you please repeat the experiment with bluetoothd in debug mode,
> though? That would give me a lot more information to work with about how
> bluetoothd got to that point.
>
> As before, please capture hcidump binary at the same time. Also please
> include every bluetoothd syslog message starting from the start of the
> experiment.
>
> I appreciate your patience helping me to track down this bug.
>
> Regards,
> Peter Hurley
Sorry, forgot to set bluetoothd in debug mode.
Attached are my latest logs, 2 files, wep475a.*. Note in the syslog that
the first entry is timestamped way before the experiment was launched,
so the log should have everything that bluetoothd wrote for the current
experiment.
--
---
Colin Beckingham
T24gU2F0LCAyMDExLTA4LTA2IGF0IDExOjMzIC0wNDAwLCBDb2xpbiBCZWNraW5naGFtIHdyb3Rl
Og0KPiBIaSBQZXRlcjoNCj4gDQouLi48c25pcD4uLi4NCj4gSSByYW4gIyBoY2ljb25maWcgaGNp
MCBzc3Btb2RlIDEgdG8gZm9yY2UgdGhlIGFkYXB0ZXIgaW50byBhIHNlY3VyZSBhdHRlbXB0Lg0K
PiANCj4gSSBkb3dubG9hZGVkIGFuZCBpbnN0YWxsZWQgdGhlIGxhdGVzdCBoY2lkdW1wIHdoaWNo
IGlkZW50aWZpZXMgaXRzZWxmIA0KPiAoaGNpZHVtcCAtdikgYXMgMi4wIGV2ZW4gdGhvdWdoIGl0
IGlzIG1hcmtlZCBhcyAyLjEgdmVyc2lvbiBvbiB0aGUgd2VicGFnZS4NCj4gDQo+IE1hZGUgYW5v
dGhlciBhdHRlbXB0IHRvIGNvbm5lY3QsIGhlcmUgaXMgdGhlIHN5c2xvZw0KPiANCj4gIyB0YWls
IC1uIDEwMCAvdmFyL2xvZy9tZXNzYWdlcyB8IGdyZXAgYmx1ZXRvb3RoZA0KPiBBdWcgIDYgMDU6
MTU6MzkgbGludXgtYzk2aCBibHVldG9vdGhkWzEyNDZdOiBBdWRpbyBjb25uZWN0aW9uIGdvdCAN
Cj4gZGlzY29ubmVjdGVkDQo+IEF1ZyAgNiAxMToyMzoyOSBsaW51eC1jOTZoIGJsdWV0b290aGRb
MTI0Nl06IFJlamVjdGluZyByZXF1ZXN0OiByZW1vdGUgDQo+IGRldmljZSBjYW4ndCBwcm92aWRl
IE1JVE0NCj4gQXVnICA2IDExOjIzOjU2IGxpbnV4LWM5NmggYmx1ZXRvb3RoZFsxMjQ2XTogRGlz
Y292ZXJ5IHNlc3Npb24gDQo+IDB4N2Y4MDFkMGE2Y2EwIHdpdGggOjEuNDE3OCBhY3RpdmF0ZWQN
Cj4gQXVnICA2IDExOjI0OjAxIGxpbnV4LWM5NmggYmx1ZXRvb3RoZFsxMjQ2XTogU3RvcHBpbmcg
ZGlzY292ZXJ5DQo+IEF1ZyAgNiAxMToyNDoxMyBsaW51eC1jOTZoIGJsdWV0b290aGRbMTI0Nl06
IFBlcm1pc3Npb24gZGVuaWVkICgxMykNCj4gDQo+IGFuZCBhIGJpbmFyeSBoY2lkdW1wIGlzIGF0
dGFjaGVkLg0KDQpIaSBDb2xpbiwNCg0KVGhhdCBtYWtlcyBhIGxvdCBtb3JlIHNlbnNlIQ0KDQpX
b3VsZCB5b3UgcGxlYXNlIHJlcGVhdCB0aGUgZXhwZXJpbWVudCB3aXRoIGJsdWV0b290aGQgaW4g
ZGVidWcgbW9kZSwNCnRob3VnaD8gVGhhdCB3b3VsZCBnaXZlIG1lIGEgbG90IG1vcmUgaW5mb3Jt
YXRpb24gdG8gd29yayB3aXRoIGFib3V0IGhvdw0KYmx1ZXRvb3RoZCBnb3QgdG8gdGhhdCBwb2lu
dC4NCg0KQXMgYmVmb3JlLCBwbGVhc2UgY2FwdHVyZSBoY2lkdW1wIGJpbmFyeSBhdCB0aGUgc2Ft
ZSB0aW1lLiBBbHNvIHBsZWFzZQ0KaW5jbHVkZSBldmVyeSBibHVldG9vdGhkIHN5c2xvZyBtZXNz
YWdlIHN0YXJ0aW5nIGZyb20gdGhlIHN0YXJ0IG9mIHRoZQ0KZXhwZXJpbWVudC4NCg0KSSBhcHBy
ZWNpYXRlIHlvdXIgcGF0aWVuY2UgaGVscGluZyBtZSB0byB0cmFjayBkb3duIHRoaXMgYnVnLg0K
DQpSZWdhcmRzLA0KUGV0ZXIgSHVybGV5DQo=
Hi Peter:
On 08/06/2011 10:36 AM, Peter Hurley wrote:
> On Thu, 2011-08-04 at 10:54 -0400, Peter Hurley wrote:
>> Hi Colin,
>>
>> On Thu, 2011-08-04 at 08:17 -0400, Johan Hedberg wrote:
>>> Hi Colin,
>>>
>>> On Thu, Aug 04, 2011, Colin Beckingham wrote:
>>>> I'd like to provide some feedback regarding a Samsung WEP475 headset
>>>> which fails to connect to linux specifically.
>>>>
>>>> The USB bluetooth adapter is a Model: Belkin BLUETOOTH USB +EDR
>>>> ADAPTER v2.1 UHE which successfully interconnects with 2 Jabra and 1
>>>> Plantronics headsets, plus a Nokia E71 phone. Samsung WEP475
>>>> successfully connects to a Windows XP machine and to the Nokia E71.
>>>>
>>>> Using Opensuse 11.4 with custom kernel 3.0 currently, (also fails
>>>> with 2.6.38), bluez 4.96 and bluedevil manager.
>>>>
>>>> Symptoms are that bluedevil sees the headset in pairing mode and
>>>> correctly retrieves the name WEP475, connected button flashes green
>>>> and then returns to grey (not connected). WEP475 led changes to
>>>> connected status but bluedevil shows headset not connected and
>>>> headset does not work.
>>>>
>>>> With bluetoothd in debug mode, I get the following transactions in
>>>> /var/log/messages:
>>>
>>> There seems to be something strange going on with the secure simple
>>> pairing logic. For some reason the initial link key isn't good enough
>>> (auth request + link key negative reply after the initial key has been
>>> generated) and then there's a user confirm negative reply for the second
>>> attempt. It'd be good to get to the bottom of this and fix it properly,
>>> but meanwhile you can probably work around this by disabling SSP on your
>>> side (hciconfig hci0 sspmode 0) and retrying pairing.
>>
>> You're having this problem because the remote device supports SSP but
>> not MITM protection. Some socket is requiring BT_SECURITY_HIGH (thus
>> requiring MITM) -- therefore the kernel is correctly disconnecting and
>> returning 'Authentication Failure' (although returning 'Insufficient
>> Authentication' would probably be better).
>>
>> I think the GATT browser is demanding BT_SECURITY_HIGH -- not sure why
>> though (I don't think it needs to. I'll get back to you on that...)
>
> Colin-
>
> Well, I was wrong about it being related to GATT. I can see some other
> possibilities but I'm confused by the syslog relative to the bt capture
> (eg., the syslog clearly shows a found key but the hcidump shows link
> key negative reply). Were they taken at the same time?!
>
> Regards,
> Peter
>
> PS - If you do send another hcidump, please send a binary capture (with
> timestamps) as you have an old version of hcidump that doesn't decode
> not-automatically-flushable l2cap packets.
I ran # hciconfig hci0 sspmode 1 to force the adapter into a secure attempt.
I downloaded and installed the latest hcidump which identifies itself
(hcidump -v) as 2.0 even though it is marked as 2.1 version on the webpage.
Made another attempt to connect, here is the syslog
# tail -n 100 /var/log/messages | grep bluetoothd
Aug 6 05:15:39 linux-c96h bluetoothd[1246]: Audio connection got
disconnected
Aug 6 11:23:29 linux-c96h bluetoothd[1246]: Rejecting request: remote
device can't provide MITM
Aug 6 11:23:56 linux-c96h bluetoothd[1246]: Discovery session
0x7f801d0a6ca0 with :1.4178 activated
Aug 6 11:24:01 linux-c96h bluetoothd[1246]: Stopping discovery
Aug 6 11:24:13 linux-c96h bluetoothd[1246]: Permission denied (13)
and a binary hcidump is attached.
--
---
Colin Beckingham
T24gVGh1LCAyMDExLTA4LTA0IGF0IDEwOjU0IC0wNDAwLCBQZXRlciBIdXJsZXkgd3JvdGU6DQo+
IEhpIENvbGluLA0KPiANCj4gT24gVGh1LCAyMDExLTA4LTA0IGF0IDA4OjE3IC0wNDAwLCBKb2hh
biBIZWRiZXJnIHdyb3RlOg0KPiA+IEhpIENvbGluLA0KPiA+IA0KPiA+IE9uIFRodSwgQXVnIDA0
LCAyMDExLCBDb2xpbiBCZWNraW5naGFtIHdyb3RlOg0KPiA+ID4gSSdkIGxpa2UgdG8gcHJvdmlk
ZSBzb21lIGZlZWRiYWNrIHJlZ2FyZGluZyBhIFNhbXN1bmcgV0VQNDc1IGhlYWRzZXQNCj4gPiA+
IHdoaWNoIGZhaWxzIHRvIGNvbm5lY3QgdG8gbGludXggc3BlY2lmaWNhbGx5Lg0KPiA+ID4gDQo+
ID4gPiBUaGUgVVNCIGJsdWV0b290aCBhZGFwdGVyIGlzIGEgTW9kZWw6IEJlbGtpbiBCTFVFVE9P
VEggVVNCICtFRFINCj4gPiA+IEFEQVBURVIgdjIuMSBVSEUgd2hpY2ggc3VjY2Vzc2Z1bGx5IGlu
dGVyY29ubmVjdHMgd2l0aCAyIEphYnJhIGFuZCAxDQo+ID4gPiBQbGFudHJvbmljcyBoZWFkc2V0
cywgcGx1cyBhIE5va2lhIEU3MSBwaG9uZS4gU2Ftc3VuZyBXRVA0NzUNCj4gPiA+IHN1Y2Nlc3Nm
dWxseSBjb25uZWN0cyB0byBhIFdpbmRvd3MgWFAgbWFjaGluZSBhbmQgdG8gdGhlIE5va2lhIEU3
MS4NCj4gPiA+IA0KPiA+ID4gVXNpbmcgT3BlbnN1c2UgMTEuNCB3aXRoIGN1c3RvbSBrZXJuZWwg
My4wIGN1cnJlbnRseSwgKGFsc28gZmFpbHMNCj4gPiA+IHdpdGggMi42LjM4KSwgYmx1ZXogNC45
NiBhbmQgYmx1ZWRldmlsIG1hbmFnZXIuDQo+ID4gPiANCj4gPiA+IFN5bXB0b21zIGFyZSB0aGF0
IGJsdWVkZXZpbCBzZWVzIHRoZSBoZWFkc2V0IGluIHBhaXJpbmcgbW9kZSBhbmQNCj4gPiA+IGNv
cnJlY3RseSByZXRyaWV2ZXMgdGhlIG5hbWUgV0VQNDc1LCBjb25uZWN0ZWQgYnV0dG9uIGZsYXNo
ZXMgZ3JlZW4NCj4gPiA+IGFuZCB0aGVuIHJldHVybnMgdG8gZ3JleSAobm90IGNvbm5lY3RlZCku
IFdFUDQ3NSBsZWQgY2hhbmdlcyB0bw0KPiA+ID4gY29ubmVjdGVkIHN0YXR1cyBidXQgYmx1ZWRl
dmlsIHNob3dzIGhlYWRzZXQgbm90IGNvbm5lY3RlZCBhbmQNCj4gPiA+IGhlYWRzZXQgZG9lcyBu
b3Qgd29yay4NCj4gPiA+IA0KPiA+ID4gV2l0aCBibHVldG9vdGhkIGluIGRlYnVnIG1vZGUsIEkg
Z2V0IHRoZSBmb2xsb3dpbmcgdHJhbnNhY3Rpb25zIGluDQo+ID4gPiAvdmFyL2xvZy9tZXNzYWdl
czoNCj4gPiANCj4gPiBUaGVyZSBzZWVtcyB0byBiZSBzb21ldGhpbmcgc3RyYW5nZSBnb2luZyBv
biB3aXRoIHRoZSBzZWN1cmUgc2ltcGxlDQo+ID4gcGFpcmluZyBsb2dpYy4gRm9yIHNvbWUgcmVh
c29uIHRoZSBpbml0aWFsIGxpbmsga2V5IGlzbid0IGdvb2QgZW5vdWdoDQo+ID4gKGF1dGggcmVx
dWVzdCArIGxpbmsga2V5IG5lZ2F0aXZlIHJlcGx5IGFmdGVyIHRoZSBpbml0aWFsIGtleSBoYXMg
YmVlbg0KPiA+IGdlbmVyYXRlZCkgYW5kIHRoZW4gdGhlcmUncyBhIHVzZXIgY29uZmlybSBuZWdh
dGl2ZSByZXBseSBmb3IgdGhlIHNlY29uZA0KPiA+IGF0dGVtcHQuIEl0J2QgYmUgZ29vZCB0byBn
ZXQgdG8gdGhlIGJvdHRvbSBvZiB0aGlzIGFuZCBmaXggaXQgcHJvcGVybHksDQo+ID4gYnV0IG1l
YW53aGlsZSB5b3UgY2FuIHByb2JhYmx5IHdvcmsgYXJvdW5kIHRoaXMgYnkgZGlzYWJsaW5nIFNT
UCBvbiB5b3VyDQo+ID4gc2lkZSAoaGNpY29uZmlnIGhjaTAgc3NwbW9kZSAwKSBhbmQgcmV0cnlp
bmcgcGFpcmluZy4NCj4gDQo+IFlvdSdyZSBoYXZpbmcgdGhpcyBwcm9ibGVtIGJlY2F1c2UgdGhl
IHJlbW90ZSBkZXZpY2Ugc3VwcG9ydHMgU1NQIGJ1dA0KPiBub3QgTUlUTSBwcm90ZWN0aW9uLiBT
b21lIHNvY2tldCBpcyByZXF1aXJpbmcgQlRfU0VDVVJJVFlfSElHSCAodGh1cw0KPiByZXF1aXJp
bmcgTUlUTSkgLS0gdGhlcmVmb3JlIHRoZSBrZXJuZWwgaXMgY29ycmVjdGx5IGRpc2Nvbm5lY3Rp
bmcgYW5kDQo+IHJldHVybmluZyAnQXV0aGVudGljYXRpb24gRmFpbHVyZScgKGFsdGhvdWdoIHJl
dHVybmluZyAnSW5zdWZmaWNpZW50DQo+IEF1dGhlbnRpY2F0aW9uJyB3b3VsZCBwcm9iYWJseSBi
ZSBiZXR0ZXIpLg0KPiANCj4gSSB0aGluayB0aGUgR0FUVCBicm93c2VyIGlzIGRlbWFuZGluZyBC
VF9TRUNVUklUWV9ISUdIIC0tIG5vdCBzdXJlIHdoeQ0KPiB0aG91Z2ggKEkgZG9uJ3QgdGhpbmsg
aXQgbmVlZHMgdG8uIEknbGwgZ2V0IGJhY2sgdG8geW91IG9uIHRoYXQuLi4pDQoNCkNvbGluLQ0K
DQpXZWxsLCBJIHdhcyB3cm9uZyBhYm91dCBpdCBiZWluZyByZWxhdGVkIHRvIEdBVFQuIEkgY2Fu
IHNlZSBzb21lIG90aGVyDQpwb3NzaWJpbGl0aWVzIGJ1dCBJJ20gY29uZnVzZWQgYnkgdGhlIHN5
c2xvZyByZWxhdGl2ZSB0byB0aGUgYnQgY2FwdHVyZQ0KKGVnLiwgdGhlIHN5c2xvZyBjbGVhcmx5
IHNob3dzIGEgZm91bmQga2V5IGJ1dCB0aGUgaGNpZHVtcCBzaG93cyBsaW5rDQprZXkgbmVnYXRp
dmUgcmVwbHkpLiBXZXJlIHRoZXkgdGFrZW4gYXQgdGhlIHNhbWUgdGltZT8hDQoNClJlZ2FyZHMs
DQpQZXRlcg0KDQpQUyAtIElmIHlvdSBkbyBzZW5kIGFub3RoZXIgaGNpZHVtcCwgcGxlYXNlIHNl
bmQgYSBiaW5hcnkgY2FwdHVyZSAod2l0aA0KdGltZXN0YW1wcykgYXMgeW91IGhhdmUgYW4gb2xk
IHZlcnNpb24gb2YgaGNpZHVtcCB0aGF0IGRvZXNuJ3QgZGVjb2RlDQpub3QtYXV0b21hdGljYWxs
eS1mbHVzaGFibGUgbDJjYXAgcGFja2V0cy4NCg==
SGkgQ29saW4sDQoNCk9uIFRodSwgMjAxMS0wOC0wNCBhdCAwODoxNyAtMDQwMCwgSm9oYW4gSGVk
YmVyZyB3cm90ZToNCj4gSGkgQ29saW4sDQo+IA0KPiBPbiBUaHUsIEF1ZyAwNCwgMjAxMSwgQ29s
aW4gQmVja2luZ2hhbSB3cm90ZToNCj4gPiBJJ2QgbGlrZSB0byBwcm92aWRlIHNvbWUgZmVlZGJh
Y2sgcmVnYXJkaW5nIGEgU2Ftc3VuZyBXRVA0NzUgaGVhZHNldA0KPiA+IHdoaWNoIGZhaWxzIHRv
IGNvbm5lY3QgdG8gbGludXggc3BlY2lmaWNhbGx5Lg0KPiA+IA0KPiA+IFRoZSBVU0IgYmx1ZXRv
b3RoIGFkYXB0ZXIgaXMgYSBNb2RlbDogQmVsa2luIEJMVUVUT09USCBVU0IgK0VEUg0KPiA+IEFE
QVBURVIgdjIuMSBVSEUgd2hpY2ggc3VjY2Vzc2Z1bGx5IGludGVyY29ubmVjdHMgd2l0aCAyIEph
YnJhIGFuZCAxDQo+ID4gUGxhbnRyb25pY3MgaGVhZHNldHMsIHBsdXMgYSBOb2tpYSBFNzEgcGhv
bmUuIFNhbXN1bmcgV0VQNDc1DQo+ID4gc3VjY2Vzc2Z1bGx5IGNvbm5lY3RzIHRvIGEgV2luZG93
cyBYUCBtYWNoaW5lIGFuZCB0byB0aGUgTm9raWEgRTcxLg0KPiA+IA0KPiA+IFVzaW5nIE9wZW5z
dXNlIDExLjQgd2l0aCBjdXN0b20ga2VybmVsIDMuMCBjdXJyZW50bHksIChhbHNvIGZhaWxzDQo+
ID4gd2l0aCAyLjYuMzgpLCBibHVleiA0Ljk2IGFuZCBibHVlZGV2aWwgbWFuYWdlci4NCj4gPiAN
Cj4gPiBTeW1wdG9tcyBhcmUgdGhhdCBibHVlZGV2aWwgc2VlcyB0aGUgaGVhZHNldCBpbiBwYWly
aW5nIG1vZGUgYW5kDQo+ID4gY29ycmVjdGx5IHJldHJpZXZlcyB0aGUgbmFtZSBXRVA0NzUsIGNv
bm5lY3RlZCBidXR0b24gZmxhc2hlcyBncmVlbg0KPiA+IGFuZCB0aGVuIHJldHVybnMgdG8gZ3Jl
eSAobm90IGNvbm5lY3RlZCkuIFdFUDQ3NSBsZWQgY2hhbmdlcyB0bw0KPiA+IGNvbm5lY3RlZCBz
dGF0dXMgYnV0IGJsdWVkZXZpbCBzaG93cyBoZWFkc2V0IG5vdCBjb25uZWN0ZWQgYW5kDQo+ID4g
aGVhZHNldCBkb2VzIG5vdCB3b3JrLg0KPiA+IA0KPiA+IFdpdGggYmx1ZXRvb3RoZCBpbiBkZWJ1
ZyBtb2RlLCBJIGdldCB0aGUgZm9sbG93aW5nIHRyYW5zYWN0aW9ucyBpbg0KPiA+IC92YXIvbG9n
L21lc3NhZ2VzOg0KPiANCj4gVGhlcmUgc2VlbXMgdG8gYmUgc29tZXRoaW5nIHN0cmFuZ2UgZ29p
bmcgb24gd2l0aCB0aGUgc2VjdXJlIHNpbXBsZQ0KPiBwYWlyaW5nIGxvZ2ljLiBGb3Igc29tZSBy
ZWFzb24gdGhlIGluaXRpYWwgbGluayBrZXkgaXNuJ3QgZ29vZCBlbm91Z2gNCj4gKGF1dGggcmVx
dWVzdCArIGxpbmsga2V5IG5lZ2F0aXZlIHJlcGx5IGFmdGVyIHRoZSBpbml0aWFsIGtleSBoYXMg
YmVlbg0KPiBnZW5lcmF0ZWQpIGFuZCB0aGVuIHRoZXJlJ3MgYSB1c2VyIGNvbmZpcm0gbmVnYXRp
dmUgcmVwbHkgZm9yIHRoZSBzZWNvbmQNCj4gYXR0ZW1wdC4gSXQnZCBiZSBnb29kIHRvIGdldCB0
byB0aGUgYm90dG9tIG9mIHRoaXMgYW5kIGZpeCBpdCBwcm9wZXJseSwNCj4gYnV0IG1lYW53aGls
ZSB5b3UgY2FuIHByb2JhYmx5IHdvcmsgYXJvdW5kIHRoaXMgYnkgZGlzYWJsaW5nIFNTUCBvbiB5
b3VyDQo+IHNpZGUgKGhjaWNvbmZpZyBoY2kwIHNzcG1vZGUgMCkgYW5kIHJldHJ5aW5nIHBhaXJp
bmcuDQoNCllvdSdyZSBoYXZpbmcgdGhpcyBwcm9ibGVtIGJlY2F1c2UgdGhlIHJlbW90ZSBkZXZp
Y2Ugc3VwcG9ydHMgU1NQIGJ1dA0Kbm90IE1JVE0gcHJvdGVjdGlvbi4gU29tZSBzb2NrZXQgaXMg
cmVxdWlyaW5nIEJUX1NFQ1VSSVRZX0hJR0ggKHRodXMNCnJlcXVpcmluZyBNSVRNKSAtLSB0aGVy
ZWZvcmUgdGhlIGtlcm5lbCBpcyBjb3JyZWN0bHkgZGlzY29ubmVjdGluZyBhbmQNCnJldHVybmlu
ZyAnQXV0aGVudGljYXRpb24gRmFpbHVyZScgKGFsdGhvdWdoIHJldHVybmluZyAnSW5zdWZmaWNp
ZW50DQpBdXRoZW50aWNhdGlvbicgd291bGQgcHJvYmFibHkgYmUgYmV0dGVyKS4NCg0KSSB0aGlu
ayB0aGUgR0FUVCBicm93c2VyIGlzIGRlbWFuZGluZyBCVF9TRUNVUklUWV9ISUdIIC0tIG5vdCBz
dXJlIHdoeQ0KdGhvdWdoIChJIGRvbid0IHRoaW5rIGl0IG5lZWRzIHRvLiBJJ2xsIGdldCBiYWNr
IHRvIHlvdSBvbiB0aGF0Li4uKQ0KDQpSZWdhcmRzLA0KUGV0ZXINCg==
On 08/04/2011 08:17 AM, Johan Hedberg wrote:
> Hi Colin,
>
> On Thu, Aug 04, 2011, Colin Beckingham wrote:
>> I'd like to provide some feedback regarding a Samsung WEP475 headset
>> which fails to connect to linux specifically.
>>
>> The USB bluetooth adapter is a Model: Belkin BLUETOOTH USB +EDR
>> ADAPTER v2.1 UHE which successfully interconnects with 2 Jabra and 1
>> Plantronics headsets, plus a Nokia E71 phone. Samsung WEP475
>> successfully connects to a Windows XP machine and to the Nokia E71.
>>
>> Using Opensuse 11.4 with custom kernel 3.0 currently, (also fails
>> with 2.6.38), bluez 4.96 and bluedevil manager.
>>
>> Symptoms are that bluedevil sees the headset in pairing mode and
>> correctly retrieves the name WEP475, connected button flashes green
>> and then returns to grey (not connected). WEP475 led changes to
>> connected status but bluedevil shows headset not connected and
>> headset does not work.
>>
>> With bluetoothd in debug mode, I get the following transactions in
>> /var/log/messages:
>
> There seems to be something strange going on with the secure simple
> pairing logic. For some reason the initial link key isn't good enough
> (auth request + link key negative reply after the initial key has been
> generated) and then there's a user confirm negative reply for the second
> attempt. It'd be good to get to the bottom of this and fix it properly,
> but meanwhile you can probably work around this by disabling SSP on your
> side (hciconfig hci0 sspmode 0) and retrying pairing.
>
> Johan
>
Johan, sspmode 0 did have a positive effect. I have now been able to
pair the headset and use it in a pipe arecord to aplay context with good
results at least two times from scratch. Thanks very much.
What further feedback would be useful to developers to track down the
fundamental issue?
--
---
Colin Beckingham
Hi Colin,
On Thu, Aug 04, 2011, Colin Beckingham wrote:
> I'd like to provide some feedback regarding a Samsung WEP475 headset
> which fails to connect to linux specifically.
>
> The USB bluetooth adapter is a Model: Belkin BLUETOOTH USB +EDR
> ADAPTER v2.1 UHE which successfully interconnects with 2 Jabra and 1
> Plantronics headsets, plus a Nokia E71 phone. Samsung WEP475
> successfully connects to a Windows XP machine and to the Nokia E71.
>
> Using Opensuse 11.4 with custom kernel 3.0 currently, (also fails
> with 2.6.38), bluez 4.96 and bluedevil manager.
>
> Symptoms are that bluedevil sees the headset in pairing mode and
> correctly retrieves the name WEP475, connected button flashes green
> and then returns to grey (not connected). WEP475 led changes to
> connected status but bluedevil shows headset not connected and
> headset does not work.
>
> With bluetoothd in debug mode, I get the following transactions in
> /var/log/messages:
There seems to be something strange going on with the secure simple
pairing logic. For some reason the initial link key isn't good enough
(auth request + link key negative reply after the initial key has been
generated) and then there's a user confirm negative reply for the second
attempt. It'd be good to get to the bottom of this and fix it properly,
but meanwhile you can probably work around this by disabling SSP on your
side (hciconfig hci0 sspmode 0) and retrying pairing.
Johan
On 08/04/2011 07:10 AM, Colin Beckingham wrote:
> I'd like to provide some feedback regarding a Samsung WEP475 headset
> which fails to connect to linux specifically.
>
> The USB bluetooth adapter is a Model: Belkin BLUETOOTH USB +EDR ADAPTER
> v2.1 UHE which successfully interconnects with 2 Jabra and 1 Plantronics
> headsets, plus a Nokia E71 phone. Samsung WEP475 successfully connects
> to a Windows XP machine and to the Nokia E71.
>
> Using Opensuse 11.4 with custom kernel 3.0 currently, (also fails with
> 2.6.38), bluez 4.96 and bluedevil manager.
>
> Symptoms are that bluedevil sees the headset in pairing mode and
> correctly retrieves the name WEP475, connected button flashes green and
> then returns to grey (not connected). WEP475 led changes to connected
> status but bluedevil shows headset not connected and headset does not work.
>
> With bluetoothd in debug mode, I get the following transactions in
> /var/log/messages:
>
> Aug 4 06:22:51 linux-xxxx bluetoothd[13227]:
> plugins/hciops.c:conn_complete() status 0x00
> Aug 4 06:22:51 linux-xxxx bluetoothd[13227]:
> src/adapter.c:adapter_get_device() 00:---:47
> Aug 4 06:22:51 linux-xxxx bluetoothd[13227]:
> plugins/hciops.c:remote_features_information() hci0 status 0
> Aug 4 06:22:51 linux-xxxx bluetoothd[13227]:
> plugins/hciops.c:remote_name_information() hci0 status 0
> Aug 4 06:22:51 linux-xxxx bluetoothd[13227]:
> audio/headset.c:headset_set_channel() Discovered Handsfree service on
> channel 2
> Aug 4 06:22:51 linux-xxxx bluetoothd[13227]:
> audio/headset.c:rfcomm_connect() /org/bluez/13226/hci0/dev_00_---_47:
> Connecting to 00:---:47 channel 2
> Aug 4 06:22:51 linux-xxxx bluetoothd[13227]:
> plugins/hciops.c:link_key_request() hci0 dba 00:---:47
> Aug 4 06:22:51 linux-xxxx bluetoothd[13227]:
> plugins/hciops.c:get_auth_info() hci0 dba 00:---:47
> Aug 4 06:22:51 linux-xxxx bluetoothd[13227]:
> plugins/hciops.c:link_key_request() kernel auth requirements = 0x04
> Aug 4 06:22:51 linux-xxxx bluetoothd[13227]:
> plugins/hciops.c:link_key_request() Matching key found
> Aug 4 06:22:51 linux-xxxx bluetoothd[13227]:
> plugins/hciops.c:link_key_request() link key type 0x04
> Aug 4 06:22:51 linux-xxxx bluetoothd[13227]:
> plugins/hciops.c:auth_complete() hci0 status 0
> Aug 4 06:22:51 linux-xxxx bluetoothd[13227]:
> plugins/hciops.c:bonding_complete() status 0x00
> Aug 4 06:22:51 linux-xxxx bluetoothd[13227]:
> src/event.c:btd_event_bonding_complete() status 0x00
> Aug 4 06:22:51 linux-xxxx bluetoothd[13227]:
> src/adapter.c:adapter_get_device() 00:---:47
> Aug 4 06:22:51 linux-xxxx bluetoothd[13227]:
> src/device.c:device_bonding_complete() bonding (nil) status 0x00
> Aug 4 06:22:52 linux-xxxx bluetoothd[13227]: Permission denied (13)
> Aug 4 06:22:52 linux-xxxx bluetoothd[13227]:
> audio/headset.c:headset_set_state() State changed
> /org/bluez/13226/hci0/dev_00_---_47: HEADSET_STATE_CONNECTING ->
> HEADSET_STATE_DISCONNECTED
> Aug 4 06:22:52 linux-xxxx bluetoothd[13227]:
> plugins/hciops.c:disconn_complete() handle 11 status 0x00
> Aug 4 06:22:52 linux-xxxx bluetoothd[13227]:
> src/event.c:btd_event_disconn_complete()
> Aug 4 06:22:52 linux-xxxx bluetoothd[13227]:
> src/adapter.c:adapter_remove_connection()
>
> I have tried clearing the contents of /var/lib/bluetooth/ forcing the
> system to recreate, but no difference.
Attached is hcidump
--
---
Colin Beckingham