[Bluez-devel] hci_create_connection assuming timeout too soon

[Bluez-devel] hci_create_connection assuming timeout too soon

[Andreas Gaufer]

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

Hi,

I noticed that many tools that use hci_create_connection use a hard coded 
timeout-value that varries between 1000 and 25000. 1000 is much to short for 
most mobile phones. 

This leads to error messages even if the chip didnt report a "connection 
complete" yet. Very often a conection complete with 00 is reported 
later but the tool did exit already.

IMHO we could rely on the chips page timeout and wait for its "connection
complete" event. This timeout can also be changed with hciconfig pageto 
by the user.

To catch a condition where the chip is stalled in some way i think the best 
approach would be to time out on host side after the chips 
page time out * 1,5 or so.

I changed hcitool to make it possible to specifiy the host side
timeout via command line but i dont belive that this is a good aproach because
it only fixes the symthoms not the root of the problem. Anyways I attach the 
patch against the latest CVS-HEAD to show what im talking about.

In the moment my time is extremly short, i will try to bring up some code 
that realy helps here later. Since im not that familiar with C please let me 
know if somethings not right with my changes.

Greetings

Andreas Gaufer


[-- Attachment #2: hcitool.c.diff --]
[-- Type: text/plain, Size: 3597 bytes --]

Index: hcitool.c
===================================================================
RCS file: /cvsroot/bluez/utils/tools/hcitool.c,v
retrieving revision 1.43
diff -u -r1.43 hcitool.c
--- hcitool.c	28 Apr 2004 10:39:47 -0000	1.43
+++ hcitool.c	9 Jun 2004 13:37:35 -0000
@@ -380,12 +380,13 @@
 
 static struct option info_options[] = {
 	{"help",	0,0, 'h'},
+	{"to",		1,0, 't'},
 	{0, 0, 0, 0}
 };
 
 static char *info_help = 
 	"Usage:\n"
-	"\tinfo <bdaddr>\n";
+	"\tinfo [--to=timeout] <bdaddr>\n";
 
 static void cmd_info(int dev_id, int argc, char **argv)
 {
@@ -395,10 +396,14 @@
 	unsigned char features[8];
 	struct hci_version version;
 	struct hci_conn_info_req *cr;
-	int opt, dd, cc = 0;
+	int opt, dd, cc = 0, to = 25000;
 
 	for_each_opt(opt, info_options, NULL) {
 		switch(opt) {
+		case 't':
+			to = atoi(optarg);
+			break;
+			
 		default:
 			printf(info_help);
 			return;
@@ -443,7 +448,7 @@
 	bacpy(&cr->bdaddr, &bdaddr);
 	cr->type = ACL_LINK;
 	if (ioctl(dd, HCIGETCONNINFO, (unsigned long) cr) < 0) {
-		if (hci_create_connection(dd, &bdaddr, htobs(HCI_DM1 | HCI_DH1), 0, 0, &handle, 25000) < 0) {
+		if (hci_create_connection(dd, &bdaddr, htobs(HCI_DM1 | HCI_DH1), 0, 0, &handle, to) < 0) {
 			perror("Can't create connection");
 			close(dd);
 			exit(1);
@@ -454,17 +459,17 @@
 
 	printf("\tBD Address:  %s\n", argv[0]);
 
-	if (hci_read_remote_name(dd, &bdaddr, sizeof(name), name, 25000) == 0)
+	if (hci_read_remote_name(dd, &bdaddr, sizeof(name), name, to) == 0)
 		printf("\tDevice Name: %s\n", name);
 
-	if (hci_read_remote_version(dd, handle, &version, 20000) == 0) {
+	if (hci_read_remote_version(dd, handle, &version, to) == 0) {
 		printf("\tLMP Version: %s (0x%x) LMP Subversion: 0x%x\n"
 			"\tManufacturer: %s (%d)\n",
 			lmp_vertostr(version.lmp_ver), version.lmp_ver, version.lmp_subver, 
 			bt_compidtostr(version.manufacturer), version.manufacturer);
 	}
 
-	if (hci_read_remote_features(dd, handle, features, 20000) == 0) {
+	if (hci_read_remote_features(dd, handle, features, to) == 0) {
 		printf("\tFeatures: 0x%2.2x 0x%2.2x 0x%2.2x 0x%2.2x 0x%2.2x 0x%2.2x 0x%2.2x 0x%2.2x\n%s\n",
 				features[0], features[1], features[2], features[3],
 				features[4], features[5], features[6], features[7],
@@ -472,7 +477,7 @@
 	}
 
 	if (cc)
-		hci_disconnect(dd, handle, HCI_OE_USER_ENDED_CONNECTION, 10000);
+		hci_disconnect(dd, handle, HCI_OE_USER_ENDED_CONNECTION, to);
 
 	close(dd);
 }
@@ -601,12 +606,13 @@
 	{"help",	0,0, 'h'},
 	{"role",	1,0, 'r'},
 	{"ptype",	1,0, 'p'},
+	{"to",	1,0, 't'},
 	{0, 0, 0, 0}
 };
 
 static char *cc_help = 
 	"Usage:\n"
-	"\tcc [--role=m|s] [--ptype=pkt_types] <bdaddr>\n"
+	"\tcc [--role=m|s] [--ptype=pkt_types] [--to=timeout] <bdaddr>\n"
 	"Example:\n"
 	"\tcc --ptype=dm1,dh3,dh5 01:02:03:04:05:06\n"
 	"\tcc --role=m 01:02:03:04:05:06\n";
@@ -614,12 +620,13 @@
 static void cmd_cc(int dev_id, int argc, char **argv)
 {
 	bdaddr_t bdaddr;
-	int opt, ptype, dd;
+	int opt, ptype, dd, to;
 	uint16_t handle;
 	uint8_t role;
 
 	role = 0;
 	ptype = HCI_DM1 | HCI_DM3 | HCI_DM5 | HCI_DH1 | HCI_DH3 | HCI_DH5;
+	to = 1000;
 
 	for_each_opt(opt, cc_options, NULL) {
 		switch(opt) {
@@ -630,6 +637,10 @@
 		case 'r':
 			role = optarg[0] == 'm' ? 0 : 1;
 			break;
+		
+		case 't':
+			to = atoi(optarg);
+			break;
 
 		default:
 			printf(cc_help);
@@ -660,7 +671,7 @@
 		exit(1);
 	}
 
-	if (hci_create_connection(dd, &bdaddr, htobs(ptype), 0, role, &handle, 1000) < 0)
+	if (hci_create_connection(dd, &bdaddr, htobs(ptype), 0, role, &handle, to) < 0)
 		perror("Can't create connection");
 	hci_close_dev(dd);
 }

Re: [Bluez-devel] hci_create_connection assuming timeout too soon

[Marcel Holtmann]

Hi Andreas,

> I noticed that many tools that use hci_create_connection use a hard coded 
> timeout-value that varries between 1000 and 25000. 1000 is much to short for 
> most mobile phones. 
> 
> This leads to error messages even if the chip didnt report a "connection 
> complete" yet. Very often a conection complete with 00 is reported 
> later but the tool did exit already.
> 
> IMHO we could rely on the chips page timeout and wait for its "connection
> complete" event. This timeout can also be changed with hciconfig pageto 
> by the user.
> 
> To catch a condition where the chip is stalled in some way i think the best 
> approach would be to time out on host side after the chips 
> page time out * 1,5 or so.
> 
> I changed hcitool to make it possible to specifiy the host side
> timeout via command line but i dont belive that this is a good aproach because
> it only fixes the symthoms not the root of the problem. Anyways I attach the 
> patch against the latest CVS-HEAD to show what im talking about.
> 
> In the moment my time is extremly short, i will try to bring up some code 
> that realy helps here later. Since im not that familiar with C please let me 
> know if somethings not right with my changes.

your change is me too much at the moment. I simply changed the timeout
to 25000 for the hcitool cc command.

Regards

Marcel




-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
>From Windows to Linux, servers to mobile, InstallShield X is the
one installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] hci_create_connection assuming timeout too soon

[Steven Singer]

Marcel Holtmann wrote:
>Andreas Gaufer wrote:
>> To catch a condition where the chip is stalled in some way i think the best
>> approach would be to time out on host side after the chips
>> page time out * 1,5 or so.

Even that might not be sufficient.

There are two potentially large delays, you've identified just one - the
page timeout. By default this is just over 5 seconds, but it could be
raised as high as 41 seconds.

The page timeout, however, is applied only over the initial baseband
connection. Before the connection complete event can be reported to the
host, the LMP negotiation also has to take place. This can include
authentication and pairing. In theory, the whole LMP negotiation should
be bounded by a 30 second timeout, but, in practice I suspect it's better
to err on the cautious side.

Normally, this isn't a problem as you just wait for the connection
complete event and it'll give a success or failure code. However, I
understand that you want to detect non-responsive host controllers.

> your change is me too much at the moment. I simply changed the timeout
> to 25000 for the hcitool cc command.

If you want just a rough figure that'll probably work, I'd suggest
assuming that the page timeout is about 10 seconds and allow the full
30 seconds LMP timeout. That'd give a 40 second timeout.

If you wanted to be sure, then somwhere above 71 seconds is better, but
to be really, really sure I suspect 2 minutes is better still.

If this is too long, then I suggest a shorter timeout on the command
status event. This event should always be reported promptly. You
could get away with a one second timeout on that followed by a two
minute timeout on the connection complete event.

	- Steven
-- 




**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************

Re: [Bluez-devel] hci_create_connection assuming timeout too soon

[Marcel Holtmann]

Hi Steven,

> There are two potentially large delays, you've identified just one - the
> page timeout. By default this is just over 5 seconds, but it could be
> raised as high as 41 seconds.
> 
> The page timeout, however, is applied only over the initial baseband
> connection. Before the connection complete event can be reported to the
> host, the LMP negotiation also has to take place. This can include
> authentication and pairing. In theory, the whole LMP negotiation should
> be bounded by a 30 second timeout, but, in practice I suspect it's better
> to err on the cautious side.
> 
> Normally, this isn't a problem as you just wait for the connection
> complete event and it'll give a success or failure code. However, I
> understand that you want to detect non-responsive host controllers.

the kernel uses a connect timeout of 40 seconds. This was working fine
in the past.

> > your change is me too much at the moment. I simply changed the timeout
> > to 25000 for the hcitool cc command.
> 
> If you want just a rough figure that'll probably work, I'd suggest
> assuming that the page timeout is about 10 seconds and allow the full
> 30 seconds LMP timeout. That'd give a 40 second timeout.
> 
> If you wanted to be sure, then somwhere above 71 seconds is better, but
> to be really, really sure I suspect 2 minutes is better still.
> 
> If this is too long, then I suggest a shorter timeout on the command
> status event. This event should always be reported promptly. You
> could get away with a one second timeout on that followed by a two
> minute timeout on the connection complete event.

I fully agree with you, but the "hcitool cc ..." is more for debugging
as for daily use. If people rely on it I can't help them, because in
general a ACL link should only be created by the kernel and not from
userspace. And this means the L2CAP layer would cause the Bluetooth core
to create the ACL link.

Regards

Marcel




-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
>From Windows to Linux, servers to mobile, InstallShield X is the
one installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel