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 - <[email protected]> wrote:
> What format do you specify the bdaddr in ?
>
> Cheers.
>
> On Fri, May 13, 2011 at 9:26 AM, Mika Linnanoja
> <[email protected]> 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
>>
>
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
<[email protected]> wrote:
> Hi,
>
> On Tue, May 17, 2011 at 3:13 AM, Eponymous - <[email protected]> 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
>
Hi,
On Tue, May 17, 2011 at 3:13 AM, Eponymous - <[email protected]> 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
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
<[email protected]> wrote:
> Hi,
>
> On Mon, May 16, 2011 at 6:36 AM, Eponymous - <[email protected]> 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
>
Hi,
On Mon, May 16, 2011 at 6:36 AM, Eponymous - <[email protected]> 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
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 - <[email protected]> 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 - <[email protected]> wrote:
>> What format do you specify the bdaddr in ?
>>
>> Cheers.
>>
>> On Fri, May 13, 2011 at 9:26 AM, Mika Linnanoja
>> <[email protected]> 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
>>>
>>
>