HCI data payload not getting through when using BlueZ

HCI data payload not getting through when using BlueZ

[Eponymous -]

[-- Attachment #1: Type: text/plain, Size: 848 bytes --]

Hi,

I've ran into an issue where data doesn't seem to be received by a slave device.

I do the following:

Using Gentoo Linux (2.6.34-gentoo-r1)
Using BlueZ 4.81

1. Use BlueZ to connect to two Bluetooth devices using HCI only. This
is over USB.

2. I set one device as a slave and then create a connection between
the two. This completes sucessfully and can be seen on both sides.

3. I then try to send an acl packet with the word "hi" in it and it is
not received on the other side.

--------

Doing the same thing above but:

Using Fedora Core 5 (2.6.20-1.2320.fc5)
And:
bluez-libs-2.25-1
bluez-pin-0.30-2
bluez-utils-2.25-4
bluez-libs-devel-2.25-1
bluez-hcidump-1.30-1

and using the same hardware - the problem doesn't happen.

I have attached two HCI dumps, one of the Master device and one of the Slave.

Thanks for any help you can give.

[-- Attachment #2: master.out --]
[-- Type: application/octet-stream, Size: 157 bytes --]

[-- Attachment #3: slave.out --]
[-- Type: application/octet-stream, Size: 181 bytes --]

Re: HCI data payload not getting through when using BlueZ

[Gustavo F. Padovan]

* Eponymous - <the.epon@gmail.com> [2011-05-11 09:52:28 +0100]:

> Hi,
> 
> I've ran into an issue where data doesn't seem to be received by a slave device.
> 
> I do the following:
> 
> Using Gentoo Linux (2.6.34-gentoo-r1)
> Using BlueZ 4.81
> 
> 1. Use BlueZ to connect to two Bluetooth devices using HCI only. This
> is over USB.
> 
> 2. I set one device as a slave and then create a connection between
> the two. This completes sucessfully and can be seen on both sides.
> 
> 3. I then try to send an acl packet with the word "hi" in it and it is
> not received on the other side.

There a utility called l2test in the bluez sources. Check if it works for you.
Using -r in one side to listen and -s in the other side to send data. Or
l2test -h and see all options.

-- 
Gustavo F. Padovan
http://profusion.mobi

Re: HCI data payload not getting through when using BlueZ

[Eponymous -]

Hi,

I've just downloaded the 4.91 sources and done a make and the only
program I can see starting "l2" is "l2ping". There is no l2test.


On Wed, May 11, 2011 at 5:47 PM, Gustavo F. Padovan
<padovan@profusion.mobi> wrote:
> * Eponymous - <the.epon@gmail.com> [2011-05-11 09:52:28 +0100]:
>
>> Hi,
>>
>> I've ran into an issue where data doesn't seem to be received by a slave device.
>>
>> I do the following:
>>
>> Using Gentoo Linux (2.6.34-gentoo-r1)
>> Using BlueZ 4.81
>>
>> 1. Use BlueZ to connect to two Bluetooth devices using HCI only. This
>> is over USB.
>>
>> 2. I set one device as a slave and then create a connection between
>> the two. This completes sucessfully and can be seen on both sides.
>>
>> 3. I then try to send an acl packet with the word "hi" in it and it is
>> not received on the other side.
>
> There a utility called l2test in the bluez sources. Check if it works for you.
> Using -r in one side to listen and -s in the other side to send data. Or
> l2test -h and see all options.
>
> --
> Gustavo F. Padovan
> http://profusion.mobi
>

Re: HCI data payload not getting through when using BlueZ

[Eponymous -]

Can someone please advise me further on this please? There is no
binary called "l2test" in the 4.91 sources. It's crucial I get this
problem remedied as I can't send data between two HCI devices. This
could be a bug in BlueZ...


On Thu, May 12, 2011 at 11:19 AM, Eponymous - <the.epon@gmail.com> wrote:
> Hi,
>
> I've just downloaded the 4.91 sources and done a make and the only
> program I can see starting "l2" is "l2ping". There is no l2test.
>
>
> On Wed, May 11, 2011 at 5:47 PM, Gustavo F. Padovan
> <padovan@profusion.mobi> wrote:
>> * Eponymous - <the.epon@gmail.com> [2011-05-11 09:52:28 +0100]:
>>
>>> Hi,
>>>
>>> I've ran into an issue where data doesn't seem to be received by a slave device.
>>>
>>> I do the following:
>>>
>>> Using Gentoo Linux (2.6.34-gentoo-r1)
>>> Using BlueZ 4.81
>>>
>>> 1. Use BlueZ to connect to two Bluetooth devices using HCI only. This
>>> is over USB.
>>>
>>> 2. I set one device as a slave and then create a connection between
>>> the two. This completes sucessfully and can be seen on both sides.
>>>
>>> 3. I then try to send an acl packet with the word "hi" in it and it is
>>> not received on the other side.
>>
>> There a utility called l2test in the bluez sources. Check if it works for you.
>> Using -r in one side to listen and -s in the other side to send data. Or
>> l2test -h and see all options.
>>
>> --
>> Gustavo F. Padovan
>> http://profusion.mobi
>>
>

RE: HCI data payload not getting through when using BlueZ

[Suraj Sumangala]

Hi,
________________________________________
From: linux-bluetooth-owner@vger.kernel.org [linux-bluetooth-owner@vger.kernel.org] On Behalf Of Eponymous - [the.epon@gmail.com]
Sent: Friday, May 13, 2011 1:24 PM
To: Eponymous -; linux-bluetooth@vger.kernel.org
Subject: Re: HCI data payload not getting through when using BlueZ

Can someone please advise me further on this please? There is no
binary called "l2test" in the 4.91 sources. It's crucial I get this
problem remedied as I can't send data between two HCI devices. This
could be a bug in BlueZ...


On Thu, May 12, 2011 at 11:19 AM, Eponymous - <the.epon@gmail.com> wrote:
> Hi,
>
> I've just downloaded the 4.91 sources and done a make and the only
> program I can see starting "l2" is "l2ping". There is no l2test.
>
>
> On Wed, May 11, 2011 at 5:47 PM, Gustavo F. Padovan
> <padovan@profusion.mobi> wrote:
>> * Eponymous - <the.epon@gmail.com> [2011-05-11 09:52:28 +0100]:
>>
>>> Hi,
>>>
>>> I've ran into an issue where data doesn't seem to be received by a slave device.
>>>
>>> I do the following:
>>>
>>> Using Gentoo Linux (2.6.34-gentoo-r1)
>>> Using BlueZ 4.81
>>>
>>> 1. Use BlueZ to connect to two Bluetooth devices using HCI only. This
>>> is over USB.
>>>
>>> 2. I set one device as a slave and then create a connection between
>>> the two. This completes sucessfully and can be seen on both sides.
>>>
>>> 3. I then try to send an acl packet with the word "hi" in it and it is
>>> not received on the other side.
>>
>> There a utility called l2test in the bluez sources. Check if it works for you.
>> Using -r in one side to listen and -s in the other side to send data. Or
>> l2test -h and see all options.
>>
>> --
>> Gustavo F. Padovan
>> http://profusion.mobi
>>
>

You have to enable it in the cofigure file and change "test_enable" from "no" to "yes".
Edit the file "configure", search for "test_enable"
change "test_enable=no" to "test_enable=yes"

That is what I do to enable l2test. I guess there could be some other cleaner way to do it.

Regards
Suraj
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: HCI data payload not getting through when using BlueZ

[Mika Linnanoja]

On 05/13/2011 11:13 AM, ext Suraj Sumangala wrote:
> You have to enable it in the cofigure file and change "test_enable" from "no" to "yes".
> Edit the file "configure", search for "test_enable"
> change "test_enable=no" to "test_enable=yes"
>
> That is what I do to enable l2test. I guess there could be some other cleaner way to do it.

./configure --help :)

If you pull from the git repo ./bootstrap-configure already enables most of them.

Although lately configure is often *not* complaining if something is missing 
from build dependencies, have to do a bit of trial & error to get it right.

This is very easy to notice when trying to 'make' bluez on a clean system 
where it hasn't ever been built before.

Cheers,
Mika

Fwd: HCI data payload not getting through when using BlueZ

[Eponymous -]

The following were executed in a root shell.

Receive Side (Device B):

$ ./l2test -r 00:02:5B:00:31:21
l2test[29219]: Waiting for connection on psm 4113 ...

Transmit Side (Device A):

$ ./l2test -s -b 10 00:02:5B:01:FE:DF
l2test[29234]: Can't connect: Permission denied (13)
$ ./l2test -s -b 10 00:02:5B:01:FE:DF
l2test[29311]: Can't connect: Connection refused (111)
$ ./l2test -s -b 10 00:02:5B:01:FE:DF
l2test[29326]: Can't connect: Connection refused (111)
$ ./l2test -s -b 10 00:02:5B:01:FE:DF
l2test[29401]: Can't connect: Permission denied (13)
$ ./l2test -s -b 10 00:02:5B:01:FE:DF
l2test[29478]: Can't connect: Connection refused (111)
$ ./l2test -s -b 10 00:02:5B:01:FE:DF
l2test[29493]: Can't connect: Connection refused (111)

Doesn't appear to work...

On Fri, May 13, 2011 at 9:39 AM, Eponymous - <the.epon@gmail.com> wrote:
> What format do you specify the bdaddr in ?
>
> Cheers.
>
> On Fri, May 13, 2011 at 9:26 AM, Mika Linnanoja
> <mika.linnanoja@nokia.com> wrote:
>> On 05/13/2011 11:13 AM, ext Suraj Sumangala wrote:
>>>
>>> You have to enable it in the cofigure file and change "test_enable" from
>>> "no" to "yes".
>>> Edit the file "configure", search for "test_enable"
>>> change "test_enable=no" to "test_enable=yes"
>>>
>>> That is what I do to enable l2test. I guess there could be some other
>>> cleaner way to do it.
>>
>> ./configure --help :)
>>
>> If you pull from the git repo ./bootstrap-configure already enables most of
>> them.
>>
>> Although lately configure is often *not* complaining if something is missing
>> from build dependencies, have to do a bit of trial & error to get it right.
>>
>> This is very easy to notice when trying to 'make' bluez on a clean system
>> where it hasn't ever been built before.
>>
>> Cheers,
>> Mika
>>
>

Re: HCI data payload not getting through when using BlueZ

[Eponymous -]

OK guys,

I had a theory that my l2test test was not working due to the fact
that the chip wasn't configured to work with upperlayers. After
enabling this however, the  devices disappear (in hciconfig) so I
can't really test any L2CAP stuff (which I assume is what l2test is
doing).

