Re: [Bluez-devel] Re: command tx timeout and continuous inquiry.

Re: [Bluez-devel] Re: command tx timeout and continuous inquiry.

[Rene Mayrhofer]

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
------------------------------------------------

Re: [Bluez-devel] Re: command tx timeout and continuous inquiry.

[Rene Mayrhofer]

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
------------------------------------------------

Re: [Bluez-devel] Re: command tx timeout and continuous inquiry.

[Marcel Holtmann]

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

Re: [Bluez-devel] Re: command tx timeout and continuous inquiry.

[Rene Mayrhofer]

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

Re: [Bluez-devel] Re: command tx timeout and continuous inquiry.

[Marcel Holtmann]

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

Re: [Bluez-devel] Re: command tx timeout and continuous inquiry.

[Rene Mayrhofer]

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
------------------------------------------------

Re: [Bluez-devel] Re: command tx timeout and continuous inquiry.

[Marcel Holtmann]

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

Re: [Bluez-devel] Re: command tx timeout and continuous inquiry.

[Rene Mayrhofer]

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
------------------------------------------------

Re: [Bluez-devel] Stress testing (Was: Re: command tx timeout and continuous inquiry.)

[Rene Mayrhofer]

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
------------------------------------------------