From: François Beaufort <hidden> Date: 2015-11-23 14:43:11
Hello everyone!
Would you know why I get a "Status: Unknown Connection Identifier
(0x02)" error while trying to connect to a BLE device, causing a
"Connect failed" message. However sometimes, as you can read below, it
is still able to connect to it.
Bluetooth monitor ver 5.35
...
< HCI Command: LE Set Scan Parameters (0x08|0x000b) plen 7
[hci0] 15:36:33.367332
Type: Passive (0x00)
Interval: 60.000 msec (0x0060)
Window: 30.000 msec (0x0030)
Own address type: Public (0x00)
Filter policy: Ignore not in white list (0x01)
Would you know why I get a "Status: Unknown Connection Identifier
(0x02)" error while trying to connect to a BLE device, causing a
"Connect failed" message. However sometimes, as you can read below, it
is still able to connect to it.
Bluetooth monitor ver 5.35
...
< HCI Command: LE Set Scan Parameters (0x08|0x000b) plen 7
[hci0] 15:36:33.367332
Type: Passive (0x00)
Interval: 60.000 msec (0x0060)
Window: 30.000 msec (0x0030)
Own address type: Public (0x00)
Filter policy: Ignore not in white list (0x01)
LE Create Connection Cancel (0x08|0x000e) ncmd 1
Status: Success (0x00)
here you are cancelling the connection attempt.
quoted
HCI Event: LE Meta Event (0x3e) plen 19 [hci0] 15:36:39.646071
LE Connection Complete (0x01)
Status: Unknown Connection Identifier (0x02)
And this results in a connect complete with the this error. It actually says the create connection cancel has been successful.
I think the real question is why we are ending up with the create connection cancel in the first place. Only 2 seconds after the connection attempt.
This mgmt message might also be bug. It depends on what triggered the connection and the cancel action, but in general we are not tracking the state correctly as it seems. The message will not hurt, but I think it should not be here in the first place.
How are you triggering the connection?
Regards
Marcel
Hi,
On Monday 23 November 2015 18:43:11 Marcel Holtmann wrote:
Hi Francois,
quoted
Would you know why I get a "Status: Unknown Connection Identifier
(0x02)" error while trying to connect to a BLE device, causing a
"Connect failed" message. However sometimes, as you can read below, it
is still able to connect to it.
Bluetooth monitor ver 5.35
...
< HCI Command: LE Set Scan Parameters (0x08|0x000b) plen 7
[hci0] 15:36:33.367332
Type: Passive (0x00)
Interval: 60.000 msec (0x0060)
Window: 30.000 msec (0x0030)
Own address type: Public (0x00)
Filter policy: Ignore not in white list (0x01)
LE Create Connection Cancel (0x08|0x000e) ncmd 1
Status: Success (0x00)
here you are cancelling the connection attempt.
quoted
quoted
HCI Event: LE Meta Event (0x3e) plen 19
[hci0] 15:36:39.646071>>
LE Connection Complete (0x01)
Status: Unknown Connection Identifier (0x02)
And this results in a connect complete with the this error. It actually says
the create connection cancel has been successful.
I think the real question is why we are ending up with the create connection
cancel in the first place. Only 2 seconds after the connection attempt.
This is to not block other devices from connecting if pending connection takes
too long (we can't have more than 1 pending connection).
This mgmt message might also be bug. It depends on what triggered the
connection and the cancel action, but in general we are not tracking the
state correctly as it seems. The message will not hurt, but I think it
should not be here in the first place.
How are you triggering the connection?
Regards
Marcel
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth"
in the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: François Beaufort <hidden> Date: 2015-11-24 09:24:23
Thanks both of you for your input.
Here are my 100% reproducible steps:
- Restart bluetoothd to start fresh
- Remove cached device (remove 88:0F:10:9D:EB:42)
- Run basic scan (scan on)
- Wait for the device to pop up in results and stop scan (scan off)
- Try to connect to it (connect 88:0F:10:9D:EB:42)
As you can read below I now have 2 "LE Connection Complete (0x01)" events.
Bluetooth monitor ver 5.35
= New Index: A4:17:31:78:A6:04 (BR/EDR,USB,hci0)
[hci0] 0.624321
< HCI Command: LE Add Device To White List (0x08|0x0011) plen 7
[hci0] 11.038826
Address type: Public (0x00)
Address: 88:0F:10:9D:EB:42 (OUI 88-0F-10)
LE Add Device To White List (0x08|0x0011) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Scan Parameters (0x08|0x000b) plen 7
[hci0] 11.040125
Type: Passive (0x00)
Interval: 60.000 msec (0x0060)
Window: 30.000 msec (0x0030)
Own address type: Public (0x00)
Filter policy: Ignore not in white list (0x01)
Hi,
On Monday 23 November 2015 18:43:11 Marcel Holtmann wrote:
quoted
Hi Francois,
quoted
Would you know why I get a "Status: Unknown Connection Identifier
(0x02)" error while trying to connect to a BLE device, causing a
"Connect failed" message. However sometimes, as you can read below, it
is still able to connect to it.
Bluetooth monitor ver 5.35
...
< HCI Command: LE Set Scan Parameters (0x08|0x000b) plen 7
[hci0] 15:36:33.367332
Type: Passive (0x00)
Interval: 60.000 msec (0x0060)
Window: 30.000 msec (0x0030)
Own address type: Public (0x00)
Filter policy: Ignore not in white list (0x01)
LE Create Connection Cancel (0x08|0x000e) ncmd 1
Status: Success (0x00)
here you are cancelling the connection attempt.
quoted
quoted
HCI Event: LE Meta Event (0x3e) plen 19
[hci0] 15:36:39.646071>>
LE Connection Complete (0x01)
Status: Unknown Connection Identifier (0x02)
And this results in a connect complete with the this error. It actually says
the create connection cancel has been successful.
I think the real question is why we are ending up with the create connection
cancel in the first place. Only 2 seconds after the connection attempt.
This is to not block other devices from connecting if pending connection takes
too long (we can't have more than 1 pending connection).
This mgmt message might also be bug. It depends on what triggered the
connection and the cancel action, but in general we are not tracking the
state correctly as it seems. The message will not hurt, but I think it
should not be here in the first place.
How are you triggering the connection?
Regards
Marcel
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth"
in the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Thanks both of you for your input.
Here are my 100% reproducible steps:
- Restart bluetoothd to start fresh
- Remove cached device (remove 88:0F:10:9D:EB:42)
- Run basic scan (scan on)
- Wait for the device to pop up in results and stop scan (scan off)
- Try to connect to it (connect 88:0F:10:9D:EB:42)
As you can read below I now have 2 "LE Connection Complete (0x01)" events.
Bluetooth monitor ver 5.35
= New Index: A4:17:31:78:A6:04 (BR/EDR,USB,hci0)
[hci0] 0.624321
< HCI Command: LE Add Device To White List (0x08|0x0011) plen 7
[hci0] 11.038826
Address type: Public (0x00)
Address: 88:0F:10:9D:EB:42 (OUI 88-0F-10)
LE Add Device To White List (0x08|0x0011) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Scan Parameters (0x08|0x000b) plen 7
[hci0] 11.040125
Type: Passive (0x00)
Interval: 60.000 msec (0x0060)
Window: 30.000 msec (0x0030)
Own address type: Public (0x00)
Filter policy: Ignore not in white list (0x01)
we might should have the LE Create Connection scan with a full duty cycle here. So it does not miss any advertising PDUs.
Filter policy: White list is not used (0x00)
Peer address type: Public (0x00)
Peer address: 88:0F:10:9D:EB:42 (OUI 88-0F-10)
Own address type: Public (0x00)
Min connection interval: 50.00 msec (0x0028)
Max connection interval: 70.00 msec (0x0038)
Connection latency: 0x0000
Supervision timeout: 420 msec (0x002a)
Min connection length: 0.000 msec (0x0000)
Max connection length: 0.000 msec (0x0000)
quoted
HCI Event: Command Status (0x0f) plen 4 [hci0] 15.670065
This one still needs to be fixed. It is a bug. The implementation is too naive. The unknown connection identifier is actually the success case for LE Create Connection Cancel command. And since we keep trying until the connection timeout hits, this is not an error at this point.
Regards
Marcel
From: François Beaufort <hidden> Date: 2015-11-24 12:05:06
On Tue, Nov 24, 2015 at 12:00 PM, Marcel Holtmann [off-list ref] wro=
te:
Hi Francois,
quoted
Thanks both of you for your input.
Here are my 100% reproducible steps:
- Restart bluetoothd to start fresh
- Remove cached device (remove 88:0F:10:9D:EB:42)
- Run basic scan (scan on)
- Wait for the device to pop up in results and stop scan (scan off)
- Try to connect to it (connect 88:0F:10:9D:EB:42)
As you can read below I now have 2 "LE Connection Complete (0x01)" event=
s.
quoted
Bluetooth monitor ver 5.35
=3D New Index: A4:17:31:78:A6:04 (BR/EDR,USB,hci0)
[hci0] 0.624321
< HCI Command: LE Add Device To White List (0x08|0x0011) plen 7
[hci0] 11.038826
Address type: Public (0x00)
Address: 88:0F:10:9D:EB:42 (OUI 88-0F-10)
quoted
HCI Event: Command Complete (0x0e) plen 4 =
[hci0] 11.040084
quoted
LE Add Device To White List (0x08|0x0011) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Scan Parameters (0x08|0x000b) plen 7
[hci0] 11.040125
Type: Passive (0x00)
Interval: 60.000 msec (0x0060)
Window: 30.000 msec (0x0030)
Own address type: Public (0x00)
Filter policy: Ignore not in white list (0x01)
quoted
HCI Event: Command Complete (0x0e) plen 4 =
[hci0] 11.041085
quoted
LE Set Scan Parameters (0x08|0x000b) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2
[hci0] 11.041134
Scanning: Enabled (0x01)
Filter duplicates: Enabled (0x01)
quoted
HCI Event: Command Complete (0x0e) plen 4 =
[hci0] 11.042084
quoted
LE Set Scan Enable (0x08|0x000c) ncmd 1
Status: Success (0x00)
quoted
HCI Event: LE Meta Event (0x3e) plen 43 =
[hci0] 15.668141
quoted
LE Advertising Report (0x02)
Num reports: 1
Event type: Connectable undirected - ADV_IND (0x00)
Address type: Public (0x00)
Address: 88:0F:10:9D:EB:42 (OUI 88-0F-10)
Data length: 31
Flags: 0x06
LE General Discoverable Mode
BR/EDR Not Supported
Company: Anhui Huami Information Technology Co., Ltd. (343)
Data: 00f70b676930f4c909f4a5acd792a299ff02880f109deb42
RSSI: -59 dBm (0xc5)
< HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2
[hci0] 15.668289
Scanning: Disabled (0x00)
Filter duplicates: Disabled (0x00)
we might should have the LE Create Connection scan with a full duty cycle=
here. So it does not miss any advertising PDUs.
quoted
Filter policy: White list is not used (0x00)
Peer address type: Public (0x00)
Peer address: 88:0F:10:9D:EB:42 (OUI 88-0F-10)
Own address type: Public (0x00)
Min connection interval: 50.00 msec (0x0028)
Max connection interval: 70.00 msec (0x0038)
Connection latency: 0x0000
Supervision timeout: 420 msec (0x002a)
Min connection length: 0.000 msec (0x0000)
Max connection length: 0.000 msec (0x0000)
This one still needs to be fixed. It is a bug. The implementation is too =
naive. The unknown connection identifier is actually the success case for L=
E Create Connection Cancel command. And since we keep trying until the conn=
ection timeout hits, this is not an error at this point.
Where should I file that bug so that I can keep track of it?
From: François Beaufort <hidden> Date: 2015-11-30 07:43:16
On Tue, Nov 24, 2015 at 12:00 PM, Marcel Holtmann [off-list ref]
wrote:
Hi Francois,
quoted
Thanks both of you for your input.
Here are my 100% reproducible steps:
- Restart bluetoothd to start fresh
- Remove cached device (remove 88:0F:10:9D:EB:42)
- Run basic scan (scan on)
- Wait for the device to pop up in results and stop scan (scan off)
- Try to connect to it (connect 88:0F:10:9D:EB:42)
As you can read below I now have 2 "LE Connection Complete (0x01)"
events.
quoted
Bluetooth monitor ver 5.35
= New Index: A4:17:31:78:A6:04 (BR/EDR,USB,hci0)
[hci0] 0.624321
< HCI Command: LE Add Device To White List (0x08|0x0011) plen 7
[hci0] 11.038826
Address type: Public (0x00)
Address: 88:0F:10:9D:EB:42 (OUI 88-0F-10)
quoted
HCI Event: Command Complete (0x0e) plen 4
[hci0] 11.040084
quoted
LE Add Device To White List (0x08|0x0011) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Scan Parameters (0x08|0x000b) plen 7
[hci0] 11.040125
Type: Passive (0x00)
Interval: 60.000 msec (0x0060)
Window: 30.000 msec (0x0030)
Own address type: Public (0x00)
Filter policy: Ignore not in white list (0x01)
quoted
HCI Event: Command Complete (0x0e) plen 4
[hci0] 11.041085
quoted
LE Set Scan Parameters (0x08|0x000b) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2
[hci0] 11.041134
Scanning: Enabled (0x01)
Filter duplicates: Enabled (0x01)
quoted
HCI Event: Command Complete (0x0e) plen 4
[hci0] 11.042084
quoted
LE Set Scan Enable (0x08|0x000c) ncmd 1
Status: Success (0x00)
quoted
HCI Event: LE Meta Event (0x3e) plen 43
[hci0] 15.668141
quoted
LE Advertising Report (0x02)
Num reports: 1
Event type: Connectable undirected - ADV_IND (0x00)
Address type: Public (0x00)
Address: 88:0F:10:9D:EB:42 (OUI 88-0F-10)
Data length: 31
Flags: 0x06
LE General Discoverable Mode
BR/EDR Not Supported
Company: Anhui Huami Information Technology Co., Ltd. (343)
Data: 00f70b676930f4c909f4a5acd792a299ff02880f109deb42
RSSI: -59 dBm (0xc5)
< HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2
[hci0] 15.668289
Scanning: Disabled (0x00)
Filter duplicates: Disabled (0x00)
we might should have the LE Create Connection scan with a full duty cycle
here. So it does not miss any advertising PDUs.
Is this something the Linux Bluetooth team is going to address?
quoted
Filter policy: White list is not used (0x00)
Peer address type: Public (0x00)
Peer address: 88:0F:10:9D:EB:42 (OUI 88-0F-10)
Own address type: Public (0x00)
Min connection interval: 50.00 msec (0x0028)
Max connection interval: 70.00 msec (0x0038)
Connection latency: 0x0000
Supervision timeout: 420 msec (0x002a)
Min connection length: 0.000 msec (0x0000)
Max connection length: 0.000 msec (0x0000)
And I think we need to increase the timeout to something like 4-5 seconds
before we give up and try the next device that might have been found.
For my own curiosity, how does does perform Android Bluetooth stack when
creating a LE connection?
Does it hardcode a 4-5 seconds timeout or does it use other heuristics?
quoted
quoted
HCI Event: Command Complete (0x0e) plen 4
[hci0] 17.672048
quoted
LE Create Connection Cancel (0x08|0x000e) ncmd 1
Status: Success (0x00)
This one still needs to be fixed. It is a bug. The implementation is too
naive. The unknown connection identifier is actually the success case for
LE Create Connection Cancel command. And since we keep trying until the
connection timeout hits, this is not an error at this point.
Regards
Marcel
From: François Beaufort <hidden> Date: 2015-11-30 07:44:27
On Tue, Nov 24, 2015 at 12:00 PM, Marcel Holtmann [off-list ref] wro=
te:
Hi Francois,
quoted
Thanks both of you for your input.
Here are my 100% reproducible steps:
- Restart bluetoothd to start fresh
- Remove cached device (remove 88:0F:10:9D:EB:42)
- Run basic scan (scan on)
- Wait for the device to pop up in results and stop scan (scan off)
- Try to connect to it (connect 88:0F:10:9D:EB:42)
As you can read below I now have 2 "LE Connection Complete (0x01)" event=
s.
quoted
Bluetooth monitor ver 5.35
=3D New Index: A4:17:31:78:A6:04 (BR/EDR,USB,hci0)
[hci0] 0.624321
< HCI Command: LE Add Device To White List (0x08|0x0011) plen 7
[hci0] 11.038826
Address type: Public (0x00)
Address: 88:0F:10:9D:EB:42 (OUI 88-0F-10)
quoted
HCI Event: Command Complete (0x0e) plen 4 =
[hci0] 11.040084
quoted
LE Add Device To White List (0x08|0x0011) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Scan Parameters (0x08|0x000b) plen 7
[hci0] 11.040125
Type: Passive (0x00)
Interval: 60.000 msec (0x0060)
Window: 30.000 msec (0x0030)
Own address type: Public (0x00)
Filter policy: Ignore not in white list (0x01)
quoted
HCI Event: Command Complete (0x0e) plen 4 =
[hci0] 11.041085
quoted
LE Set Scan Parameters (0x08|0x000b) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2
[hci0] 11.041134
Scanning: Enabled (0x01)
Filter duplicates: Enabled (0x01)
quoted
HCI Event: Command Complete (0x0e) plen 4 =
[hci0] 11.042084
quoted
LE Set Scan Enable (0x08|0x000c) ncmd 1
Status: Success (0x00)
quoted
HCI Event: LE Meta Event (0x3e) plen 43 =
[hci0] 15.668141
quoted
LE Advertising Report (0x02)
Num reports: 1
Event type: Connectable undirected - ADV_IND (0x00)
Address type: Public (0x00)
Address: 88:0F:10:9D:EB:42 (OUI 88-0F-10)
Data length: 31
Flags: 0x06
LE General Discoverable Mode
BR/EDR Not Supported
Company: Anhui Huami Information Technology Co., Ltd. (343)
Data: 00f70b676930f4c909f4a5acd792a299ff02880f109deb42
RSSI: -59 dBm (0xc5)
< HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2
[hci0] 15.668289
Scanning: Disabled (0x00)
Filter duplicates: Disabled (0x00)
we might should have the LE Create Connection scan with a full duty cycle=
here. So it does not miss any advertising PDUs.
Is this something the Linux Bluetooth team is going to address?
quoted
Filter policy: White list is not used (0x00)
Peer address type: Public (0x00)
Peer address: 88:0F:10:9D:EB:42 (OUI 88-0F-10)
Own address type: Public (0x00)
Min connection interval: 50.00 msec (0x0028)
Max connection interval: 70.00 msec (0x0038)
Connection latency: 0x0000
Supervision timeout: 420 msec (0x002a)
Min connection length: 0.000 msec (0x0000)
Max connection length: 0.000 msec (0x0000)
And I think we need to increase the timeout to something like 4-5 seconds=
before we give up and try the next device that might have been found.
For my own curiosity, how does does perform Android Bluetooth stack
when creating a LE connection?
Does it hardcode a 4-5 seconds timeout or does it use other heuristics?
quoted
quoted
HCI Event: Command Complete (0x0e) plen 4 =
[hci0] 17.672048
quoted
LE Create Connection Cancel (0x08|0x000e) ncmd 1
Status: Success (0x00)
This one still needs to be fixed. It is a bug. The implementation is too =
naive. The unknown connection identifier is actually the success case for L=
E Create Connection Cancel command. And since we keep trying until the conn=
ection timeout hits, this is not an error at this point.
we might should have the LE Create Connection scan with a full duty
cycle here. So it does not miss any advertising PDUs.
Is this something the Linux Bluetooth team is going to address?
I think this alone might fix the issue you're seeing. Could you please
try the patch I just sent and see if it solves the issue for you:
Bluetooth: Use continuous scanning when creating LE connections
Johan
Thanks both of you for your input.
Here are my 100% reproducible steps:
- Restart bluetoothd to start fresh
- Remove cached device (remove 88:0F:10:9D:EB:42)
- Run basic scan (scan on)
- Wait for the device to pop up in results and stop scan (scan off)
- Try to connect to it (connect 88:0F:10:9D:EB:42)
As you can read below I now have 2 "LE Connection Complete (0x01)" events.
Bluetooth monitor ver 5.35
= New Index: A4:17:31:78:A6:04 (BR/EDR,USB,hci0)
[hci0] 0.624321
< HCI Command: LE Add Device To White List (0x08|0x0011) plen 7
[hci0] 11.038826
Address type: Public (0x00)
Address: 88:0F:10:9D:EB:42 (OUI 88-0F-10)
LE Add Device To White List (0x08|0x0011) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Scan Parameters (0x08|0x000b) plen 7
[hci0] 11.040125
Type: Passive (0x00)
Interval: 60.000 msec (0x0060)
Window: 30.000 msec (0x0030)
Own address type: Public (0x00)
Filter policy: Ignore not in white list (0x01)
we might should have the LE Create Connection scan with a full duty cycle here. So it does not miss any advertising PDUs.
Is this something the Linux Bluetooth team is going to address?
yes we are addressing this. Also the mgmt event with the connection failed error needs to be suppressed. While a connection attempt might still be aborted, it is not an error. It is really just lets scan one more time and try again.
quoted
quoted
Filter policy: White list is not used (0x00)
Peer address type: Public (0x00)
Peer address: 88:0F:10:9D:EB:42 (OUI 88-0F-10)
Own address type: Public (0x00)
Min connection interval: 50.00 msec (0x0028)
Max connection interval: 70.00 msec (0x0038)
Connection latency: 0x0000
Supervision timeout: 420 msec (0x002a)
Min connection length: 0.000 msec (0x0000)
Max connection length: 0.000 msec (0x0000)
quoted
HCI Event: Command Status (0x0f) plen 4 [hci0] 15.670065
And I think we need to increase the timeout to something like 4-5 seconds before we give up and try the next device that might have been found.
For my own curiosity, how does does perform Android Bluetooth stack
when creating a LE connection?
Does it hardcode a 4-5 seconds timeout or does it use other heuristics?
I honestly do not know what Android picks as default values. Easy to find out though, just enable tracing and grab the btsnoop file via adb. You can read it with btmon btw.
Regards
Marcel
we might should have the LE Create Connection scan with a full duty
cycle here. So it does not miss any advertising PDUs.
Is this something the Linux Bluetooth team is going to address?
I think this alone might fix the issue you're seeing. Could you please
try the patch I just sent and see if it solves the issue for you:
Bluetooth: Use continuous scanning when creating LE connections
I ended up with the same problem using the 4.3 kernel.
The patch seems to solve the issue, and could perhaps be submitted to
-stable.
I gave it a few tries trying to connect to a Parrot Flower Power, and
got into a situation that may indicate a possible race condition:
(this line: '< HCI Command: LE Create Connection Cancel... ')
< HCI Command: LE Set Scan Parameters (0x08|0x000b) plen 7 =
[hci0] 20.602345
Type: Passive (0x00)
Interval: 60.000 msec (0x0060)
Window: 30.000 msec (0x0030)
Own address type: Public (0x00)
Filter policy: Ignore not in white list (0x01)
HCI Event: Command Complete (0x0e) plen 4 =
[hci0] 20.603330
LE Set Scan Parameters (0x08|0x000b) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2 =
[hci0] 20.603348
Scanning: Enabled (0x01)
Filter duplicates: Enabled (0x01)
HCI Event: Command Complete (0x0e) plen 4 =
[hci0] 20.604339
LE Set Scan Enable (0x08|0x000c) ncmd 1
Status: Success (0x00)
HCI Event: LE Meta Event (0x3e) plen 36 =
[hci0] 21.508266
LE Advertising Report (0x02)
Num reports: 1
Event type: Connectable undirected - ADV_IND (0x00)
Address type: Public (0x00)
Address: A0:14:3D:08:B5:36 (PARROT SA)
Data length: 24
Flags: 0x06
LE General Discoverable Mode
BR/EDR Not Supported
128-bit Service UUIDs (partial): 1 entry
39e1fa00-84a8-11e2-afba-0002a5d5c51b
RSSI: -59 dBm (0xc5)
< HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2 =
[hci0] 21.508332
Scanning: Disabled (0x00)
Filter duplicates: Disabled (0x00)
HCI Event: Command Complete (0x0e) plen 4 =
[hci0] 21.510342
LE Set Scan Enable (0x08|0x000c) ncmd 1
Status: Success (0x00)
< HCI Command: LE Create Connection (0x08|0x000d) plen 25 =
[hci0] 21.510396
Scan interval: 60.000 msec (0x0060)
Scan window: 60.000 msec (0x0060)
Filter policy: White list is not used (0x00)
Peer address type: Public (0x00)
Peer address: A0:14:3D:08:B5:36 (PARROT SA)
Own address type: Public (0x00)
Min connection interval: 50.00 msec (0x0028)
Max connection interval: 70.00 msec (0x0038)
Connection latency: 0x0000
Supervision timeout: 420 msec (0x002a)
Min connection length: 0.000 msec (0x0000)
Max connection length: 0.000 msec (0x0000)
we might should have the LE Create Connection scan with a full duty
cycle here. So it does not miss any advertising PDUs.
Is this something the Linux Bluetooth team is going to address?
I think this alone might fix the issue you're seeing. Could you please
try the patch I just sent and see if it solves the issue for you:
Bluetooth: Use continuous scanning when creating LE connections
I ended up with the same problem using the 4.3 kernel.
The patch seems to solve the issue, and could perhaps be submitted to
-stable.
I gave it a few tries trying to connect to a Parrot Flower Power, and
got into a situation that may indicate a possible race condition:
(this line: '< HCI Command: LE Create Connection Cancel... ')
< HCI Command: LE Set Scan Parameters (0x08|0x000b) plen 7 [hci0] 20.602345
Type: Passive (0x00)
Interval: 60.000 msec (0x0060)
Window: 30.000 msec (0x0030)
Own address type: Public (0x00)
Filter policy: Ignore not in white list (0x01)
I assume you means this one. The LE Connection Complete event arrives before the LE Create Connection Cancel actually completes.
Actually I do not think this is a race condition, it is just something with the nature on how LE connection are established (remember there is no CONN_RSP, just a CONN_REQ). It is just to catch this one since I think we need to be able to handle this one correctly.
If I remember the specification correctly, then you can only cancel a LE Create Connection that has not yet received its first data packet. Once the first data packet has arrived, then the connection has been established. Meaning the cancel operation either cancels the scanning or has to wait for the timeout of CONN_REQ. If you actually get a data packet, then it can not do anything anymore. Hence we have the Command Disallowed error here. Now only sending Disconnect will work.
It would be great if we have l2cap-tester or mgmt-tester test cases that simulate this behavior and also the other one where the LE Create Connection requires more than 2 seconds. Ensuring that we handle these correctly is important.
< HCI Command: LE Read Remote Used Features (0x08|0x0016) plen 2 [hci0] 23.519347
Handle: 64
quoted
HCI Event: Command Status (0x0f) plen 4 [hci0] 23.520302
LE Read Remote Used Features (0x08|0x0016) ncmd 1
Status: Success (0x00)
quoted
HCI Event: LE Meta Event (0x3e) plen 12 [hci0] 23.632256
LE Read Remote Used Features (0x04)
Status: Success (0x00)
Handle: 64
Features: 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00
LE Encryption
< ACL Data TX: Handle 64 flags 0x00 dlen 11 [hci0] 23.632361
SMP: Pairing Request (0x01) len 6
IO capability: NoInputNoOutput (0x03)
OOB data: Authentication data not present (0x00)
Authentication requirement: Bonding, No MITM, SC, No Keypresses (0x09)
Max encryption key size: 16
Initiator key distribution: EncKey Sign LinkKey (0x0d)
Responder key distribution: EncKey IdKey Sign LinkKey (0x0f)
This one still needs to be fixed. It is a bug. The implementation is
too naive. The unknown connection identifier is actually the success
case for LE Create Connection Cancel command. And since we keep trying
until the connection timeout hits, this is not an error at this point.
I think we need to differentiate between explicit connection requests
(L2CAP socket connect()) and Add Device based connections. For the
former we probably do want the Connect Failed since that's consistent
with the behavior you see when operating the L2CAP socket. For the
latter where we just go back to trying again, so the event doesn't
really describe what's going on.
Johan
This one still needs to be fixed. It is a bug. The implementation is
too naive. The unknown connection identifier is actually the success
case for LE Create Connection Cancel command. And since we keep trying
until the connection timeout hits, this is not an error at this point.
I think we need to differentiate between explicit connection requests
(L2CAP socket connect()) and Add Device based connections. For the
former we probably do want the Connect Failed since that's consistent
with the behavior you see when operating the L2CAP socket. For the
latter where we just go back to trying again, so the event doesn't
really describe what's going on.
are you sure about that. I think we need to define when we want the mgmt connect failed event to show up. Does it make sense that it shows up for connection attempts that are not initiated by mgmt?
I mean, what is the benefit of a connection failed event if you can not tell that something actually tried to connect in the first. So if you try to connect via L2CAP, we are just getting a failure and do not know what triggered it. How is that helpful?
Regards
Marcel
This one still needs to be fixed. It is a bug. The implementation is
too naive. The unknown connection identifier is actually the success
case for LE Create Connection Cancel command. And since we keep trying
until the connection timeout hits, this is not an error at this point.
I think we need to differentiate between explicit connection requests
(L2CAP socket connect()) and Add Device based connections. For the
former we probably do want the Connect Failed since that's consistent
with the behavior you see when operating the L2CAP socket. For the
latter where we just go back to trying again, so the event doesn't
really describe what's going on.
are you sure about that. I think we need to define when we want the
mgmt connect failed event to show up. Does it make sense that it shows
up for connection attempts that are not initiated by mgmt?
I mean, what is the benefit of a connection failed event if you can
not tell that something actually tried to connect in the first. So if
you try to connect via L2CAP, we are just getting a failure and do not
know what triggered it. How is that helpful?
I could think of at least one case: a device uses security mode 3 and we
connect to it via L2CAP. This triggers a PIN Code Request event, however
before we answer it the remote side cancels the connection/pairing
triggering a connect complete with failure status. In this case
bluetoothd should notify the agent to stop requesting for the PIN. Quite
a far stretched scenario (and I might even be wrong about it) but I
wouldn't be so quick to dismiss this event for non-mgmt actions.
Johan
This one still needs to be fixed. It is a bug. The implementation is
too naive. The unknown connection identifier is actually the success
case for LE Create Connection Cancel command. And since we keep trying
until the connection timeout hits, this is not an error at this point.
I think we need to differentiate between explicit connection requests
(L2CAP socket connect()) and Add Device based connections. For the
former we probably do want the Connect Failed since that's consistent
with the behavior you see when operating the L2CAP socket. For the
latter where we just go back to trying again, so the event doesn't
really describe what's going on.
are you sure about that. I think we need to define when we want the
mgmt connect failed event to show up. Does it make sense that it shows
up for connection attempts that are not initiated by mgmt?
I mean, what is the benefit of a connection failed event if you can
not tell that something actually tried to connect in the first. So if
you try to connect via L2CAP, we are just getting a failure and do not
know what triggered it. How is that helpful?
I could think of at least one case: a device uses security mode 3 and we
connect to it via L2CAP. This triggers a PIN Code Request event, however
before we answer it the remote side cancels the connection/pairing
triggering a connect complete with failure status. In this case
bluetoothd should notify the agent to stop requesting for the PIN. Quite
a far stretched scenario (and I might even be wrong about it) but I
wouldn't be so quick to dismiss this event for non-mgmt actions.
actually I agree, everything involved with mgmt and pairing should cause this error. However has that really anything to do with L2CAP? It is more like we only send it if something happens on HCI side of things that are no related to any higher layers.
Btw. I am fine with applying your initial patch with the updated comment. It is improving the situation no matter what, but we might want to double check if not sending this event with nobody being able to react on it.
Regards
Marcel