Are there any other things I can try to help debug this issue I've seen?

Thankyou.

On Fri, May 13, 2011 at 1:42 PM, Eponymous - <the.epon@gmail.com> wrote:
> The following were executed in a root shell.
>
> Receive Side (Device B):
>
> $ ./l2test -r 00:02:5B:00:31:21
> l2test[29219]: Waiting for connection on psm 4113 ...
>
> Transmit Side (Device A):
>
> $ ./l2test -s -b 10 00:02:5B:01:FE:DF
> l2test[29234]: Can't connect: Permission denied (13)
> $ ./l2test -s -b 10 00:02:5B:01:FE:DF
> l2test[29311]: Can't connect: Connection refused (111)
> $ ./l2test -s -b 10 00:02:5B:01:FE:DF
> l2test[29326]: Can't connect: Connection refused (111)
> $ ./l2test -s -b 10 00:02:5B:01:FE:DF
> l2test[29401]: Can't connect: Permission denied (13)
> $ ./l2test -s -b 10 00:02:5B:01:FE:DF
> l2test[29478]: Can't connect: Connection refused (111)
> $ ./l2test -s -b 10 00:02:5B:01:FE:DF
> l2test[29493]: Can't connect: Connection refused (111)
>
> Doesn't appear to work...
>
> On Fri, May 13, 2011 at 9:39 AM, Eponymous - <the.epon@gmail.com> wrote:
>> What format do you specify the bdaddr in ?
>>
>> Cheers.
>>
>> On Fri, May 13, 2011 at 9:26 AM, Mika Linnanoja
>> <mika.linnanoja@nokia.com> wrote:
>>> On 05/13/2011 11:13 AM, ext Suraj Sumangala wrote:
>>>>
>>>> You have to enable it in the cofigure file and change "test_enable" from
>>>> "no" to "yes".
>>>> Edit the file "configure", search for "test_enable"
>>>> change "test_enable=no" to "test_enable=yes"
>>>>
>>>> That is what I do to enable l2test. I guess there could be some other
>>>> cleaner way to do it.
>>>
>>> ./configure --help :)
>>>
>>> If you pull from the git repo ./bootstrap-configure already enables most of
>>> them.
>>>
>>> Although lately configure is often *not* complaining if something is missing
>>> from build dependencies, have to do a bit of trial & error to get it right.
>>>
>>> This is very easy to notice when trying to 'make' bluez on a clean system
>>> where it hasn't ever been built before.
>>>
>>> Cheers,
>>> Mika
>>>
>>
>

