* Re: [Bluez-devel] Re: command tx timeout and continuous inquiry.
[not found] ` <1065791594.14514.179.camel@pegasus>
@ 2003-10-10 13:23 ` Rene Mayrhofer
2003-10-13 10:28 ` Rene Mayrhofer
[not found] ` <3F8FB6D9.8030000@soft.uni-linz.ac.at>
2 siblings, 0 replies; 9+ messages in thread
From: Rene Mayrhofer @ 2003-10-10 13:23 UTC (permalink / raw)
To: Marcel Holtmann, bluez-devel
Hi Marcel (again),
Marcel Holtmann wrote:
> it is a HCI 14.7 with max encryption of 56 bits.
>
>
>>So it's a hardware problem ?
>
>
> No, it's a problem of the firmware inside the dongle. Ask Acer for an
> update if they provide one.
Ok, I'll try to get an update (hopefully there is one...). Is my
conclusion correct that I am not expecting too much from the Bluetooth
protocol and that the following should work (and is already supported by
bluez in 2.4.22):
Device 1:
- background thread for continuous inquiry with about 3 seconds between
the hci_inquiry calls
- fer each MAC address found by the inquiry, another thread which uses
L2CAP connections (via Bluetooth address familiy sockets) to send "ping"
packets to measure the latency and link quality. The connection will be
created, a single ping packet will be sent and the connection will be
closed again. Then 100-500 ms delay and again opening the connection.
(Is it necessary to close the connection between the link quality checks
? I currently do that to release the devices for other communication -
if they support more piconets at the same time, I could also leave the
connection open.)
Device x:
- continuous inquiry
- possibly communication with other devices (those connections will stay
up longer than the "ping" connections).
Am I doing anything stupid in this setup ?
Thanks for your quick answers,
Rene
--
------------------------------------------------
Pervasive 2004: www.pervasive2004.org
------------------------------------------------
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Bluez-devel] Re: command tx timeout and continuous inquiry.
2003-10-13 10:28 ` Rene Mayrhofer
@ 2003-10-13 9:19 ` Marcel Holtmann
0 siblings, 0 replies; 9+ messages in thread
From: Marcel Holtmann @ 2003-10-13 9:19 UTC (permalink / raw)
To: Rene Mayrhofer; +Cc: BlueZ Mailing List
Hi Rene,
> Unfortunately Acer does not seem to provide one, they don't even seem to
> support the BT-500 properly anymore. Thus I am now stuck with a hardware
> which does not seem to support what I intend to do - time to buy new
> hardware....
> Which USB Bluetooth adapters are currently recommended for Bluez ? With
> which do people have good experiences concerning stability ? It should
> support inquiry and L2CAP connections at the same time and (which I'll
> most probably need in the near future) BNEP/PAN. A RTFM-link would be
> wonderful, if there's a list of known-good devices and revisions up
> somewhere.
all CSR firmwares with HCI 16.x and greater are fine.
http://www.holtmann.org/linux/bluetooth/features.html
http://www.holtmann.org/linux/bluetooth/csr.html
Regards
Marcel
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Bluez-devel] Re: command tx timeout and continuous inquiry.
[not found] ` <1065791594.14514.179.camel@pegasus>
2003-10-10 13:23 ` [Bluez-devel] Re: command tx timeout and continuous inquiry Rene Mayrhofer
@ 2003-10-13 10:28 ` Rene Mayrhofer
2003-10-13 9:19 ` Marcel Holtmann
[not found] ` <3F8FB6D9.8030000@soft.uni-linz.ac.at>
2 siblings, 1 reply; 9+ messages in thread
From: Rene Mayrhofer @ 2003-10-13 10:28 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: bluez-devel
Hi Marcel,
Marcel Holtmann wrote:
> No, it's a problem of the firmware inside the dongle. Ask Acer for an
> update if they provide one.
Unfortunately Acer does not seem to provide one, they don't even seem to
support the BT-500 properly anymore. Thus I am now stuck with a hardware
which does not seem to support what I intend to do - time to buy new
hardware....
Which USB Bluetooth adapters are currently recommended for Bluez ? With
which do people have good experiences concerning stability ? It should
support inquiry and L2CAP connections at the same time and (which I'll
most probably need in the near future) BNEP/PAN. A RTFM-link would be
wonderful, if there's a list of known-good devices and revisions up
somewhere.
Thanks for your time,
Rene
--
------------------------------------------------
Pervasive 2004: www.pervasive2004.org
------------------------------------------------
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Bluez-devel] Re: command tx timeout and continuous inquiry.
[not found] ` <1066636708.902.5.camel@pegasus>
@ 2003-10-21 10:45 ` Rene Mayrhofer
2003-10-21 11:32 ` Marcel Holtmann
0 siblings, 1 reply; 9+ messages in thread
From: Rene Mayrhofer @ 2003-10-21 10:45 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: bluez-devel
Hi Marcel,
Sorry to bother you again, but it still doesn't work as expected....
Marcel Holtmann wrote:
>>>all CSR firmwares with HCI 16.x and greater are fine.
>>
>>I will try a few devices at the hardware store to be sure to get a good
>>firmware revision if I know what to look for. I'll look for CSR chipsets
>>(easy to check), but which HCI Rev. and Subver. should I look for ?
>>Which is the mimimum set of features that is needed ?
>
>
> You can take a look at my web pages
>
> http://www.holtmann.org/linux/bluetooth/csr.html
I think I now have an adapter with correct firmware:
[rene@wall2 /tmp]$ sudo hciconfig -a
hci0: Type: USB
BD Address: 00:04:61:80:C3:DC ACL MTU: 192:8 SCO MTU: 64:8
UP RUNNING PSCAN ISCAN
RX bytes:99 acl:0 sco:0 events:13 errors:0
TX bytes:296 acl:0 sco:0 commands:12 errors:0
Features: 0xff 0xff 0x0b 0x00
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy: HOLD SNIFF PARK
Link mode: MASTER
Name: 'Wally (0)'
Class: 0x000100
Service Classes: Unspecified
Device Class: Computer, Uncategorized
HCI Ver: 1.1 (0x1) HCI Rev: 0x20d LMP Ver: 1.1 (0x1) LMP
Subver: 0x20d
Manufacturer: Cambridge Silicon Radio (10)
[rene@wall2 /tmp]$ sudo hciconfig hci0 revision
hci0: Type: USB
BD Address: 00:04:61:80:C3:DC ACL MTU: 192:8 SCO MTU: 64:8
HCI 16.4 (bc02x)
[rene@wall2 /tmp]$ cat /proc/version
Linux version 2.4.22 (root@wally) (gcc version 3.2.3 (Debian)) #1 Fri
Sep 5 16:10:27 CEST 2003
However, I am still unable to create a second L2 connection (with BSD
sockets) from two independent threads. A test run with my custom code
shows the following (I've commented it a bit and the respective code is
at the end of this mail):
Creating new L2Connection object for MAC 00:E0:00:C7:33:5E, starting
ping thread now
<comment> This means that the MAC address 00:E0:00:C7:33:5E has been
found during an inquiry (in a background inquiry thread) and that
another thread was started specifically for this MAC. No connection has
been made until now, only the inquiry. </comment>
BluetoothLinuxFeatureProvider::L2Connection::run (00:E0:00:C7:33:5E):
opened socket 8
<comment> This means that the newly started thread has created a socket
for Bluetooth and got socket descriptor 8 back from the socket call.
</comment>
Creating new L2Connection object for MAC 00:02:C7:08:77:11, starting
ping thread now
Creating new L2Connection object for MAC 00:01:E3:10:44:ED, starting
ping thread now
<comment> Two more MAC addresses were found during the inquiry, so two
additional threads are started. </comment>
BluetoothLinuxFeatureProvider::L2Connection::run (00:02:C7:08:77:11):
opened socket 9
<comment> The socket was opened successfully. </comment>
BluetoothLinuxFeatureProvider::L2Connection::run: Can't connect: Device
or resource busy (16)
<comment> But the connect() call returned an error (16). </comment>
Deleting L2Connection object for MAC 00:02:C7:08:77:11, ping thread stopped
<comment> Since connect is not possible, the new thread immediately
stops again. </comment>
BluetoothLinuxFeatureProvider::L2Connection::run (00:01:E3:10:44:ED):
opened socket 9
BluetoothLinuxFeatureProvider::L2Connection::run: Can't connect: Device
or resource busy (16)
Deleting L2Connection object for MAC 00:01:E3:10:44:ED, ping thread stopped
<comment> The same problem for the third MAC address. </comment>
BluetoothLinuxFeatureProvider::L2Connection::run (00:E0:00:C7:33:5E):
opened socket 6
<comment> The first "ping" thread is running in the background and
sending L2 echo packets. </comment>
Creating new L2Connection object for MAC 00:02:C7:08:77:11, starting
ping thread now
BluetoothLinuxFeatureProvider::L2Connection::run (00:02:C7:08:77:11):
opened socket 8
Creating new L2Connection object for MAC 00:01:E3:10:44:ED, starting
ping thread now
BluetoothLinuxFeatureProvider::L2Connection::run: Can't connect: Device
or resource busy (16)
Deleting L2Connection object for MAC 00:02:C7:08:77:11, ping thread stopped
BluetoothLinuxFeatureProvider::L2Connection::run (00:01:E3:10:44:ED):
opened socket 8
BluetoothLinuxFeatureProvider::L2Connection::run: Can't connect: Device
or resource busy (16)
Deleting L2Connection object for MAC 00:01:E3:10:44:ED, ping thread stopped
<comment> Another try at the two MAC addresses because they were again
found in the inquiry. </comment>
BluetoothLinuxFeatureProvider::L2Connection::run (00:E0:00:C7:33:5E):
opened socket 6
BluetoothLinuxFeatureProvider::L2Connection::run (00:E0:00:C7:33:5E):
opened socket 6
BluetoothLinuxFeatureProvider::L2Connection::run (00:E0:00:C7:33:5E):
opened socket 6
BluetoothLinuxFeatureProvider::L2Connection::run (00:E0:00:C7:33:5E):
opened socket 6
BluetoothLinuxFeatureProvider::L2Connection::run (00:E0:00:C7:33:5E):
opened socket 6
BluetoothLinuxFeatureProvider::L2Connection::run (00:E0:00:C7:33:5E):
opened socket 6
BluetoothLinuxFeatureProvider::L2Connection::run (00:E0:00:C7:33:5E):
opened socket 6
BluetoothLinuxFeatureProvider::L2Connection::run (00:E0:00:C7:33:5E):
opened socket 6
BluetoothLinuxFeatureProvider::L2Connection::run (00:E0:00:C7:33:5E):
opened socket 6
BluetoothLinuxFeatureProvider::L2Connection::run (00:E0:00:C7:33:5E):
opened socket 6
BluetoothLinuxFeatureProvider::L2Connection::run (00:E0:00:C7:33:5E):
opened socket 6
<comment> This took nearly a minute (there is a 5 seconds delays between
ping packets), during which no MAC addresses were found in the
inquiries. Inquiries run constantly in the background with 3 seconds
delay between inquiry attempts and about 6 seconds inquiry time. As soon
as a stable "ping" connection is created, the inquiry call no longer
returns any addresses. </comment>
no response from 00:E0:00:C7:33:5E: id 212
Deleting L2Connection object for MAC 00:E0:00:C7:33:5E, ping thread stopped
<comment> This was simply a timeout in this thread, although the devices
were not moved. But in my experience, this just happens sometimes.
</comment>
Creating new L2Connection object for MAC 00:01:E3:10:44:ED, starting
ping thread now
Creating new L2Connection object for MAC 00:02:C7:08:77:11, starting
ping thread now
<comment> As soon as the L2 connection is down, the inquiry works again
and returns MAC addresses. </comment>
BluetoothLinuxFeatureProvider::L2Connection::run (00:01:E3:10:44:ED):
opened socket 8
BluetoothLinuxFeatureProvider::L2Connection::run (00:02:C7:08:77:11):
opened socket 9
BluetoothLinuxFeatureProvider::L2Connection::run: Can't connect: Device
or resource busy (16)
Deleting L2Connection object for MAC 00:02:C7:08:77:11, ping thread stopped
<comment> Same story again. The first socket creation call succeeds, the
second doesn't. </comment>
.....
This is the code responsible for the background inquiry thread:
void BluetoothLinuxFeatureProvider::run() throw()
{
int dev_id = -1, length = 5, flags = 0 /*IREQ_CACHE_FLUSH*/,
num_rsp;
inquiry_info *info = NULL;
bdaddr_t bdaddr;
while (!this->isCancelled()) {
/* hci_inquiry will malloc() the info structure for the found number
of devices */
num_rsp = hci_inquiry(dev_id, length, 0, NULL, &info, flags);
if (num_rsp >= 0) {
for (int i = 0; i < num_rsp; i++) {
char* macStr = NULL;
baswap(&bdaddr, &(info+i)->bdaddr);
macStr = batostr(&bdaddr);
if (macStr != NULL) {
// skipped a few checks here, this is only done if a thread is not
already running for this MAC
new L2Connection(this, macStr);
}
}
if (info != NULL)
free(info);
// we have to set it to 0 so that hci_inquire will again malloc !
info = NULL;
}
this->sleep(3000);
}
}
And this is the "ping" code for the threads:
void BluetoothLinuxFeatureProvider::L2Connection::run() throw() {
bool running = true, started = false;
bdaddr_t bdaddr;
int id;
struct sockaddr_l2 addr;
char buf[128];
struct hci_conn_info_req *cr;
struct hci_request rq;
get_link_quality_rp rp;
baswap(&bdaddr, strtoba(mac.c_str()));
// intialize ping packet buffer
for(unsigned int i = L2CAP_CMD_HDR_SIZE; i < sizeof(buf); i++)
buf[i]=(i%40)+'A';
memset(&addr, 0, sizeof(addr));
addr.l2_family = AF_BLUETOOTH;
id = ident;
while (running) {
struct timeval tv_send, tv_recv, tv_diff;
l2cap_cmd_hdr *cmd = (l2cap_cmd_hdr *) buf;
int s, dd, dev_id;
// first we need to create a Bluetooth socket
if ((s = socket(PF_BLUETOOTH, SOCK_RAW, BTPROTO_L2CAP)) < 0) {
plog("BluetoothLinuxFeatureProvider::L2Connection::run: Can't create
socket: %s\n", strerror(errno));
running = false;
break;
}
plog("BluetoothLinuxFeatureProvider::L2Connection::run (%s): opened
socket %d\n", mac.c_str(), s);
bacpy(&(addr.l2_bdaddr), BDADDR_ANY);
if (bind(s, (struct sockaddr *) &addr, sizeof(addr)) < 0) {
plog("BluetoothLinuxFeatureProvider::L2Connection::run: Can't bind
socket.\n");
running = false;
close(s);
break;
}
// connect to the remote host
bacpy(&addr.l2_bdaddr, &bdaddr);
// here the problem starts
if (connect(s, (struct sockaddr *)&addr, sizeof(addr)) < 0) {
plog("BluetoothLinuxFeatureProvider::L2Connection::run: Can't
connect: %s (%d)\n", strerror(errno), errno);
running = false;
close(s);
break;
}
/* Build command header */
<snip>
plog("Deleting L2Connection object for MAC %s, ping thread stopped\n",
mac.c_str());
}
Most of the code has been taken from hcitool and simply has been adapted
to the framework. What is not shown here (the <skip> block) is that,
after a successfully received reply packet, I also open a HCI socket
with hci_open_dev to get the L2 link quality (code taken from hcitool
con). Both sockets are closed immediately afterwards in the ping loop.
Then there is a delay of 5 seconds and it starts again to open the L2
socket.
Do you have any other pointers on what might go wrong here ? I am
grateful for any hint. We don't have very much money to spend on
hardware here at the university, but another Bluetooth adapter should be
doable :)
best regards,
Rene
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Bluez-devel] Re: command tx timeout and continuous inquiry.
2003-10-21 10:45 ` Rene Mayrhofer
@ 2003-10-21 11:32 ` Marcel Holtmann
2003-10-21 12:09 ` Rene Mayrhofer
0 siblings, 1 reply; 9+ messages in thread
From: Marcel Holtmann @ 2003-10-21 11:32 UTC (permalink / raw)
To: Rene Mayrhofer; +Cc: BlueZ Mailing List
Hi Rene,
> Sorry to bother you again, but it still doesn't work as expected....
this must be a problem with your code. I checked it with two l2ping
commands and an inquiry from the command line and it works as expect. I
have used my Microsoft USB adapter for testing.
hci0: Type: USB
BD Address: 00:50:xx:xx:xx:xx ACL MTU: 192:8 SCO MTU: 64:8
HCI 16.1.1
Chip version: BlueCore02
Max key size: 128 bit
SCO mapping: HCI
Regards
Marcel
-------------------------------------------------------
This SF.net email is sponsored by OSDN developer relations
Here's your chance to show off your extensive product knowledge
We want to know what you know. Tell us and you have a chance to win $100
http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Bluez-devel] Re: command tx timeout and continuous inquiry.
2003-10-21 11:32 ` Marcel Holtmann
@ 2003-10-21 12:09 ` Rene Mayrhofer
2003-10-21 12:13 ` Marcel Holtmann
0 siblings, 1 reply; 9+ messages in thread
From: Rene Mayrhofer @ 2003-10-21 12:09 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: BlueZ Mailing List
Hi Marcel,
Marcel Holtmann wrote:
> this must be a problem with your code. I checked it with two l2ping
> commands and an inquiry from the command line and it works as expect. I
> have used my Microsoft USB adapter for testing.
>
> hci0: Type: USB
> BD Address: 00:50:xx:xx:xx:xx ACL MTU: 192:8 SCO MTU: 64:8
> HCI 16.1.1
> Chip version: BlueCore02
> Max key size: 128 bit
> SCO mapping: HCI
On my system, I can not confirm this. When I start two l2ping runs,
"hcitool scan" will never return a result (I have tried a number of
times). The interesting thing is the following: One l2ping runs in the
background and I start "hcitool scan". It will take 10 - 24 seconds and
will only return those devices which are currently _not_ pinged. When I
start the second l2ping when "hcitool scan" is still running, either:
a) hcitool scan will immediately return (in less than 10 seconds) and
the l2ping will work
b) hcitool scan will return with "Can't connect.: Device or ressource busy"
I've not found a way to reliably reproduce on of the two, it seems to be
random which one will happen.
PS: Is libbluetooth thread-safe ? Maybe that could be part of my problem
with two l2ping sessions from two different threads in the same process ?
best regards,
Rene
--
------------------------------------------------
Pervasive 2004: www.pervasive2004.org
------------------------------------------------
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Bluez-devel] Re: command tx timeout and continuous inquiry.
2003-10-21 12:09 ` Rene Mayrhofer
@ 2003-10-21 12:13 ` Marcel Holtmann
2003-10-21 13:04 ` Rene Mayrhofer
2003-10-21 14:31 ` [Bluez-devel] Stress testing (Was: Re: command tx timeout and continuous inquiry.) Rene Mayrhofer
0 siblings, 2 replies; 9+ messages in thread
From: Marcel Holtmann @ 2003-10-21 12:13 UTC (permalink / raw)
To: Rene Mayrhofer; +Cc: BlueZ Mailing List
Hi Rene,
> On my system, I can not confirm this. When I start two l2ping runs,
> "hcitool scan" will never return a result (I have tried a number of
> times). The interesting thing is the following: One l2ping runs in the
> background and I start "hcitool scan". It will take 10 - 24 seconds and
> will only return those devices which are currently _not_ pinged. When I
> start the second l2ping when "hcitool scan" is still running, either:
> a) hcitool scan will immediately return (in less than 10 seconds) and
> the l2ping will work
> b) hcitool scan will return with "Can't connect.: Device or ressource busy"
> I've not found a way to reliably reproduce on of the two, it seems to be
> random which one will happen.
it is ok that devices with active connections don't answer inquiry scans
and you need to use --flush with hcitool to disable the kernel side
inquiry cache.
> PS: Is libbluetooth thread-safe ? Maybe that could be part of my problem
> with two l2ping sessions from two different threads in the same process ?
I don't see any problems here, because you only use socket programming.
Regards
Marcel
-------------------------------------------------------
This SF.net email is sponsored by OSDN developer relations
Here's your chance to show off your extensive product knowledge
We want to know what you know. Tell us and you have a chance to win $100
http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Bluez-devel] Re: command tx timeout and continuous inquiry.
2003-10-21 12:13 ` Marcel Holtmann
@ 2003-10-21 13:04 ` Rene Mayrhofer
2003-10-21 14:31 ` [Bluez-devel] Stress testing (Was: Re: command tx timeout and continuous inquiry.) Rene Mayrhofer
1 sibling, 0 replies; 9+ messages in thread
From: Rene Mayrhofer @ 2003-10-21 13:04 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: BlueZ Mailing List
Hi Marcel,
Marcel Holtmann wrote:
> it is ok that devices with active connections don't answer inquiry scans
I was expecting something like that, and it shouldn't be a problem since
I have the pings anyway.
> and you need to use --flush with hcitool to disable the kernel side
> inquiry cache.
I didn't know the --flush, but I always executed hcitool scan multiple
times until it really did a new scan (judging from the response time).
--flush doesn't change the results.
I still find it a bit disturbing that I am unable to reproduce your
results (two l2ping runs and an inquriy which returns results), maybe
there is something wrong with my setup. I just loaded the appropriate
modules, started hcid and did nothing to tweak it. If two l2ping
invocations run and I start "hcitool scan --flush", then I get nothing back.
Update: On one invocation, I indeed got a third MAC address back (which
is detected reliably when no l2ping is running), but only this one time....
The second l2ping also can not be started reliably when inquiries are
continuously running (while true; do hcitool scan --flush; done).
Sometimes (I've not found a way to reproduce it reliably), it fails with
device or ressource busy.
>>PS: Is libbluetooth thread-safe ? Maybe that could be part of my problem
>>with two l2ping sessions from two different threads in the same process ?
>
>
> I don't see any problems here, because you only use socket programming.
Me neither, just wanted to ask :)
best regards,
Rene
--
------------------------------------------------
Pervasive 2004: www.pervasive2004.org
------------------------------------------------
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Bluez-devel] Stress testing (Was: Re: command tx timeout and continuous inquiry.)
2003-10-21 12:13 ` Marcel Holtmann
2003-10-21 13:04 ` Rene Mayrhofer
@ 2003-10-21 14:31 ` Rene Mayrhofer
1 sibling, 0 replies; 9+ messages in thread
From: Rene Mayrhofer @ 2003-10-21 14:31 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: BlueZ Mailing List
Hi Marcel
I've now done a bit of stress-testing and these are the results:
With the Epox adapter (HCI 16.4), I was able to go up to the theoretical
maximum of 7 concurrent l2ping instances to different devices. All 7
instances run and get their reply packets back. However, only 3 of them
report "20 bytes from ...." while the other 4 report "0 bytes from
....". I am not sure what causes this, but it might be the devices
themselves. The Bluetooth stacks on the devices I used in this test are
vastly different, ranging from Compaq Ipaq, FSC Pocket Loox, Sony Vaio
with WinXP to other bluez boxes under x86 or Compaq Ipaq. There were
even a few mobile phones in the pool....
And the background inquiry even returned some devices under this load,
I'm now nearly where I want to go :)
Although this sounds very good, there are a few catches:
- Starting the l2ping instances was very tricky. The more were already
running, the more difficult it got to start an additional one. For the
last 2 instances, I had to try for about 25 times until it started
correctly. Before that, it always returned "Can't connect.: Device or
resource busy". Are there any internal kernel timeouts for freeing
resources ? I have no idea why in the beginning it doesn't work but then
suddenly it does. As soon as the l2ping starts, it seems reliable most
of the time (some connection break but can be re-established, maybe it's
just the radio link that's bad in these cases).
- Sometimes the same happens for the inquiry. In my "while true; hcitool
scan --flush; done" loop, it sometimes also goes crazy with "Inquiry
failed.: Device or resource busy" for about 30 seconds and then starts
to work again.
How is an application supposed to deal with these phenomena ? Is there a
maximum period during which a call is allowed to fail or is it random ?
Although my application still can't create two L2 connections, this test
shows that (with a current HCI firmware) it is in principle possible. I
still have to find out why my code (which is mostly copied from l2ping)
does not perform the same - I still think that it has to do with
multi-threading somehow. But I am getting closer now.....
As a sidenote, bluez is rather unstable on my Sony Vaio PCG-SRX51P/A,
which has a CSR chip with build ID 0x77 (which is reported as HCI 12.1).
After a while of moderate load, the kernel log starts to get entries such as
kernel: hci_cmd_task: hci0 command tx timeout
kernel: Warning: null TTY for (d8:00) in tty_fasync
(I use rfcomm connections to a Siemens S55).
Reloading the bluez stack seems to reset everything so that it works
again (until it breaks again....) - at least I don't have to reboot to
get it back to work and can still claim that bluez is more mature than
the Sony Bluespace stack :)
On my Debian system, this typically means
/etc/init.d/bluez-sdp stop
/etc/init.d/bluez-utils stop
/etc/init.d/hotplug restart
/etc/init.d/bluez-utils start
/etc/init.d/bluez-sdp start
Another sequence won't work, especially restarting the whole USB
subsystem is necessary so that hci_usb gets reloaded.
PS: I can now confirm that Acer indeed has no updated firmware for their
Bluetooth adapters BT-500 and does not plan to create one - our
technician has talked to our Acer contact. Thus, I can not recommend
this adapter for any more serious use under Linux.
best regards,
Rene
--
------------------------------------------------
Pervasive 2004: www.pervasive2004.org
------------------------------------------------
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2003-10-21 14:31 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <3F86784F.9050608@soft.uni-linz.ac.at>
[not found] ` <1065778372.14923.336.camel@baroque.rococosoft.com>
[not found] ` <3F86A88E.4090106@soft.uni-linz.ac.at>
[not found] ` <1065790691.14513.173.camel@pegasus>
[not found] ` <3F86AF96.7000904@soft.uni-linz.ac.at>
[not found] ` <1065791594.14514.179.camel@pegasus>
2003-10-10 13:23 ` [Bluez-devel] Re: command tx timeout and continuous inquiry Rene Mayrhofer
2003-10-13 10:28 ` Rene Mayrhofer
2003-10-13 9:19 ` Marcel Holtmann
[not found] ` <3F8FB6D9.8030000@soft.uni-linz.ac.at>
[not found] ` <1066636708.902.5.camel@pegasus>
2003-10-21 10:45 ` Rene Mayrhofer
2003-10-21 11:32 ` Marcel Holtmann
2003-10-21 12:09 ` Rene Mayrhofer
2003-10-21 12:13 ` Marcel Holtmann
2003-10-21 13:04 ` Rene Mayrhofer
2003-10-21 14:31 ` [Bluez-devel] Stress testing (Was: Re: command tx timeout and continuous inquiry.) Rene Mayrhofer
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.