Hello
This is an "old" issue that was reported downstream some time ago at:
http://bugs.gentoo.org/show_bug.cgi?id=327705
Getting errors like:
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
Reporter found that the problem with his dongle was introduced in commit
aee26b30bbc24cde464ba1a557c2b258ddec6432 "Make BtIO default security
level MEDIUM", he asked here, on upstream mailing list, but didn't get
any reply clarifying this:
http://marc.info/?l=linux-bluetooth&m=127893935109510&w=2
Thanks a lot for your help :-)
Hi,
On Mon, Sep 20, 2010, Pacho Ramos wrote:
> Reporter found that the problem with his dongle was introduced in commit
> aee26b30bbc24cde464ba1a557c2b258ddec6432 "Make BtIO default security
> level MEDIUM", he asked here, on upstream mailing list, but didn't get
> any reply clarifying this:
> http://marc.info/?l=linux-bluetooth&m=127893935109510&w=2
The important piece of info missing here is an HCI trace of the failure
(i.e. output of hcidump). There was a similar issue reported on IRC a
few days back and the hcidump there revealed a LMP response timeout
after BlueZ issues a HCI_Set_Connection_Encryption command. This would
seem to indicate a bug either in the local adapter or the remote device
(headset). Only an airtrace would really reveal what's going on.
However, I suspect it might be possible to work around this by looking
into possibilities of changing the ordering and timing of when the
kernel sends the encryption request.
Johan
El lun, 18-10-2010 a las 20:24 +0200, Pacho Ramos escribió:
> El lun, 04-10-2010 a las 14:35 +0200, Uwe Kleine-König escribió:
> > Hello Pacho,
> >
> > On Mon, Oct 04, 2010 at 12:25:46PM +0200, Pacho Ramos wrote:
> > > > I would say this was because of double authentication request, but it
> > > > seems it is not the case, actually ssp doesn't seems to be used at all
> > > > here so this must be something else, maybe you should try this:
> > > >
> > > > http://thread.gmane.org/gmane.linux.bluez.kernel/7256
> > > >
> > >
> > > Thanks but, how should I try to apply that patch? Looks like
> > > net/bluetooth/rfcomm/core.c is not present on bluez-4.72 sources
> > I guess this is a patch to apply to your kernel, not bluez.
> >
> > Best regards
> > Uwe
> >
>
> Downstream affected reported told me it's still failing even with the
> patch:
>
> http://bugs.gentoo.org/show_bug.cgi?id=327705#c19
>
> Attached is the new hcidump output
>
> Thanks a lot for your help :-)
>
There is no possible solution to this? :-(
Thanks
El lun, 04-10-2010 a las 14:35 +0200, Uwe Kleine-König escribió:
> Hello Pacho,
>
> On Mon, Oct 04, 2010 at 12:25:46PM +0200, Pacho Ramos wrote:
> > > I would say this was because of double authentication request, but it
> > > seems it is not the case, actually ssp doesn't seems to be used at all
> > > here so this must be something else, maybe you should try this:
> > >
> > > http://thread.gmane.org/gmane.linux.bluez.kernel/7256
> > >
> >
> > Thanks but, how should I try to apply that patch? Looks like
> > net/bluetooth/rfcomm/core.c is not present on bluez-4.72 sources
> I guess this is a patch to apply to your kernel, not bluez.
>
> Best regards
> Uwe
>
Downstream affected reported told me it's still failing even with the
patch:
http://bugs.gentoo.org/show_bug.cgi?id=327705#c19
Attached is the new hcidump output
Thanks a lot for your help :-)
Hello Chetan,
Based on my limited understanding of networking, avahi should
implement DNS-SD on Linux, which is quite close to Microsoft's version
of LLMNR. You may also want to use any other utility that may be
required for supporting Link-local addresses etc on your host distro.
But from Bluez perspective, pand should be really transparent as long
as endpoints TCP/IP stacks support LLMNR or similar variants of LL
name resolution protocols. It is pretty much a TCP/IP stack feature or
so I believe.
Good Luck!
--
Best Regards,
Arun Kumar Singh
http://www.crazydaks.com
On Tue, Oct 5, 2010 at 10:17 AM, Chetankumar Manjegowda
<[email protected]> wrote:
>
> Hi Arun,
> Thanks for your reply.
>
> I am new to networking I am not sure about that.
>
> I want to send LLMNR query so i am planning to use avahi-0.6.27(avahi-autoipd) is this is fine or any other is available ?
>
> Rgds
> Chetan
>
>
> -----Original Message-----
> From: Arun Kumar [mailto:[email protected]]
> Sent: Monday, October 04, 2010 9:06 PM
> To: Chetankumar Manjegowda
> Cc: [email protected]
> Subject: Re: How add support of LLMNR for PAN
>
> Shouldn't this support come from linux ip stack rather than bluez?
>
>
> Best Regards,
> Arun Kumar Singh
> http://www.crazydaks.com
>
>
> On Mon, Oct 4, 2010 at 6:15 PM, Chetankumar Manjegowda
> <[email protected]> wrote:
> >
> > Hi All,
> >
> > I want to know how to enable/Integrate LLMNR for PAN profile.
> >
> > Can anyone give some suggestions or link where I can refer the same ??
> >
> > Rgds
> > Chetan
> >
> > ________________________________
> >
> > http://www.mindtree.com/email/disclaimer.html
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> > the body of a message to [email protected]
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
>
> --
SGkgQXJ1biwNClRoYW5rcyBmb3IgeW91ciByZXBseS4NCg0KSSBhbSBuZXcgdG8gbmV0d29ya2lu
ZyBJIGFtIG5vdCBzdXJlIGFib3V0IHRoYXQuDQoNCkkgd2FudCB0byBzZW5kIExMTU5SIHF1ZXJ5
IHNvIGkgYW0gcGxhbm5pbmcgdG8gdXNlIGF2YWhpLTAuNi4yNyhhdmFoaS1hdXRvaXBkKSBpcyB0
aGlzIGlzIGZpbmUgb3IgYW55IG90aGVyIGlzIGF2YWlsYWJsZSA/DQoNClJnZHMNCkNoZXRhbg0K
DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBBcnVuIEt1bWFyIFttYWlsdG86
YXJ1bmthdEBnbWFpbC5jb21dIA0KU2VudDogTW9uZGF5LCBPY3RvYmVyIDA0LCAyMDEwIDk6MDYg
UE0NClRvOiBDaGV0YW5rdW1hciBNYW5qZWdvd2RhDQpDYzogbGludXgtYmx1ZXRvb3RoQHZnZXIu
a2VybmVsLm9yZw0KU3ViamVjdDogUmU6IEhvdyBhZGQgc3VwcG9ydCBvZiBMTE1OUiBmb3IgUEFO
DQoNClNob3VsZG4ndCB0aGlzIHN1cHBvcnQgY29tZSBmcm9tIGxpbnV4IGlwIHN0YWNrIHJhdGhl
ciB0aGFuIGJsdWV6Pw0KDQoNCkJlc3QgUmVnYXJkcywNCkFydW4gS3VtYXIgU2luZ2gNCnd3dy5j
cmF6eWRha3MuY29tDQoNCg0KT24gTW9uLCBPY3QgNCwgMjAxMCBhdCA2OjE1IFBNLCBDaGV0YW5r
dW1hciBNYW5qZWdvd2RhDQo8Q2hldGFua3VtYXJfTWFuamVnb3dkYUBtaW5kdHJlZS5jb20+IHdy
b3RlOg0KPg0KPiBIaSBBbGwsDQo+DQo+IEkgd2FudCB0byBrbm93IGhvdyB0byBlbmFibGUvSW50
ZWdyYXRlIExMTU5SIGZvciBQQU4gcHJvZmlsZS4NCj4NCj4gQ2FuIGFueW9uZSBnaXZlIHNvbWUg
c3VnZ2VzdGlvbnMgb3IgbGluayB3aGVyZSBJIGNhbiByZWZlciB0aGUgc2FtZSA/Pw0KPg0KPiBS
Z2RzDQo+IENoZXRhbg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPg0K
PiBodHRwOi8vd3d3Lm1pbmR0cmVlLmNvbS9lbWFpbC9kaXNjbGFpbWVyLmh0bWwNCj4gLS0NCj4g
VG8gdW5zdWJzY3JpYmUgZnJvbSB0aGlzIGxpc3Q6IHNlbmQgdGhlIGxpbmUgInVuc3Vic2NyaWJl
IGxpbnV4LWJsdWV0b290aCIgaW4NCj4gdGhlIGJvZHkgb2YgYSBtZXNzYWdlIHRvIG1ham9yZG9t
b0B2Z2VyLmtlcm5lbC5vcmcNCj4gTW9yZSBtYWpvcmRvbW8gaW5mbyBhdCDCoGh0dHA6Ly92Z2Vy
Lmtlcm5lbC5vcmcvbWFqb3Jkb21vLWluZm8uaHRtbA0KDQoNCg0KLS0NCg==
Shouldn't this support come from linux ip stack rather than bluez?
Best Regards,
Arun Kumar Singh
http://www.crazydaks.com
On Mon, Oct 4, 2010 at 6:15 PM, Chetankumar Manjegowda
<[email protected]> wrote:
>
> Hi All,
>
> I want to know how to enable/Integrate LLMNR for PAN profile.
>
> Can anyone give some suggestions or link where I can refer the same ??
>
> Rgds
> Chetan
>
> ________________________________
>
> http://www.mindtree.com/email/disclaimer.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Hi All,
I want to know how to enable/Integrate LLMNR for PAN profile.
Can anyone give some suggestions or link where I can refer the same ??
Rgds
Chetan
________________________________
http://www.mindtree.com/email/disclaimer.html
Hello Pacho,
On Mon, Oct 04, 2010 at 12:25:46PM +0200, Pacho Ramos wrote:
> > I would say this was because of double authentication request, but it
> > seems it is not the case, actually ssp doesn't seems to be used at all
> > here so this must be something else, maybe you should try this:
> >
> > http://thread.gmane.org/gmane.linux.bluez.kernel/7256
> >
>
> Thanks but, how should I try to apply that patch? Looks like
> net/bluetooth/rfcomm/core.c is not present on bluez-4.72 sources
I guess this is a patch to apply to your kernel, not bluez.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
El lun, 04-10-2010 a las 13:00 +0300, Luiz Augusto von Dentz escribió:
> Hi,
>
> On Sat, Oct 2, 2010 at 4:58 PM, Pacho Ramos
> <[email protected]> wrote:
> > El lun, 20-09-2010 a las 21:49 +0300, Johan Hedberg escribió:
> >> Hi,
> >>
> >> On Mon, Sep 20, 2010, Pacho Ramos wrote:
> >> > Reporter found that the problem with his dongle was introduced in commit
> >> > aee26b30bbc24cde464ba1a557c2b258ddec6432 "Make BtIO default security
> >> > level MEDIUM", he asked here, on upstream mailing list, but didn't get
> >> > any reply clarifying this:
> >> > http://marc.info/?l=linux-bluetooth&m=127893935109510&w=2
> >>
> >> The important piece of info missing here is an HCI trace of the failure
> >> (i.e. output of hcidump). There was a similar issue reported on IRC a
> >> few days back and the hcidump there revealed a LMP response timeout
> >> after BlueZ issues a HCI_Set_Connection_Encryption command. This would
> >> seem to indicate a bug either in the local adapter or the remote device
> >> (headset). Only an airtrace would really reveal what's going on.
> >> However, I suspect it might be possible to work around this by looking
> >> into possibilities of changing the ordering and timing of when the
> >> kernel sends the encryption request.
> >>
> >> Johan
> >>
> >
> > Sorry for the delay but downstream reporter wasn't able to provide the
> > information sooner.
> >
> > Attached is hcidump output, I hope it helps :-)
>
> I would say this was because of double authentication request, but it
> seems it is not the case, actually ssp doesn't seems to be used at all
> here so this must be something else, maybe you should try this:
>
> http://thread.gmane.org/gmane.linux.bluez.kernel/7256
>
Thanks but, how should I try to apply that patch? Looks like
net/bluetooth/rfcomm/core.c is not present on bluez-4.72 sources
Best regards
Hi,
On Sat, Oct 2, 2010 at 4:58 PM, Pacho Ramos
<[email protected]> wrote:
> El lun, 20-09-2010 a las 21:49 +0300, Johan Hedberg escribi?:
>> Hi,
>>
>> On Mon, Sep 20, 2010, Pacho Ramos wrote:
>> > Reporter found that the problem with his dongle was introduced in commit
>> > aee26b30bbc24cde464ba1a557c2b258ddec6432 "Make BtIO default security
>> > level MEDIUM", he asked here, on upstream mailing list, but didn't get
>> > any reply clarifying this:
>> > http://marc.info/?l=linux-bluetooth&m=127893935109510&w=2
>>
>> The important piece of info missing here is an HCI trace of the failure
>> (i.e. output of hcidump). There was a similar issue reported on IRC a
>> few days back and the hcidump there revealed a LMP response timeout
>> after BlueZ issues a HCI_Set_Connection_Encryption command. This would
>> seem to indicate a bug either in the local adapter or the remote device
>> (headset). Only an airtrace would really reveal what's going on.
>> However, I suspect it might be possible to work around this by looking
>> into possibilities of changing the ordering and timing of when the
>> kernel sends the encryption request.
>>
>> Johan
>>
>
> Sorry for the delay but downstream reporter wasn't able to provide the
> information sooner.
>
> Attached is hcidump output, I hope it helps :-)
I would say this was because of double authentication request, but it
seems it is not the case, actually ssp doesn't seems to be used at all
here so this must be something else, maybe you should try this:
http://thread.gmane.org/gmane.linux.bluez.kernel/7256
--
Luiz Augusto von Dentz
Computer Engineer
El lun, 20-09-2010 a las 21:49 +0300, Johan Hedberg escribió:
> Hi,
>
> On Mon, Sep 20, 2010, Pacho Ramos wrote:
> > Reporter found that the problem with his dongle was introduced in commit
> > aee26b30bbc24cde464ba1a557c2b258ddec6432 "Make BtIO default security
> > level MEDIUM", he asked here, on upstream mailing list, but didn't get
> > any reply clarifying this:
> > http://marc.info/?l=linux-bluetooth&m=127893935109510&w=2
>
> The important piece of info missing here is an HCI trace of the failure
> (i.e. output of hcidump). There was a similar issue reported on IRC a
> few days back and the hcidump there revealed a LMP response timeout
> after BlueZ issues a HCI_Set_Connection_Encryption command. This would
> seem to indicate a bug either in the local adapter or the remote device
> (headset). Only an airtrace would really reveal what's going on.
> However, I suspect it might be possible to work around this by looking
> into possibilities of changing the ordering and timing of when the
> kernel sends the encryption request.
>
> Johan
>
Sorry for the delay but downstream reporter wasn't able to provide the
information sooner.
Attached is hcidump output, I hope it helps :-)
Thanks a lot
Hi Pacho,
On Sun, 2010-10-31 at 12:25 +0100, Pacho Ramos wrote:
> El lun, 18-10-2010 a las 20:24 +0200, Pacho Ramos escribi?:
> > El lun, 04-10-2010 a las 14:35 +0200, Uwe Kleine-K?nig escribi?:
> > > Hello Pacho,
> > >
> > > On Mon, Oct 04, 2010 at 12:25:46PM +0200, Pacho Ramos wrote:
> > > > > I would say this was because of double authentication request, but it
> > > > > seems it is not the case, actually ssp doesn't seems to be used at all
> > > > > here so this must be something else, maybe you should try this:
> > > > >
> > > > > http://thread.gmane.org/gmane.linux.bluez.kernel/7256
> > > > >
> > > >
> > > > Thanks but, how should I try to apply that patch? Looks like
> > > > net/bluetooth/rfcomm/core.c is not present on bluez-4.72 sources
> > > I guess this is a patch to apply to your kernel, not bluez.
> > >
> > > Best regards
> > > Uwe
> > >
> >
> > Downstream affected reported told me it's still failing even with the
> > patch:
> >
> > http://bugs.gentoo.org/show_bug.cgi?id=327705#c19
> >
> > Attached is the new hcidump output
> >
> > Thanks a lot for your help :-)
> >
>
> There is no possible solution to this? :-(
>
> Thanks
The hcidump output reported is unfortunately insufficient to determine
the actual cause of failure. The indicated cause of failure appears to
be an error return from the Set Connection Encryption cmd (as indicated
by the absence of an Encryption Change evt). The actual error code is
not indicated in the hcidump output -- really, 'hcidump -tVx' is more
helpful for troubleshooting remotely.
The "Function not implemented (38)" message (which is in the bluetoothd
output capture in the downstream report) is the kernel bt stack's
translation to errno for bluetooth error codes primarily associated with
piconet errors (like Reserved Slot Violation(s), LMP Response Timeout,
etc. Actually, it's a catchall for errors the kernel bt stack thinks it
can't really do anything about).
Although I'd be happy to take a look at a more complete hcidump, the
reality is that there are bluetooth device incompatibilities/bugs that
are often unfixable - even when the hardware's available. My own bt
dongle reports that it's eSCO capable but hangs the LM when actually
attempting to negotiate an eSCO connection.
Hope that helps,
Peter Hurley