Re: HCI data payload not getting through when using BlueZ

[Anderson Lizardo]

Hi,

On Mon, May 16, 2011 at 6:36 AM, Eponymous - <the.epon@gmail.com> wrote:
> OK guys,
>
> I had a theory that my l2test test was not working due to the fact
> that the chip wasn't configured to work with upperlayers. After
> enabling this however, the  devices disappear (in hciconfig) so I
> can't really test any L2CAP stuff (which I assume is what l2test is
> doing).
>
> Are there any other things I can try to help debug this issue I've seen?

What is the chipset of your USB dongles ? A "lsusb -d <vid>:<pid>" and
relevant output from dmesg might help here.

What do you mean by "the chip wasn't configured to work with
upperlayers" ? Was the chipset in a mode which was not HCI compliant?

Keep in mind that there are development/prototype USB dongles which
are in fact serial/FTDI devices, and thus require using hciattach to
be able to use them in BlueZ.

Regards,
-- 
Anderson Lizardo
Instituto Nokia de Tecnologia - INdT
Manaus - Brazil

Re: HCI data payload not getting through when using BlueZ

[Eponymous -]

The chips are CSR Bluecores. In order to get upperlayers access rather
 than HCI over USB you have to configure a key in the firmware.

As soon as I enable upperlayers access the devices disappear from hciconfig.

On Mon, May 16, 2011 at 1:17 PM, Anderson Lizardo
<anderson.lizardo@openbossa.org> wrote:
> Hi,
>
> On Mon, May 16, 2011 at 6:36 AM, Eponymous - <the.epon@gmail.com> wrote:
>> OK guys,
>>
>> I had a theory that my l2test test was not working due to the fact
>> that the chip wasn't configured to work with upperlayers. After
>> enabling this however, the  devices disappear (in hciconfig) so I
>> can't really test any L2CAP stuff (which I assume is what l2test is
>> doing).
>>
>> Are there any other things I can try to help debug this issue I've seen?
>
> What is the chipset of your USB dongles ? A "lsusb -d <vid>:<pid>" and
> relevant output from dmesg might help here.
>
> What do you mean by "the chip wasn't configured to work with
> upperlayers" ? Was the chipset in a mode which was not HCI compliant?
>
> Keep in mind that there are development/prototype USB dongles which
> are in fact serial/FTDI devices, and thus require using hciattach to
> be able to use them in BlueZ.
>
> Regards,
> --
> Anderson Lizardo
> Instituto Nokia de Tecnologia - INdT
> Manaus - Brazil
>

Re: HCI data payload not getting through when using BlueZ

[Anderson Lizardo]

Hi,

On Tue, May 17, 2011 at 3:13 AM, Eponymous - <the.epon@gmail.com> wrote:
> The chips are CSR Bluecores. In order to get upperlayers access rather
>  than HCI over USB you have to configure a key in the firmware.
>
> As soon as I enable upperlayers access the devices disappear from hciconfig.

As I said, there are various development/prototype devices out there
that use UART (usually CDC ACM or FTDI over USB) transport instead of
"plain" USB. If you post the relevant lines from "dmesg" and "lsusb"
somewhere (after you configure the firmware key), we might be able to
identify the transport.

For UART, you need to use hciattach on a e.g. /dev/ttyUSBX device
created when plugging the device.

HTH,
-- 
Anderson Lizardo
Instituto Nokia de Tecnologia - INdT
Manaus - Brazil

Re: HCI data payload not getting through when using BlueZ

[Eponymous -]

lsusb:

Bus 001 Device 041: ID 0a12:0001 Cambridge Silicon Radio, Ltd
Bluetooth Dongle (HCI mode)
Bus 001 Device 040: ID 0a12:0001 Cambridge Silicon Radio, Ltd
Bluetooth Dongle (HCI mode)

These are definitely plain USB devices. There is no /dev/ttyUSBxx like
you would get with the FTDI USB->Serial converters.

I've checked over dmesg and the messages (of which there are many
since I have eight of these devices) says they are USB.

I don't want to become sidetracked from the issue though. Is there
anyway to debug this issue without using l2test or any other
upperlayers program? The issue I have seen was at the HCI level
remember so I'm thinking introducing the upperlayers is going to make
things unnecessarily complicated.

Cheers.


On Tue, May 17, 2011 at 12:50 PM, Anderson Lizardo
<anderson.lizardo@openbossa.org> wrote:
> Hi,
>
> On Tue, May 17, 2011 at 3:13 AM, Eponymous - <the.epon@gmail.com> wrote:
>> The chips are CSR Bluecores. In order to get upperlayers access rather
>>  than HCI over USB you have to configure a key in the firmware.
>>
>> As soon as I enable upperlayers access the devices disappear from hciconfig.
>
> As I said, there are various development/prototype devices out there
> that use UART (usually CDC ACM or FTDI over USB) transport instead of
> "plain" USB. If you post the relevant lines from "dmesg" and "lsusb"
> somewhere (after you configure the firmware key), we might be able to
> identify the transport.
>
> For UART, you need to use hciattach on a e.g. /dev/ttyUSBX device
> created when plugging the device.
>
> HTH,
> --
> Anderson Lizardo
> Instituto Nokia de Tecnologia - INdT
> Manaus - Brazil
>

Fwd: HCI data payload not getting through when using BlueZ

[Eponymous -]

Anyone got any ideas or have we given up on this?

Cheers.

On Tue, May 17, 2011 at 1:45 PM, Eponymous - <the.epon@gmail.com> wrote:
> lsusb:
>
> Bus 001 Device 041: ID 0a12:0001 Cambridge Silicon Radio, Ltd
> Bluetooth Dongle (HCI mode)
> Bus 001 Device 040: ID 0a12:0001 Cambridge Silicon Radio, Ltd
> Bluetooth Dongle (HCI mode)
>
> These are definitely plain USB devices. There is no /dev/ttyUSBxx like
> you would get with the FTDI USB->Serial converters.
>
> I've checked over dmesg and the messages (of which there are many
> since I have eight of these devices) says they are USB.
>
> I don't want to become sidetracked from the issue though. Is there
> anyway to debug this issue without using l2test or any other
> upperlayers program? The issue I have seen was at the HCI level
> remember so I'm thinking introducing the upperlayers is going to make
> things unnecessarily complicated.
>
> Cheers.
>
>
> On Tue, May 17, 2011 at 12:50 PM, Anderson Lizardo
> <anderson.lizardo@openbossa.org> wrote:
>> Hi,
>>
>> On Tue, May 17, 2011 at 3:13 AM, Eponymous - <the.epon@gmail.com> wrote:
>>> The chips are CSR Bluecores. In order to get upperlayers access rather
>>>  than HCI over USB you have to configure a key in the firmware.
>>>
>>> As soon as I enable upperlayers access the devices disappear from hciconfig.
>>
>> As I said, there are various development/prototype devices out there
>> that use UART (usually CDC ACM or FTDI over USB) transport instead of
>> "plain" USB. If you post the relevant lines from "dmesg" and "lsusb"
>> somewhere (after you configure the firmware key), we might be able to
>> identify the transport.
>>
>> For UART, you need to use hciattach on a e.g. /dev/ttyUSBX device
>> created when plugging the device.
>>
>> HTH,
>> --
>> Anderson Lizardo
>> Instituto Nokia de Tecnologia - INdT
>> Manaus - Brazil
>>
>

