Skip to contentSkip to conversation

Multiple Bluetooth connections

Bluez-users Superseded Pedro Monjo Florit 5 participants 12 messages Mar 15, 2005 – Feb 4, 2019 1 message not in the archive

Subsystems (2)
Bluetooth drivers Bluetooth

v2 of 3 Superseded Latest is v3 →

lore
Share & tools
lore

Pedro Monjo Florit

author
#0 lore raw

Hi,

In the application that I am developing, I want to send simultaneous OBEX messages to different OBEX servers over Bluetooth. I am using OpenOBEX for this purpose. There are two problems I am facing.

On the one hand, it seems that there is only room to establish one Bluetooth connection at a time. If I start many OBEX pushes simultaneously, only the first one succeeds. The others fail usually with error "Device or resource busy" (errno=16); sometimes even with "Software caused connection abort" (errno=103). Once the first connection is established and while sending OBEX data, I can establish another connection.

I just want to make clear that the problem is with the establishment of the connection. I am fully aware that it is possible to handle various on-going connections with no problems and I have succeeded with that. Is there a limitation with Bluetooth or BlueZ that allows only one RFCOMM, L2CAP or HCI connection establishment?

On the other hand, some connections die before sending the data, but it seems that the file descriptor of this connection does not receive any notification (I use select() on all file descriptors, with the file descriptor in the read mask). I know that this could be due to a problem with my program, a problem with OpenOBEX or the BlueZ version I am using (it is not the latest). In any case, to track down the cause, I would like to know how can I monitor the Bluetooth connections (at any level, but preferably RFCOMM) that a process (or the whole system) has. What I am looking for is a tool like netstat.

Thanks & regards,

Pedro Monjo

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users

#1 lore raw

It is quite as my problem, I can't find any documentation about bluetooth java and multiple connections, I create to threads that open a RFCOMM connection on my computer, and try to connect a mobile phone or a pda, but only one thread receive the connection and the seconde mobile unit can't establish the link with the server.

It is not enough documentated.

If somebody can help us....

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users

maintainer
#2 lore raw
In reply to Pedro Monjo Florit

Hi Pedro,

Quoted 12 lines

In the application that I am developing, I want to send simultaneous OBEX messages to different OBEX servers over Bluetooth. I am using OpenOBEX for this purpose. There are two problems I am facing.

On the one hand, it seems that there is only room to establish one Bluetooth connection at a time. If I start many OBEX pushes simultaneously, only the first one succeeds. The others fail usually with error "Device or resource busy" (errno=16); sometimes even with "Software caused connection abort" (errno=103). Once the first connection is established and while sending OBEX data, I can establish another connection.

Quoted 5 lines

I just want to make clear that the problem is with the establishment of the connection. I am fully aware that it is possible to handle various on-going connections with no problems and I have succeeded with that. Is there a limitation with Bluetooth or BlueZ that allows only one RFCOMM, L2CAP or HCI connection establishment?

this is a hardware limit and I don't know of any chip that is capable of establishing two connections at the same time. From what I know this will never be possible, but you should better ask a radio/baseband expert for a correct answer.

Quoted 9 lines

On the other hand, some connections die before sending the data, but it seems that the file descriptor of this connection does not receive any notification (I use select() on all file descriptors, with the file descriptor in the read mask). I know that this could be due to a problem with my program, a problem with OpenOBEX or the BlueZ version I am using (it is not the latest). In any case, to track down the cause, I would like to know how can I monitor the Bluetooth connections (at any level, but preferably RFCOMM) that a process (or the whole system) has. What I am looking for is a tool like netstat.

Using poll() or select() is the right way. About what version of the kernel and library/utils are we talking?

Regards

Marcel

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users

A message that is not in the archive (sent off-list or not yet received): [email protected]

#4 lore raw
Quoted 4 lines · Marcel Holtmann

this is a hardware limit and I don't know of any chip that is capable of establishing two connections at the same time. From what I know this will never be possible, but you should better ask a radio/baseband expert for a correct answer.

