Bluetooth LE active scanning causes connection problems on other machine - bluetooth

Question

I am having a problem where BLE active scanning on one machine causes connection problems on another machine. I was wounder if anyone could explain why, and offer any suggestions on how to fix.
I have broken down a rough version of my what my code does into simple scripts.
on machine 1:
sudo stdbuf -oL hcidump -X |tee hci.log &
sudo hcitool lewlclr
sudo hcitool lewladd 68:C9:0B:xx:xx:01
sudo hcitool lewladd 68:C9:0B:xx:xx:02
sudo hcitool lewladd 68:C9:0B:xx:xx:03
sudo hcitool lewladd 68:C9:0B:xx:xx:04
sudo hcitool lewladd 68:C9:0B:xx:xx:05
sudo hcitool lewladd 68:C9:0B:xx:xx:06
while true; do sudo hcitool lecc --whitelist; if [ $? == 1 ] ; then sleep 20; else sleep 1; sudo hcitool ledc 64 ; fi; done
The above will run with no problems
However after running the following on a different machine I get connection issues.
sudo hcitool lescan --duplicates
from the hci logs a normal connecition looks like:
< HCI Command: LE Create Connection (0x08|0x000d) plen 25
bdaddr 00:00:00:00:00:00 type 0
interval 4 window 4 initiator_filter 1
own_bdaddr_type 0 min_interval 15 max_interval 15
latency 0 supervision_to 3200 min_ce 1 max_ce 1
> HCI Event: Command Status (0x0f) plen 4
LE Create Connection (0x08|0x000d) status 0x00 ncmd 1
> HCI Event: LE Meta Event (0x3e) plen 19
LE Connection Complete
status 0x00 handle 64, role master
bdaddr 68:C9:0B:xx:xx:xx (Public)
< HCI Command: Disconnect (0x01|0x0006) plen 3
handle 64 reason 0x13
Reason: Remote User Terminated Connection
> HCI Event: Command Status (0x0f) plen 4
Disconnect (0x01|0x0006) status 0x00 ncmd 1
> HCI Event: Disconn Complete (0x05) plen 4
status 0x00 handle 64 reason 0x16
Reason: Connection Terminated by Local Host
and a bad connection is as follows:
< HCI Command: LE Create Connection (0x08|0x000d) plen 25
bdaddr 00:00:00:00:00:00 type 0
interval 4 window 4 initiator_filter 1
own_bdaddr_type 0 min_interval 15 max_interval 15
latency 0 supervision_to 3200 min_ce 1 max_ce 1
> HCI Event: Command Status (0x0f) plen 4
LE Create Connection (0x08|0x000d) status 0x00 ncmd 1
> HCI Event: LE Meta Event (0x3e) plen 19
LE Connection Complete
status 0x00 handle 64, role master
bdaddr 68:C9:0B:xx:xx:xx (Public)
> HCI Event: Disconn Complete (0x05) plen 4
status 0x00 handle 64 reason 0x3e
Reason: Connection Failed to be Established
< HCI Command: Disconnect (0x01|0x0006) plen 3
handle 64 reason 0x13
Reason: Remote User Terminated Connection
> HCI Event: Command Status (0x0f) plen 4
Disconnect (0x01|0x0006) status 0x12 ncmd 1
Error: Invalid HCI Command Parameters
Note: the last two entries (Invalid HCI Command Parameters) are because of the crudeness of the script, and only occur because of the failed connection.
Of note, it looks like the connection is made, then it says in couldn't (Connection Failed to be Established). This seems a bit confusing to me.
I have tried this on different machines. (desktop PC and RPi3)

Answer 1

Peripheral is advertising. That means it periodically sends an avertisement (ADV_IND) packet on some advertisement channel. In response to this packet, a central may either (Core_v4.2, 6.B.4.4.2.3):
do nothing,
send a scan request (SCAN_REQ) packet (Figure 4.3), peripheral should respond with a scan response (SCAN_RSP),
send a connection request (CONN_REQ) packet (Figure 4.5).
Here, you have two centrals trying to reach the same peripheral at the same time. One is doing active scanning (#2 above), the other is initiating (#3 above). Unfortunately, both must send their packet at the exact same time, receiver gets jammed, and both scan request and connection request packets get lost.
There is no acknowledgement for connection requests. Initiator must to assume the advertiser received and accepted the connection request, create the connection speculatively, and possibly time out afterwards. That's why the fast termination feature pointed by bare_metal exists. In case the peripheral does not take the connection request, central should not wait forever.
LE Connection Complete event in your dumps just tell a Connection Request packet got sent, it does not tell it actually got received, processed or accepted by target.

Answer 2

on the confusion of connection created vs connection established please see the vol 6, Part B,section 4.5 from low energy specification (core 4.2). so it seems in the second instance the remote device didn't send any
data channel packet after CONNECT_REQ PDU. and in the second case if a disconnect is tried on a link which is not established , the controller will complain about invalid handle ( as there is no valid connection exist). To debug further you could enable Timing in hcidump which will confirm the failed to establish event is received by the host after Supervision Timeout.
"The Link Layer enters the Connection State when an initiator sends a
CONNECT_REQ PDU to an advertiser or an advertiser receives a
CONNECT_REQ PDU from an initiator.
After entering the Connection State, the connection is considered to be
created. The connection is not considered to be established at this point. A connection is only considered to be established once a data channel packet
has been received from the peer device. The only difference between A connection that is created and a connection that is established is the Link Layer connection supervision timeout value that is used"
"If the Link Layer connection supervision timer reaches 6 * connInterval before the connection is established (see Section 4.5), the connection shall be considered lost. This enables fast termination of connections that fail to establish"