Re: HCI data payload not getting through when using BlueZ

[Eponymous -]

Ok well this has been a complete waste of time. I guess we should just
ignore a potential bug then,...

Is this project dead or something? I can't believe an entire mailing
list can't be bothered to even e-mail back or try and help with this.

On Tue, May 24, 2011 at 9:12 AM, Eponymous - <the.epon@gmail.com> wrote:
> Anyone got any ideas or have we given up on this?
>
> Cheers.
>
> On Tue, May 17, 2011 at 1:45 PM, Eponymous - <the.epon@gmail.com> wrote:
>> lsusb:
>>
>> Bus 001 Device 041: ID 0a12:0001 Cambridge Silicon Radio, Ltd
>> Bluetooth Dongle (HCI mode)
>> Bus 001 Device 040: ID 0a12:0001 Cambridge Silicon Radio, Ltd
>> Bluetooth Dongle (HCI mode)
>>
>> These are definitely plain USB devices. There is no /dev/ttyUSBxx like
>> you would get with the FTDI USB->Serial converters.
>>
>> I've checked over dmesg and the messages (of which there are many
>> since I have eight of these devices) says they are USB.
>>
>> I don't want to become sidetracked from the issue though. Is there
>> anyway to debug this issue without using l2test or any other
>> upperlayers program? The issue I have seen was at the HCI level
>> remember so I'm thinking introducing the upperlayers is going to make
>> things unnecessarily complicated.
>>
>> Cheers.
>>
>>
>> On Tue, May 17, 2011 at 12:50 PM, Anderson Lizardo
>> <anderson.lizardo@openbossa.org> wrote:
>>> Hi,
>>>
>>> On Tue, May 17, 2011 at 3:13 AM, Eponymous - <the.epon@gmail.com> wrote:
>>>> The chips are CSR Bluecores. In order to get upperlayers access rather
>>>>  than HCI over USB you have to configure a key in the firmware.
>>>>
>>>> As soon as I enable upperlayers access the devices disappear from hciconfig.
>>>
>>> As I said, there are various development/prototype devices out there
>>> that use UART (usually CDC ACM or FTDI over USB) transport instead of
>>> "plain" USB. If you post the relevant lines from "dmesg" and "lsusb"
>>> somewhere (after you configure the firmware key), we might be able to
>>> identify the transport.
>>>
>>> For UART, you need to use hciattach on a e.g. /dev/ttyUSBX device
>>> created when plugging the device.
>>>
>>> HTH,
>>> --
>>> Anderson Lizardo
>>> Instituto Nokia de Tecnologia - INdT
>>> Manaus - Brazil
>>>
>>
>

Re: HCI data payload not getting through when using BlueZ

[Peter Hurley]

T24gV2VkLCAyMDExLTA1LTExIGF0IDA0OjUyIC0wNDAwLCBFcG9ueW1vdXMgLSB3cm90ZToNCj4g
SGksDQo+IA0KPiBJJ3ZlIHJhbiBpbnRvIGFuIGlzc3VlIHdoZXJlIGRhdGEgZG9lc24ndCBzZWVt
IHRvIGJlIHJlY2VpdmVkIGJ5IGEgc2xhdmUgZGV2aWNlLg0KPiANCj4gSSBkbyB0aGUgZm9sbG93
aW5nOg0KPiANCj4gVXNpbmcgR2VudG9vIExpbnV4ICgyLjYuMzQtZ2VudG9vLXIxKQ0KPiBVc2lu
ZyBCbHVlWiA0LjgxDQo+IA0KPiAxLiBVc2UgQmx1ZVogdG8gY29ubmVjdCB0byB0d28gQmx1ZXRv
b3RoIGRldmljZXMgdXNpbmcgSENJIG9ubHkuIFRoaXMNCj4gaXMgb3ZlciBVU0IuDQo+IA0KPiAy
LiBJIHNldCBvbmUgZGV2aWNlIGFzIGEgc2xhdmUgYW5kIHRoZW4gY3JlYXRlIGEgY29ubmVjdGlv
biBiZXR3ZWVuDQo+IHRoZSB0d28uIFRoaXMgY29tcGxldGVzIHN1Y2Vzc2Z1bGx5IGFuZCBjYW4g
YmUgc2VlbiBvbiBib3RoIHNpZGVzLg0KPiANCj4gMy4gSSB0aGVuIHRyeSB0byBzZW5kIGFuIGFj
bCBwYWNrZXQgd2l0aCB0aGUgd29yZCAiaGkiIGluIGl0IGFuZCBpdCBpcw0KPiBub3QgcmVjZWl2
ZWQgb24gdGhlIG90aGVyIHNpZGUuDQo+IA0KPiAtLS0tLS0tLQ0KPiANCj4gRG9pbmcgdGhlIHNh
bWUgdGhpbmcgYWJvdmUgYnV0Og0KPiANCj4gVXNpbmcgRmVkb3JhIENvcmUgNSAoMi42LjIwLTEu
MjMyMC5mYzUpDQo+IEFuZDoNCj4gYmx1ZXotbGlicy0yLjI1LTENCj4gYmx1ZXotcGluLTAuMzAt
Mg0KPiBibHVlei11dGlscy0yLjI1LTQNCj4gYmx1ZXotbGlicy1kZXZlbC0yLjI1LTENCj4gYmx1
ZXotaGNpZHVtcC0xLjMwLTENCj4gDQo+IGFuZCB1c2luZyB0aGUgc2FtZSBoYXJkd2FyZSAtIHRo
ZSBwcm9ibGVtIGRvZXNuJ3QgaGFwcGVuLg0KPiANCj4gSSBoYXZlIGF0dGFjaGVkIHR3byBIQ0kg
ZHVtcHMsIG9uZSBvZiB0aGUgTWFzdGVyIGRldmljZSBhbmQgb25lIG9mIHRoZSBTbGF2ZS4NCj4g
DQo+IFRoYW5rcyBmb3IgYW55IGhlbHAgeW91IGNhbiBnaXZlLg0KDQpBbHRob3VnaCBpdCdzIG5v
dCBhdCBhbGwgY2xlYXIgZnJvbSB5b3VyIHBvc3RzLCBJJ20gYXNzdW1pbmcgdGhhdCB5b3UncmUN
CnVzaW5nIGEgcmF3IEhDSSBzb2NrZXQgaW4gYSB1c2VyLXNwYWNlIHV0aWxpdHkuDQoNCk15IGd1
ZXNzIGlzIHRoYXQgdGhlIGJ0dXNiIGtlcm5lbCBkcml2ZXIgaXMgZHJvcHBpbmcgeW91ciBBQ0wg
cGFja2V0DQp3aXRob3V0IHRyYW5zbWl0dGluZyBpdC4gSWYgeW91IGxvb2sgYXQgZHJpdmVycy9i
bHVldG9vdGgvYnR1c2IuYy4gaW4NCnRoZSBidHVzYl9zZW5kX2ZyYW1lKCkgZnVuY3Rpb24sIHlv
dSdsbCBzZWU6DQoNCglzd2l0Y2ggKGJ0X2NiKHNrYiktPnBrdF90eXBlKSB7DQoJCS4uLi4NCglj
YXNlIEhDSV9BQ0xEQVRBX1BLVDoNCgkJaWYgKCFkYXRhLT5idWxrX3R4X2VwIHx8IGhkZXYtPmNv
bm5faGFzaC5hY2xfbnVtIDwgMSkNCgkJCXJldHVybiAtRU5PREVWOw0KDQpUaGUgb25seSB3YXkg
dGhhdCBoZGV2LT5jb25uX2hhc2guYWNsX251bSB3aWxsIGJlIDErIGlzIGlmIHRoZQ0KZXN0YWJs
aXNobWVudCBvZiBhbiBBQ0wgY29ubmVjdGlvbiB3ZW50IHRocm91Z2ggaGNpX2Nvbm5lY3QoKSB3
aXRoIGENCmNvbm5lY3Rpb24gdHlwZSBvZiBBQ0xfTElOSy4gVGhpcyBjb2RlIHdhcyBhZGRlZCB3
aGVuIFNDTyBzdXBwb3J0IHdhcw0KYWRkZWQgYmFjayBpbiBBdWcgMjAwOC4NCg0KVGhlIGFjbF9u
dW0gdGVzdCAoYW5kIHRoZSBzY29fdGVzdCBiZWxvdyBpdCkgcHJvYmFibHkgc2hvdWxkIGJlIHNr
aXBwZWQNCmlmIHRoZSBIQ0kgZGV2aWNlIGlzIGluIHJhdyBtb2RlIChhc3N1bWluZyB5b3Ugc2Vu
dCB0aGUgSENJU0VUUkFXIGlvY3RsDQp0byBib3RoIGRldmljZXMpLg0KDQpZb3UgY2FuIGNvbmZp
cm0gdGhpcyBpcyBoYXBwZW5pbmcgYnkgZW5hYmxpbmcgZGVidWcgbWVzc2FnZXMgZm9yIGJ0dXNi
DQphbmQgYmx1ZXRvb3RoLiBZb3Ugc2hvdWxkbid0IG5lZWQgYmx1ZXosIGFzIHRoaXMgaXMgdGhl
IHVzZXItc3BhY2UNCmRhZW1vbiByZXNwb25zaWJsZSBmb3IgdGhlIHByb3RvY29scyBidWlsdCBv
biBMMkNBUCBhbmQgU0NPIChTRFAsDQpSRkNPTU0sIEEyRFAsIGV0Yy4pDQoNCk9uIE1vbiwgMjAx
MS0wNS0zMCBhdCAwOTo1NyAtMDQwMCwgRXBvbnltb3VzIC0gd3JvdGU6DQo+IE9rIHdlbGwgdGhp
cyBoYXMgYmVlbiBhIGNvbXBsZXRlIHdhc3RlIG9mIHRpbWUuIEkgZ3Vlc3Mgd2Ugc2hvdWxkIGp1
c3QNCj4gaWdub3JlIGEgcG90ZW50aWFsIGJ1ZyB0aGVuLC4uLg0KPiANCj4gSXMgdGhpcyBwcm9q
ZWN0IGRlYWQgb3Igc29tZXRoaW5nPyBJIGNhbid0IGJlbGlldmUgYW4gZW50aXJlIG1haWxpbmcN
Cj4gbGlzdCBjYW4ndCBiZSBib3RoZXJlZCB0byBldmVuIGUtbWFpbCBiYWNrIG9yIHRyeSBhbmQg
aGVscCB3aXRoIHRoaXMuDQoNClRoaXMgaXNuJ3QgYXBwcm9wcmlhdGUuDQoNCkkgY2FuIHVuZGVy
c3RhbmQgeW91ciBmcnVzdHJhdGlvbiB0aGF0IHdoYXQgeW91IHdhbnQgdG8gd29yayBkb2Vzbid0
LA0KYnV0IHNpbmNlIHlvdSdyZSB1c2luZyBhIGtlcm5lbCBpbnRlcmZhY2UgZGlyZWN0bHksIHlv
dSBzaG91bGQgYmUNCnByZXBhcmVkIHRvIGRlYnVnIHRoYXQgeW91cnNlbGYuDQoNCk9uIEZyaSwg
MjAxMS0wNS0xMyBhdCAwODo0MiAtMDQwMCwgRXBvbnltb3VzIC0gd3JvdGU6DQo+IFRoZSBmb2xs
b3dpbmcgd2VyZSBleGVjdXRlZCBpbiBhIHJvb3Qgc2hlbGwuDQo+IA0KPiBSZWNlaXZlIFNpZGUg
KERldmljZSBCKToNCj4gDQo+ICQgLi9sMnRlc3QgLXIgMDA6MDI6NUI6MDA6MzE6MjENCj4gbDJ0
ZXN0WzI5MjE5XTogV2FpdGluZyBmb3IgY29ubmVjdGlvbiBvbiBwc20gNDExMyAuLi4NCj4gDQo+
IFRyYW5zbWl0IFNpZGUgKERldmljZSBBKToNCj4gDQo+ICQgLi9sMnRlc3QgLXMgLWIgMTAgMDA6
MDI6NUI6MDE6RkU6REYNCi4uLg0KPiANCj4gRG9lc24ndCBhcHBlYXIgdG8gd29yay4uLg0KDQpC
VFcsIHlvdSdyZSB1c2luZyBsMnRlc3Qgd3JvbmcuIFdpdGggdGhlIGVhY2ggQ1NSIGRvbmdsZSBv
biAqZGlmZmVyZW50DQptYWNoaW5lcyosIHRoaXMgaXMgc3VwcG9zZWQgdG8gbG9vayBsaWtlOg0K
DQpSZWNlaXZlIHNpZGUgKGRldmljZSAwMDowMjo1QjowMDozMToyMSkNCiQgLi9sMnRlc3QgLXIN
Cg0KVHJhbnNtaXQgc2lkZSAoZGV2aWNlIDAwOjAyOjVCOjAxOkZFOkRGKQ0KJCAuL2wydGVzdCAt
cyAtYiAxMCAwMDowMjo1QjowMDozMToyMQ0KDQpOQjogdGhlIGJkYWRkciBwYXJhbWV0ZXIgaXMg
dXNlZCB0byBpbmRpY2F0ZSAqdG8gd2hlcmUqLCBub3QgKmZyb20NCndoZXJlKi4NCg0KU2luY2Ug
eW91IGhhdmUgYm90aCBkZXZpY2VzIG9uIHRoZSBzYW1lIG1hY2hpbmUsIGRvIHRoaXMgKGluIHJv
b3QNCnNoZWxscyk6DQoNClJlY2VpdmUgc2lkZSAoZGV2aWNlIDAwOjAyOjVCOjAwOjMxOjIxKQ0K
JCAuL2wydGVzdCAtciAtaSAwMDowMjo1QjowMDozMToyMQ0KDQpUcmFuc21pdCBzaWRlIChkZXZp
Y2UgMDA6MDI6NUI6MDE6RkU6REYpDQokIC4vbDJ0ZXN0IC1zIC1pIDAwOjAyOjVCOjAxOkZFOkRG
IC1iIDEwIDAwOjAyOjVCOjAwOjMxOjIxDQoNCkxhc3RseSwgeW91IG1heSB3YW50IHRvIHJlY29u
c2lkZXIgdGhlIHdheSB5b3UncmUgdXNpbmcgQmx1ZXRvb3RoLiAgSWYNCnlvdSBjYW4gZ2V0IEwy
Q0FQIHdvcmtpbmcgb24geW91ciBzZXR1cCAoaWUsIGlmIGwydGVzdCB3b3JrcyksIHRoZW4NCmNv
bnNpZGVyIHVzaW5nIFJGQ09NTSBpbnN0ZWFkLiBNb3N0IEJUIHN0YWNrcyBhcmUgbm90IGdvaW5n
IHRvIGxldCB5b3UNCnByb2dyYW0gdGhlIGhvc3QgY29udHJvbGxlciBkaXJlY3RseS4NCg0KR29v
ZCBsdWNrLA0KUGV0ZXIgSHVybGV5DQoNCg==

Re: HCI data payload not getting through when using BlueZ

[Eponymous -]

Thanks for your reply Peter.

Sorry if I came across a bit rude there, it is just very frustrating
sometimes :)

Ok, I managed to get l2test working from the 4.91 source using BlueZ 4.94:

./l2test -s -i 00:02:5B:00:31:27 -b 10 00:02:5B:00:31:25
l2test[30513]: Connected [imtu 672, omtu 672, flush_to 65535, mode 0,
handle 44, class 0x000000]
l2test[30513]: Sending ...

./l2test -r -i 00:02:5B:00:31:25
l2test[30498]: Waiting for connection on psm 4113 ...
l2test[30590]: Connect from 00:02:5B:00:31:27 [imtu 672, omtu 672,
flush_to 65535, mode 0, handle 44, class 0x480100]
l2test[30590]: Receiving ...
l2test[30590]: 680 bytes in 0.09 sec, 7.36 kB/s
l2test[30590]: 680 bytes in 0.08 sec, 7.82 kB/s
l2test[30590]: 680 bytes in 0.10 sec, 6.92 kB/s
l2test[30590]: 680 bytes in 0.08 sec, 7.82 kB/s
l2test[30590]: 680 bytes in 0.08 sec, 7.82 kB/s
l2test[30590]: 680 bytes in 0.08 sec, 7.82 kB/s
l2test[30590]: 680 bytes in 0.08 sec, 7.82 kB/s
l2test[30590]: 680 bytes in 0.08 sec, 7.82 kB/s
l2test[30590]: Disconnect: Success

Does this help us?

You mentioned enabling debug messages for btusb and bluetooth. Do you
by any chance know how to do this?

Thanks.