Below HCI, it won't work in a typical set up. The usual scan mode is "R1 page scan repetition mode" where the device scans at least (and usually only) every 1.28 seconds, usually for 18 slots. If you try to page two devices at once, you run the risk of switching to paging the other device at exactly the short window you need to pick up one device, and hence miss it altogether. You can do it when the devices are in "R0" (continuous scan) but then connection time should be more or less instantaneous anyway and there's no gain. So it's not supported by HCI_Create_Connection.

Once you have an ACL connection, it should be entirely possible to negotiate multiple channels over the top of it, depending on the software.

pws

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

**********************************************************************

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users

#5 lore raw

PATCH v2 1/1 Bluetooth: Support fast advertising interval

In reply to a message not in the archive

Changes made to add support for fast advertising interval as per core 4.1 specification, section 9.3.11.2.

A peripheral device entering any of the following GAP modes and sending either non-connectable advertising events or scannable undirected advertising events should use adv_fast_interval2(100ms - 150ms) for adv_fast_period(30s).
- Non-Discoverable Mode
- Non-Connectable Mode
- Limited Discoverable Mode
- General Discoverable Mode

Signed-off-by Bharat Bhusan Panda <[email protected]>
---
 include/net/bluetooth/hci_core.h |  2 ++
 net/bluetooth/hci_request.c      | 27 +++++++++++++++++++++++++++
 2 files changed, 29 insertions(+)
include/net/bluetooth/hci_core.h +2 -0
index 0db1b9b..868c2fb 100644
@@ -1491,6 +1491,8 @@ struct hci_mgmt_chan {
 #define DISCOV_INTERLEAVED_INQUIRY_LEN	0x04
 #define DISCOV_BREDR_INQUIRY_LEN	0x08
 #define DISCOV_LE_RESTART_DELAY		msecs_to_jiffies(200)	/* msec */
+#define DISCOV_LE_FAST_ADV_INT_MIN	100	/* msec */
+#define DISCOV_LE_FAST_ADV_INT_MAX	150	/* msec */
 
 void mgmt_fill_version_info(void *ver);
 int mgmt_new_settings(struct hci_dev *hdev);
net/bluetooth/hci_request.c +27 -0
index e8c9ef1..fe43498 100644
@@ -1092,6 +1092,33 @@ void __hci_req_enable_advertising(struct hci_request *req)
 	else
 		cp.type = LE_ADV_NONCONN_IND;
 
+	/* As per core 4.1 spec, section 9.3.11.2: A peripheral device
+	 * entering any of the following GAP modes and sending either
+	 * non-connectable advertising events or scannable undirected
+	 * advertising events should use adv_fast_interval2(100ms - 150ms)
+	 * for adv_fast_period(30s).
+	 *
+	 * 	- Non-Discoverable Mode
+	 *	- Non-Connectable Mode
+	 * 	- Limited Discoverable Mode
+	 * 	- General Discoverable Mode
+	 */
+	if (cp.type == LE_ADV_NONCONN_IND || cp.type == LE_ADV_SCAN_IND) {
+		/* Set the suggested min and max fast advertising interval,
+		 * only if the peripheral device has entered any of the modes
+		 * such as non-discoverable, non-connectable or limited-
+		 * discoverable.
+		 */
+		if (!hci_dev_test_flag(hdev, HCI_DISCOVERABLE) ||
+			!hci_dev_test_flag(hdev, HCI_CONNECTABLE) ||
+			hci_dev_test_flag(hdev, HCI_LIMITED_DISCOVERABLE)) {
+			cp.min_interval =
+				cpu_to_le16(DISCOV_LE_FAST_ADV_INT_MIN);
+			cp.max_interval =
+				cpu_to_le16(DISCOV_LE_FAST_ADV_INT_MAX);
+		}
+	}
+
 	cp.own_address_type = own_addr_type;
 	cp.channel_map = hdev->le_adv_channel_map;
Signature · 1 line
1.9.1
#6 lore raw

RE: [PATCH v2] Bluetooth: Support fast advertising interval

Soft reminder.

Quoted 82 lines

-----Original Message-----
From: [email protected] [mailto:linux-bluetooth- [email protected]] On Behalf Of Bharat Bhusan Panda
Sent: Tuesday, October 30, 2018 3:55 PM
To: [email protected]
Subject: [PATCH v2] Bluetooth: Support fast advertising interval

Changes made to add support for fast advertising interval as per core 4.1 specification, section 9.3.11.2.

A peripheral device entering any of the following GAP modes and sending either non-connectable advertising events or scannable undirected advertising events should use adv_fast_interval2(100ms - 150ms) for adv_fast_period(30s).
- Non-Discoverable Mode
- Non-Connectable Mode
- Limited Discoverable Mode
- General Discoverable Mode

Signed-off-by Bharat Bhusan Panda <[email protected]>
---
 include/net/bluetooth/hci_core.h |  2 ++
 net/bluetooth/hci_request.c      | 27 +++++++++++++++++++++++++++
 2 files changed, 29 insertions(+)
include/net/bluetooth/hci_core.h +0 -0
index 0db1b9b..868c2fb 100644
@@ -1491,6 +1491,8 @@ struct hci_mgmt_chan {
 #define DISCOV_INTERLEAVED_INQUIRY_LEN	0x04
 #define DISCOV_BREDR_INQUIRY_LEN	0x08
 #define DISCOV_LE_RESTART_DELAY		msecs_to_jiffies(200)	/*

msec */

include/net/bluetooth/hci_core.h +2 -0
+#define DISCOV_LE_FAST_ADV_INT_MIN	100	/* msec */
+#define DISCOV_LE_FAST_ADV_INT_MAX	150	/* msec */
 
 void mgmt_fill_version_info(void *ver);  int mgmt_new_settings(struct hci_dev

*hdev); diff --git a/net/bluetooth/hci_request.c b/net/bluetooth/hci_request.c index e8c9ef1..fe43498 100644

net/bluetooth/hci_request.c +24 -0
@@ -1092,6 +1092,33 @@ void __hci_req_enable_advertising(struct
 hci_request *req)
 	else
 		cp.type = LE_ADV_NONCONN_IND;
 
+	/* As per core 4.1 spec, section 9.3.11.2: A peripheral device
+	 * entering any of the following GAP modes and sending either
+	 * non-connectable advertising events or scannable undirected
+	 * advertising events should use adv_fast_interval2(100ms - 150ms)
+	 * for adv_fast_period(30s).
+	 *
+	 * 	- Non-Discoverable Mode
+	 *	- Non-Connectable Mode
+	 * 	- Limited Discoverable Mode
+	 * 	- General Discoverable Mode
+	 */
+	if (cp.type == LE_ADV_NONCONN_IND || cp.type ==
 LE_ADV_SCAN_IND) {
+		/* Set the suggested min and max fast advertising interval,
+		 * only if the peripheral device has entered any of the modes
+		 * such as non-discoverable, non-connectable or limited-
+		 * discoverable.
+		 */
+		if (!hci_dev_test_flag(hdev, HCI_DISCOVERABLE) ||
+			!hci_dev_test_flag(hdev, HCI_CONNECTABLE) ||
+			hci_dev_test_flag(hdev, HCI_LIMITED_DISCOVERABLE))
 {
+			cp.min_interval =
+				cpu_to_le16(DISCOV_LE_FAST_ADV_INT_MIN);
+			cp.max_interval =
+

	cpu_to_le16(DISCOV_LE_FAST_ADV_INT_MAX);
net/bluetooth/hci_request.c +3 -1
+		}
+	}
+
 	cp.own_address_type = own_addr_type;
 	cp.channel_map = hdev->le_adv_channel_map;
 
--

1.9.1

#7 lore raw

RE: [PATCH v2] Bluetooth: Support fast advertising interval

Ping

Quoted 93 lines

-----Original Message-----
From: Panda, Bharat B
Sent: Tuesday, November 13, 2018 2:31 PM
To: [email protected]; 'Marcel Holtmann' <[email protected]>
Cc: Panda, Bharat B <[email protected]>
Subject: RE: [PATCH v2] Bluetooth: Support fast advertising interval

Soft reminder.

Quoted 7 lines

-----Original Message-----
From: [email protected] [mailto:linux-bluetooth- [email protected]] On Behalf Of Bharat Bhusan Panda
Sent: Tuesday, October 30, 2018 3:55 PM
To: [email protected]
Subject: [PATCH v2] Bluetooth: Support fast advertising interval

Quoted 6 lines

Changes made to add support for fast advertising interval as per core 4.1 specification, section 9.3.11.2.

A peripheral device entering any of the following GAP modes and sending either non-connectable advertising events or scannable undirected advertising events should use adv_fast_interval2(100ms - 150ms)

for adv_fast_period(30s).

Quoted 69 lines

- Non-Discoverable Mode
- Non-Connectable Mode
- Limited Discoverable Mode
- General Discoverable Mode

Signed-off-by Bharat Bhusan Panda <[email protected]>
---
 include/net/bluetooth/hci_core.h |  2 ++
 net/bluetooth/hci_request.c      | 27 +++++++++++++++++++++++++++
 2 files changed, 29 insertions(+)
include/net/bluetooth/hci_core.h +0 -0
index 0db1b9b..868c2fb 100644
@@ -1491,6 +1491,8 @@ struct hci_mgmt_chan {
 #define DISCOV_INTERLEAVED_INQUIRY_LEN	0x04
 #define DISCOV_BREDR_INQUIRY_LEN	0x08
 #define DISCOV_LE_RESTART_DELAY		msecs_to_jiffies(200)	/*

msec */

include/net/bluetooth/hci_core.h +2 -0
+#define DISCOV_LE_FAST_ADV_INT_MIN	100	/* msec */
+#define DISCOV_LE_FAST_ADV_INT_MAX	150	/* msec */
 
 void mgmt_fill_version_info(void *ver);  int mgmt_new_settings(struct

hci_dev *hdev); diff --git a/net/bluetooth/hci_request.c b/net/bluetooth/hci_request.c index e8c9ef1..fe43498 100644

net/bluetooth/hci_request.c +24 -0
@@ -1092,6 +1092,33 @@ void __hci_req_enable_advertising(struct
 hci_request *req)
 	else
 		cp.type = LE_ADV_NONCONN_IND;
 
+	/* As per core 4.1 spec, section 9.3.11.2: A peripheral device
+	 * entering any of the following GAP modes and sending either
+	 * non-connectable advertising events or scannable undirected
+	 * advertising events should use adv_fast_interval2(100ms - 150ms)
+	 * for adv_fast_period(30s).
+	 *
+	 * 	- Non-Discoverable Mode
+	 *	- Non-Connectable Mode
+	 * 	- Limited Discoverable Mode
+	 * 	- General Discoverable Mode
+	 */
+	if (cp.type == LE_ADV_NONCONN_IND || cp.type ==
 LE_ADV_SCAN_IND) {
+		/* Set the suggested min and max fast advertising interval,
+		 * only if the peripheral device has entered any of the modes
+		 * such as non-discoverable, non-connectable or limited-
+		 * discoverable.
+		 */
+		if (!hci_dev_test_flag(hdev, HCI_DISCOVERABLE) ||
+			!hci_dev_test_flag(hdev, HCI_CONNECTABLE) ||
+			hci_dev_test_flag(hdev, HCI_LIMITED_DISCOVERABLE))
 {
+			cp.min_interval =
+				cpu_to_le16(DISCOV_LE_FAST_ADV_INT_MIN);
+			cp.max_interval =
+

	cpu_to_le16(DISCOV_LE_FAST_ADV_INT_MAX);
net/bluetooth/hci_request.c +3 -1
+		}
+	}
+
 	cp.own_address_type = own_addr_type;
 	cp.channel_map = hdev->le_adv_channel_map;
 
--

1.9.1

#8 lore raw

RE: [PATCH v2] Bluetooth: Support fast advertising interval

Any update on this.

Quoted 107 lines

-----Original Message-----
From: [email protected] [mailto:linux-bluetooth- [email protected]] On Behalf Of Panda, Bharat B
Sent: Friday, November 23, 2018 4:22 PM
To: [email protected]; 'Marcel Holtmann' <[email protected]>
Subject: RE: [PATCH v2] Bluetooth: Support fast advertising interval

Ping

Quoted 37 lines

-----Original Message-----
From: Panda, Bharat B
Sent: Tuesday, November 13, 2018 2:31 PM
To: [email protected]; 'Marcel Holtmann' <[email protected]>
Cc: Panda, Bharat B <[email protected]>
Subject: RE: [PATCH v2] Bluetooth: Support fast advertising interval

Soft reminder.

Quoted 7 lines

-----Original Message-----
From: [email protected] [mailto:linux-bluetooth- [email protected]] On Behalf Of Bharat Bhusan Panda
Sent: Tuesday, October 30, 2018 3:55 PM
To: [email protected]
Subject: [PATCH v2] Bluetooth: Support fast advertising interval

Quoted 8 lines

Changes made to add support for fast advertising interval as per core
4.1 specification, section 9.3.11.2.

A peripheral device entering any of the following GAP modes and sending either non-connectable advertising events or scannable undirected advertising events should use adv_fast_interval2(100ms - 150ms)

for adv_fast_period(30s).

Quoted 11 lines

- Non-Discoverable Mode
- Non-Connectable Mode
- Limited Discoverable Mode
- General Discoverable Mode

Signed-off-by Bharat Bhusan Panda <[email protected]>
---
 include/net/bluetooth/hci_core.h |  2 ++
 net/bluetooth/hci_request.c      | 27 +++++++++++++++++++++++++++
 2 files changed, 29 insertions(+)
Quoted 9 lines

include/net/bluetooth/hci_core.h struct hci_mgmt_chan { · line 1493

Quoted 9 lines
include/net/bluetooth/hci_core.h +0 -0
index 0db1b9b..868c2fb 100644
@@ -1491,6 +1491,8 @@ struct hci_mgmt_chan {
 #define DISCOV_INTERLEAVED_INQUIRY_LEN	0x04
 #define DISCOV_BREDR_INQUIRY_LEN	0x08
 #define DISCOV_LE_RESTART_DELAY		msecs_to_jiffies(200)

	/*
Quoted 50 lines
Quoted 50 lines

msec */

include/net/bluetooth/hci_core.h +2 -0
+#define DISCOV_LE_FAST_ADV_INT_MIN	100	/* msec */
+#define DISCOV_LE_FAST_ADV_INT_MAX	150	/* msec */
 
 void mgmt_fill_version_info(void *ver);  int

mgmt_new_settings(struct hci_dev *hdev); diff --git a/net/bluetooth/hci_request.c b/net/bluetooth/hci_request.c index e8c9ef1..fe43498 100644

net/bluetooth/hci_request.c +24 -0
@@ -1092,6 +1092,33 @@ void __hci_req_enable_advertising(struct
 hci_request *req)
 	else
 		cp.type = LE_ADV_NONCONN_IND;
 
+	/* As per core 4.1 spec, section 9.3.11.2: A peripheral device
+	 * entering any of the following GAP modes and sending either
+	 * non-connectable advertising events or scannable undirected
+	 * advertising events should use adv_fast_interval2(100ms - 150ms)
+	 * for adv_fast_period(30s).
+	 *
+	 * 	- Non-Discoverable Mode
+	 *	- Non-Connectable Mode
+	 * 	- Limited Discoverable Mode
+	 * 	- General Discoverable Mode
+	 */
+	if (cp.type == LE_ADV_NONCONN_IND || cp.type ==
 LE_ADV_SCAN_IND) {
+		/* Set the suggested min and max fast advertising interval,
+		 * only if the peripheral device has entered any of the modes
+		 * such as non-discoverable, non-connectable or limited-
+		 * discoverable.
+		 */
+		if (!hci_dev_test_flag(hdev, HCI_DISCOVERABLE) ||
+			!hci_dev_test_flag(hdev, HCI_CONNECTABLE) ||
+			hci_dev_test_flag(hdev, HCI_LIMITED_DISCOVERABLE))
 {
+			cp.min_interval =
+				cpu_to_le16(DISCOV_LE_FAST_ADV_INT_MIN);
+			cp.max_interval =
+

	cpu_to_le16(DISCOV_LE_FAST_ADV_INT_MAX);
net/bluetooth/hci_request.c +3 -1
+		}
+	}
+
 	cp.own_address_type = own_addr_type;
 	cp.channel_map = hdev->le_adv_channel_map;
 
--

1.9.1

maintainer
#9 lore raw

Re: [PATCH v2] Bluetooth: Support fast advertising interval

In reply to Bharat Bhusan Panda

Hi Bharat,

Quoted 49 lines

Changes made to add support for fast advertising interval as per core 4.1 specification, section 9.3.11.2.

A peripheral device entering any of the following GAP modes and sending either non-connectable advertising events or scannable undirected advertising events should use adv_fast_interval2(100ms - 150ms) for adv_fast_period(30s).
- Non-Discoverable Mode
- Non-Connectable Mode
- Limited Discoverable Mode
- General Discoverable Mode

Signed-off-by Bharat Bhusan Panda <[email protected]>

---
include/net/bluetooth/hci_core.h | 2 ++
net/bluetooth/hci_request.c | 27 +++++++++++++++++++++++++++

2 files changed, 29 insertions(+)
include/net/bluetooth/hci_core.h +2 -0
index 0db1b9b..868c2fb 100644
@@ -1491,6 +1491,8 @@ struct hci_mgmt_chan {
 #define DISCOV_INTERLEAVED_INQUIRY_LEN	0x04
 #define DISCOV_BREDR_INQUIRY_LEN	0x08
 #define DISCOV_LE_RESTART_DELAY		msecs_to_jiffies(200)	/* msec */
+#define DISCOV_LE_FAST_ADV_INT_MIN	100	/* msec */
+#define DISCOV_LE_FAST_ADV_INT_MAX	150	/* msec */
 
 void mgmt_fill_version_info(void *ver);
 int mgmt_new_settings(struct hci_dev *hdev);
net/bluetooth/hci_request.c +10 -0
index e8c9ef1..fe43498 100644
@@ -1092,6 +1092,33 @@ void __hci_req_enable_advertising(struct hci_request *req)
 	else
 		cp.type = LE_ADV_NONCONN_IND;
 
+	/* As per core 4.1 spec, section 9.3.11.2: A peripheral device
+	 * entering any of the following GAP modes and sending either
+	 * non-connectable advertising events or scannable undirected
+	 * advertising events should use adv_fast_interval2(100ms - 150ms)
+	 * for adv_fast_period(30s).
+	 *
+	 * 	- Non-Discoverable Mode
+	 *	- Non-Connectable Mode
+	 * 	- Limited Discoverable Mode
+	 * 	- General Discoverable Mode

net/bluetooth/hci_request.c void __hci_req_enable_advertising(struct hci_request *req) · line 1114

Quoted 10 lines
net/bluetooth/hci_request.c +10 -0
+	 */
+	if (cp.type == LE_ADV_NONCONN_IND || cp.type == LE_ADV_SCAN_IND) {
+		/* Set the suggested min and max fast advertising interval,
+		 * only if the peripheral device has entered any of the modes
+		 * such as non-discoverable, non-connectable or limited-
+		 * discoverable.
+		 */
+		if (!hci_dev_test_flag(hdev, HCI_DISCOVERABLE) ||
+			!hci_dev_test_flag(hdev, HCI_CONNECTABLE) ||
+			hci_dev_test_flag(hdev, HCI_LIMITED_DISCOVERABLE)) {

this is still wrongly indented.

net/bluetooth/hci_request.c void __hci_req_enable_advertising(struct hci_request *req) · line 1121

Quoted 7 lines
net/bluetooth/hci_request.c +7 -0
+			cp.min_interval =
+				cpu_to_le16(DISCOV_LE_FAST_ADV_INT_MIN);
+			cp.max_interval =
+				cpu_to_le16(DISCOV_LE_FAST_ADV_INT_MAX);
+		}
+	}
+

Regards

Marcel

#10 lore raw

RE: [PATCH v2] Bluetooth: Support fast advertising interval

Hi Marcel,

Quoted 73 lines

-----Original Message-----
From: Marcel Holtmann [mailto:[email protected]]
Sent: Wednesday, December 19, 2018 5:00 AM
To: Panda, Bharat B <[email protected]>
Cc: [email protected]
Subject: Re: [PATCH v2] Bluetooth: Support fast advertising interval

Hi Bharat,

Quoted 24 lines

Changes made to add support for fast advertising interval as per core 4.1 specification, section 9.3.11.2.

A peripheral device entering any of the following GAP modes and sending either non-connectable advertising events or scannable undirected advertising events should use adv_fast_interval2(100ms - 150ms) for adv_fast_period(30s).
- Non-Discoverable Mode
- Non-Connectable Mode
- Limited Discoverable Mode
- General Discoverable Mode

Signed-off-by Bharat Bhusan Panda <[email protected]>

---
include/net/bluetooth/hci_core.h | 2 ++
net/bluetooth/hci_request.c | 27 +++++++++++++++++++++++++++

2 files changed, 29 insertions(+)
include/net/bluetooth/hci_core.h +0 -0
index 0db1b9b..868c2fb 100644

include/net/bluetooth/hci_core.h struct hci_mgmt_chan { · line 1493

Quoted 3 lines
include/net/bluetooth/hci_core.h +0 -0
@@ -1491,6 +1491,8 @@ struct hci_mgmt_chan {
 #define DISCOV_INTERLEAVED_INQUIRY_LEN	0x04
 #define DISCOV_BREDR_INQUIRY_LEN	0x08
 #define DISCOV_LE_RESTART_DELAY		msecs_to_jiffies(200)	/*

msec */

net/bluetooth/hci_request.c void __hci_req_enable_advertising(struct

Quoted 9 lines
include/net/bluetooth/hci_core.h +2 -0
+#define DISCOV_LE_FAST_ADV_INT_MIN	100	/* msec */
+#define DISCOV_LE_FAST_ADV_INT_MAX	150	/* msec */

void mgmt_fill_version_info(void *ver); int mgmt_new_settings(struct hci_dev *hdev); diff --git a/net/bluetooth/hci_request.c b/net/bluetooth/hci_request.c index e8c9ef1..fe43498 100644

net/bluetooth/hci_request.c +0 -0
@@ -1092,6 +1092,33 @@ void __hci_req_enable_advertising(struct

hci_request *req)

Quoted 5 lines
net/bluetooth/hci_request.c +2 -0
 	else
 		cp.type = LE_ADV_NONCONN_IND;
 
+	/* As per core 4.1 spec, section 9.3.11.2: A peripheral device
+	 * entering any of the following GAP modes and sending either

net/bluetooth/hci_request.c void __hci_req_enable_advertising(struct hci_request *req)

Quoted 10 lines
net/bluetooth/hci_request.c +10 -0
+	 * non-connectable advertising events or scannable undirected
+	 * advertising events should use adv_fast_interval2(100ms - 150ms)
+	 * for adv_fast_period(30s).
+	 *
+	 * 	- Non-Discoverable Mode
+	 *	- Non-Connectable Mode
+	 * 	- Limited Discoverable Mode
+	 * 	- General Discoverable Mode
+	 */
+	if (cp.type == LE_ADV_NONCONN_IND || cp.type ==

LE_ADV_SCAN_IND) {

net/bluetooth/hci_request.c void __hci_req_enable_advertising(struct hci_request *req)

Quoted 8 lines
net/bluetooth/hci_request.c +8 -0
+		/* Set the suggested min and max fast advertising interval,
+		 * only if the peripheral device has entered any of the modes
+		 * such as non-discoverable, non-connectable or limited-
+		 * discoverable.
+		 */
+		if (!hci_dev_test_flag(hdev, HCI_DISCOVERABLE) ||
+			!hci_dev_test_flag(hdev, HCI_CONNECTABLE) ||
+			hci_dev_test_flag(hdev, HCI_LIMITED_DISCOVERABLE))

{

Quoted 1 line

this is still wrongly indented.

Sorry for replying late, I have made the correct indentation and submitted v3 for same. Please review.

Quoted 6 lines

net/bluetooth/hci_request.c void __hci_req_enable_advertising(struct hci_request *req) · line 1121

Quoted 5 lines
net/bluetooth/hci_request.c +4 -0
+			cp.min_interval =
+				cpu_to_le16(DISCOV_LE_FAST_ADV_INT_MIN);
+			cp.max_interval =
+

	cpu_to_le16(DISCOV_LE_FAST_ADV_INT_MAX);
Quoted 7 lines

net/bluetooth/hci_request.c void __hci_req_enable_advertising(struct hci_request *req) · line 1121

Quoted 3 lines
net/bluetooth/hci_request.c +3 -0
+		}
+	}
+

Regards

Marcel

Regards,
Bharat

author
#11 lore raw
In reply to Marcel Holtmann

Hi Marcel,

Quoted 5 lines

this is a hardware limit and I don't know of any chip that is capable of establishing two connections at the same time. From what I know this will never be possible, but you should better ask a radio/baseband expert for a correct answer.

Thank you for the information. Together with the post of Peter Stephenson (thank you, Peter), it seems that this problem cannot be circumvented as I want to connect to different devices (as I understand, various ACL connections; is this right?). I will have to live with it. :-(

Quoted 6 lines
Quoted 2 lines

On the other hand, some connections die before sending the data, but it seems that the file descriptor of this connection does not receive any notification (I use select() on all file descriptors, with the file descriptor in the read mask). I know that this could be due to a problem with my program, a problem with OpenOBEX or the BlueZ version I am using (it is not the latest). In any case, to track down the cause, I would like to know how can I monitor the Bluetooth connections (at any level, but preferably RFCOMM) that a process (or the whole system) has. What I am looking for is a tool like netstat.

Using poll() or select() is the right way. About what version of the kernel and library/utils are we talking?

I am using SuSE 9.1 with the latest updates from SuSE: kernel 2.6.5-7.147-default, bluez-libs 2.5-43 and bluez-utils 2.4-65. I know they are old, so it could perfectly be a problem with them; therefore I am planning an upgrade, but I am not quite sure whether I will be able to use the latest BlueZ upgrades. The problem with the lost established connections does not happen always, so I still have to look exactly why this happens. In any case, besides that, everything else works as expected. The only thing I am missing is a tool like "netstat" for Internet an Unix sockets. "lsof" does not give any information either. Is there anything of the like for BlueZ?

In any, case, thanks for the help.

Pedro

maintainer
#12 lore raw

Hi Pedro,

Quoted 10 lines
Quoted 5 lines

this is a hardware limit and I don't know of any chip that is capable of establishing two connections at the same time. From what I know this will never be possible, but you should better ask a radio/baseband expert for a correct answer.

Thank you for the information. Together with the post of Peter Stephenson (thank you, Peter), it seems that this problem cannot be circumvented as I want to connect to different devices (as I understand, various ACL connections; is this right?). I will have to live with it. :-(

you can have multiple ACL connections. If this is a CSR chip you need at least the HCI 16.4 firmware on it. However you can't create them at the same time. If one is established you can create another one. Up to seven if you keep the roles (master/slave) correct.

Quoted 14 lines
Quoted 11 lines
Quoted 10 lines

On the other hand, some connections die before sending the data, but it seems that the file descriptor of this connection does not receive any notification (I use select() on all file descriptors, with the file descriptor in the read mask). I know that this could be due to a problem with my program, a problem with OpenOBEX or the BlueZ version I am using (it is not the latest). In any case, to track down the cause, I would like to know how can I monitor the Bluetooth connections (at any level, but preferably RFCOMM) that a process (or the whole system) has. What I am looking for is a tool like netstat.

Quoted 3 lines

Using poll() or select() is the right way. About what version of the kernel and library/utils are we talking?

Quoted 10 lines

I am using SuSE 9.1 with the latest updates from SuSE: kernel 2.6.5-7.147-default, bluez-libs 2.5-43 and bluez-utils 2.4-65. I know they are old, so it could perfectly be a problem with them; therefore I am planning an upgrade, but I am not quite sure whether I will be able to use the latest BlueZ upgrades. The problem with the lost established connections does not happen always, so I still have to look exactly why this happens. In any case, besides that, everything else works as expected. The only thing I am missing is a tool like "netstat" for Internet an Unix sockets. "lsof" does not give any information either. Is there anything of the like for BlueZ?

We don't have any tool like this. May you wanna check /proc/bluetooth/ and make use of hcidump.

Regards

Marcel

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users