On Fri, Jun 3, 2011 at 6:35 PM, Peter Hurley <peter@hurleysoftware.com> wrote:
> On Wed, 2011-05-11 at 04:52 -0400, Eponymous - wrote:
>> Hi,
>>
>> I've ran into an issue where data doesn't seem to be received by a slave device.
>>
>> I do the following:
>>
>> Using Gentoo Linux (2.6.34-gentoo-r1)
>> Using BlueZ 4.81
>>
>> 1. Use BlueZ to connect to two Bluetooth devices using HCI only. This
>> is over USB.
>>
>> 2. I set one device as a slave and then create a connection between
>> the two. This completes sucessfully and can be seen on both sides.
>>
>> 3. I then try to send an acl packet with the word "hi" in it and it is
>> not received on the other side.
>>
>> --------
>>
>> Doing the same thing above but:
>>
>> Using Fedora Core 5 (2.6.20-1.2320.fc5)
>> And:
>> bluez-libs-2.25-1
>> bluez-pin-0.30-2
>> bluez-utils-2.25-4
>> bluez-libs-devel-2.25-1
>> bluez-hcidump-1.30-1
>>
>> and using the same hardware - the problem doesn't happen.
>>
>> I have attached two HCI dumps, one of the Master device and one of the Slave.
>>
>> Thanks for any help you can give.
>
> Although it's not at all clear from your posts, I'm assuming that you're
> using a raw HCI socket in a user-space utility.
>
> My guess is that the btusb kernel driver is dropping your ACL packet
> without transmitting it. If you look at drivers/bluetooth/btusb.c. in
> the btusb_send_frame() function, you'll see:
>
>        switch (bt_cb(skb)->pkt_type) {
>                ....
>        case HCI_ACLDATA_PKT:
>                if (!data->bulk_tx_ep || hdev->conn_hash.acl_num < 1)
>                        return -ENODEV;
>
> The only way that hdev->conn_hash.acl_num will be 1+ is if the
> establishment of an ACL connection went through hci_connect() with a
> connection type of ACL_LINK. This code was added when SCO support was
> added back in Aug 2008.
>
> The acl_num test (and the sco_test below it) probably should be skipped
> if the HCI device is in raw mode (assuming you sent the HCISETRAW ioctl
> to both devices).
>
> You can confirm this is happening by enabling debug messages for btusb
> and bluetooth. You shouldn't need bluez, as this is the user-space
> daemon responsible for the protocols built on L2CAP and SCO (SDP,
> RFCOMM, A2DP, etc.)
>
> On Mon, 2011-05-30 at 09:57 -0400, Eponymous - wrote:
>> Ok well this has been a complete waste of time. I guess we should just
>> ignore a potential bug then,...
>>
>> Is this project dead or something? I can't believe an entire mailing
>> list can't be bothered to even e-mail back or try and help with this.
>
> This isn't appropriate.
>
> I can understand your frustration that what you want to work doesn't,
> but since you're using a kernel interface directly, you should be
> prepared to debug that yourself.
>
> On Fri, 2011-05-13 at 08:42 -0400, Eponymous - wrote:
>> The following were executed in a root shell.
>>
>> Receive Side (Device B):
>>
>> $ ./l2test -r 00:02:5B:00:31:21
>> l2test[29219]: Waiting for connection on psm 4113 ...
>>
>> Transmit Side (Device A):
>>
>> $ ./l2test -s -b 10 00:02:5B:01:FE:DF
> ...
>>
>> Doesn't appear to work...
>
> BTW, you're using l2test wrong. With the each CSR dongle on *different
> machines*, this is supposed to look like:
>
> Receive side (device 00:02:5B:00:31:21)
> $ ./l2test -r
>
> Transmit side (device 00:02:5B:01:FE:DF)
> $ ./l2test -s -b 10 00:02:5B:00:31:21
>
> NB: the bdaddr parameter is used to indicate *to where*, not *from
> where*.
>
> Since you have both devices on the same machine, do this (in root
> shells):
>
> Receive side (device 00:02:5B:00:31:21)
> $ ./l2test -r -i 00:02:5B:00:31:21
>
> Transmit side (device 00:02:5B:01:FE:DF)
> $ ./l2test -s -i 00:02:5B:01:FE:DF -b 10 00:02:5B:00:31:21
>
> Lastly, you may want to reconsider the way you're using Bluetooth.  If
> you can get L2CAP working on your setup (ie, if l2test works), then
> consider using RFCOMM instead. Most BT stacks are not going to let you
> program the host controller directly.
>
> Good luck,
> Peter Hurley
>
>

Re: HCI data payload not getting through when using BlueZ

[Peter Hurley]

T24gV2VkLCAyMDExLTA2LTI5IGF0IDA2OjIyIC0wNDAwLCBFcG9ueW1vdXMgLSB3cm90ZToNCj4g
VGhhbmtzIGZvciB5b3VyIHJlcGx5IFBldGVyLg0KPiANCj4gU29ycnkgaWYgSSBjYW1lIGFjcm9z
cyBhIGJpdCBydWRlIHRoZXJlLCBpdCBpcyBqdXN0IHZlcnkgZnJ1c3RyYXRpbmcNCj4gc29tZXRp
bWVzIDopDQoNCkkgZ2V0IGl0LiBCVCBjYW4gYmUgPGFyZ2dnaGhoPi4uLg0KDQo+IFlvdSBtZW50
aW9uZWQgZW5hYmxpbmcgZGVidWcgbWVzc2FnZXMgZm9yIGJ0dXNiIGFuZCBibHVldG9vdGguIERv
IHlvdQ0KPiBieSBhbnkgY2hhbmNlIGtub3cgaG93IHRvIGRvIHRoaXM/DQoNCkkgYWx3YXlzIHJ1
biBhIGRlYnVnIGtlcm5lbC4gTXkgcmVsZXZhbnQgYnVpbGQgc2V0dGluZ3MgaW4gdGhlICJLZXJu
ZWwNCmhhY2tpbmciIHN1Ym1lbnUgYXJlOg0KIEtlcm5lbCBEZWJ1Z2dpbmcgPT4gREVCVUdfS0VS
TkVMPXkNCiBEZWJ1ZyBGaWxlc3lzdGVtID0+IERFQlVHX0ZTPXkNCiBDb21waWxlIHRoZSBrZXJu
ZWwgd2l0aCBkZWJ1ZyBpbmZvID0+IERFQlVHX0lORk89eQ0KYW5kIG1vc3QgaW1wb3J0YW50bHks
DQogRW5hYmxlIGR5bmFtaWMgcHJpbnRrKCkgc3VwcG9ydCBEWU5BTUlDX0RFQlVHPXkNCg0KVGhl
biByZWFkIHRoZSBzaG9ydCBkeW5hbWljIGRlYnVnIGhvd3RvIGluIHRoZSBrZXJuZWwgZG9jdW1l
bnRhdGlvbjoNCkRvY3VtZW50YXRpb24vZHluYW1pYy1kZWJ1Zy1ob3d0by50eHQgKHRoZXJlIGFy
ZSBzb21lIGNvcGllcyBvbmxpbmUgYXMNCndlbGwgaWYgdGhhdCdzIGVhc2llcikuDQoNClRoZW4g
d2hlbiBJIHdhbnQgdG8gc2VlIGRlYnVnIG1lc3NhZ2VzLCBJIGp1c3QgZW5hYmxlIHRob3NlIHNv
dXJjZQ0KZmlsZXMuIEVnLiwNCiMgZWNobyAtbiAnZmlsZSBoY2lfY29yZS5jICtwJyA+IC9zeXMv
a2VybmVsL2RlYnVnL2R5bmFtaWNfZGVidWcvY29udHJvbA0KIyBlY2hvIC1uICdmaWxlIGhjaV9j
b25uLmMgK3AnIC4uLg0KIyBlY2hvIC1uICdmaWxlIGhjaV9ldmVudC5jICtwJyAuLi4NCg0KUGx1
cywgaXQncyBlYXN5IHRvIGFkZCB5b3VyIG93biBpZiB5b3Ugc3VzcGVjdCBhIHBhcnRpY3VsYXIg
Y29kZSBwYXRoLg0KDQpJZiB5b3UgaGF2ZSBtb3JlIHF1ZXN0aW9ucyBhYm91dCB0aGlzLCBjb21l
IGFzayBvbiBJUkMgI2JsdWV6Lg0KDQo+IE9uIEZyaSwgSnVuIDMsIDIwMTEgYXQgNjozNSBQTSwg
UGV0ZXIgSHVybGV5IDxwZXRlckBodXJsZXlzb2Z0d2FyZS5jb20+IHdyb3RlOg0KPiA+IEFsdGhv
dWdoIGl0J3Mgbm90IGF0IGFsbCBjbGVhciBmcm9tIHlvdXIgcG9zdHMsIEknbSBhc3N1bWluZyB0
aGF0IHlvdSdyZQ0KPiA+IHVzaW5nIGEgcmF3IEhDSSBzb2NrZXQgaW4gYSB1c2VyLXNwYWNlIHV0
aWxpdHkuDQoNCkFyZSB5b3UgdXNpbmcgYSByYXcgSENJIHNvY2tldD8NCg0KPiA+IE15IGd1ZXNz
IGlzIHRoYXQgdGhlIGJ0dXNiIGtlcm5lbCBkcml2ZXIgaXMgZHJvcHBpbmcgeW91ciBBQ0wgcGFj
a2V0DQo+ID4gd2l0aG91dCB0cmFuc21pdHRpbmcgaXQuIElmIHlvdSBsb29rIGF0IGRyaXZlcnMv
Ymx1ZXRvb3RoL2J0dXNiLmMuIGluDQo+ID4gdGhlIGJ0dXNiX3NlbmRfZnJhbWUoKSBmdW5jdGlv
biwgeW91J2xsIHNlZToNCj4gPg0KPiA+ICAgICAgICBzd2l0Y2ggKGJ0X2NiKHNrYiktPnBrdF90
eXBlKSB7DQo+ID4gICAgICAgICAgICAgICAgLi4uLg0KPiA+ICAgICAgICBjYXNlIEhDSV9BQ0xE
QVRBX1BLVDoNCj4gPiAgICAgICAgICAgICAgICBpZiAoIWRhdGEtPmJ1bGtfdHhfZXAgfHwgaGRl
di0+Y29ubl9oYXNoLmFjbF9udW0gPCAxKQ0KPiA+ICAgICAgICAgICAgICAgICAgICAgICAgcmV0
dXJuIC1FTk9ERVY7DQo+ID4NCj4gPiBUaGUgb25seSB3YXkgdGhhdCBoZGV2LT5jb25uX2hhc2gu
YWNsX251bSB3aWxsIGJlIDErIGlzIGlmIHRoZQ0KPiA+IGVzdGFibGlzaG1lbnQgb2YgYW4gQUNM
IGNvbm5lY3Rpb24gd2VudCB0aHJvdWdoIGhjaV9jb25uZWN0KCkgd2l0aCBhDQo+ID4gY29ubmVj
dGlvbiB0eXBlIG9mIEFDTF9MSU5LLiBUaGlzIGNvZGUgd2FzIGFkZGVkIHdoZW4gU0NPIHN1cHBv
cnQgd2FzDQo+ID4gYWRkZWQgYmFjayBpbiBBdWcgMjAwOC4NCg0KTXkgcG9pbnQgaGVyZSBpcyB0
aGlzIGlzIHByb2JhYmx5IGEgYnVnIGluIGJ0dXNiIC0gcmF3IEhDSSBzb2NrZXRzDQpzaG91bGQg
YmUgYWJsZSB0byBzZW5kICphbnkqIHBhY2tldC4NCg0KSWYgeW91IGNhbiBjb25maXJtIHlvdSdy
ZSBvbiBhIHJhdyBIQ0kgc29ja2V0LCBJIGNhbiBleHBsb3JlIGEgZml4IGJ1dA0KeW91J2xsIGJl
IHRoZSB0ZXN0IHN1YmplY3QgPGdyaW4+Lg0KDQpMZXQgbWUga25vdywNClBldGVyIEh1cmxleSAN
Cg0KDQo=

Re: HCI data payload not getting through when using BlueZ

[Eponymous -]

Thanks for the information.

Hmm, I'm not sure what you mean about a "raw hci" socket. Could you
tell me how I can check this?

I'm using a custom program that can communicate directly to the chip
over hci using bluez as a go-between. Does this help?

Cheers.

On Thu, Jun 30, 2011 at 4:47 PM, Peter Hurley <peter@hurleysoftware.com> wrote:
> On Wed, 2011-06-29 at 06:22 -0400, Eponymous - wrote:
>> Thanks for your reply Peter.
>>
>> Sorry if I came across a bit rude there, it is just very frustrating
>> sometimes :)
>
> I get it. BT can be <arggghhh>...
>
>> You mentioned enabling debug messages for btusb and bluetooth. Do you
>> by any chance know how to do this?
>
> I always run a debug kernel. My relevant build settings in the "Kernel
> hacking" submenu are:
>  Kernel Debugging => DEBUG_KERNEL=y
>  Debug Filesystem => DEBUG_FS=y
>  Compile the kernel with debug info => DEBUG_INFO=y
> and most importantly,
>  Enable dynamic printk() support DYNAMIC_DEBUG=y
>
> Then read the short dynamic debug howto in the kernel documentation:
> Documentation/dynamic-debug-howto.txt (there are some copies online as
> well if that's easier).
>
> Then when I want to see debug messages, I just enable those source
> files. Eg.,
> # echo -n 'file hci_core.c +p' > /sys/kernel/debug/dynamic_debug/control
> # echo -n 'file hci_conn.c +p' ...
> # echo -n 'file hci_event.c +p' ...
>
> Plus, it's easy to add your own if you suspect a particular code path.
>
> If you have more questions about this, come ask on IRC #bluez.
>
>> On Fri, Jun 3, 2011 at 6:35 PM, Peter Hurley <peter@hurleysoftware.com> wrote:
>> > Although it's not at all clear from your posts, I'm assuming that you're
>> > using a raw HCI socket in a user-space utility.
>
> Are you using a raw HCI socket?
>
>> > My guess is that the btusb kernel driver is dropping your ACL packet
>> > without transmitting it. If you look at drivers/bluetooth/btusb.c. in
>> > the btusb_send_frame() function, you'll see:
>> >
>> >        switch (bt_cb(skb)->pkt_type) {
>> >                ....
>> >        case HCI_ACLDATA_PKT:
>> >                if (!data->bulk_tx_ep || hdev->conn_hash.acl_num < 1)
>> >                        return -ENODEV;
>> >
>> > The only way that hdev->conn_hash.acl_num will be 1+ is if the
>> > establishment of an ACL connection went through hci_connect() with a
>> > connection type of ACL_LINK. This code was added when SCO support was
>> > added back in Aug 2008.
>
> My point here is this is probably a bug in btusb - raw HCI sockets
> should be able to send *any* packet.
>
> If you can confirm you're on a raw HCI socket, I can explore a fix but
> you'll be the test subject <grin>.
>
> Let me know,
> Peter Hurley
>
>
>