Bluetooth: Host: Fix handling of adv reports when scanning for connection

[zhongzhijie1]

bug: v/78367

In some cases, the host starts scanning internally for establishing
connections (BT_LE_SCAN_USER_CONN), such as host-based resolving or
auto-connection. In this situation, even if the application does not
start explicit scan, the host still needs to handle the advertising
reports to continue the connection process.

Previously, both bt_hci_le_adv_report() and bt_hci_le_adv_ext_report()
will break or discard all reports when explicit scan is not active.
This causes the connection to stay in SCAN_BEFORE_INITIATING and never
move forward.

This patch adds checking of BT_LE_SCAN_USER_CONN to allow advertising
reports to be processed during connection-purpose scanning. When the
scan is started explicitly by application, the behavior remains the
same, only small comments are updated to describe this behavior and keep
the original code style unchanged.

This PR is cherry-pick from
zephyrproject-rtos/zephyr#98411
zephyrproject-rtos/zephyr#98859

[chengkai15]

line 679 would not report scan_dev_found_cb when le_adv_recv, and when would it report?

[zhongzhijie1]

when it is start by user app, 'explicit_scan' is true.

[chengkai15]

will it discrad all conn_scan adv when BT_LE_SCAN_USER_CONN was actived?

[zhongzhijie1]

BT_LE_SCAN_USER_CONN is only trigger by host rpa re-connect. not by user le scan

[zhongzhijie1]

🧩 Change Background

When calling:

int bt_conn_le_create(const bt_addr_le_t *peer,
const struct bt_conn_le_create_param *create_param,
const struct bt_le_conn_param *conn_param,
struct bt_conn **ret_conn)
Normally, a BLE connection will go through:

bt_conn_set_state(conn, BT_CONN_INITIATING);

err = bt_le_create_conn(conn);
if (err) {
conn->err = 0;
bt_conn_set_state(conn, BT_CONN_DISCONNECTED);
bt_conn_unref(conn);

/* Best-effort attempt to inform the scanner that the initiator stopped. */
int scan_check_err = bt_le_scan_user_add(BT_LE_SCAN_USER_NONE);

if (scan_check_err) {
	LOG_WRN("Error while updating the scanner (%d)", scan_check_err);
}
return err;

}
⚠️ Problem Case

After pairing and distributing IRK,
if the controller resolving list size = 0,
the next connection will follow the “host-based resolving” path:

if (bt_dev.le.rl_entries > bt_dev.le.rl_size) {
/* Use host-based identity resolving. */
bt_conn_set_state(conn, BT_CONN_SCAN_BEFORE_INITIATING);

err = bt_le_scan_user_add(BT_LE_SCAN_USER_CONN);
if (err) {
	bt_le_scan_user_remove(BT_LE_SCAN_USER_CONN);
	bt_conn_set_state(conn, BT_CONN_DISCONNECTED);
	bt_conn_unref(conn);

	return err;
}

*ret_conn = conn;
return 0;

}
This means the Host will start a scan automatically and mark it with flag:

BT_LE_SCAN_USER_CONN

However, in le_adv_recv(), if the scan is not started by user (not BT_LE_SCAN_USER_EXPLICIT_SCAN),
the advertising report is ignored:

if (!atomic_test_bit(scan_state.scan_flags, BT_LE_SCAN_USER_EXPLICIT_SCAN)) {
/* skip this adv report */
return;
}

As a result, the connection logic below can never be triggered:

conn = bt_conn_lookup_state_le(BT_ID_DEFAULT, id_addr,
BT_CONN_SCAN_BEFORE_INITIATING);
if (!conn) {
return;
}

err = bt_le_scan_user_remove(BT_LE_SCAN_USER_CONN);
bt_addr_le_copy(&conn->le.resp_addr, addr);
bt_le_create_conn(conn);
I found this issue when testing with a PTS dongle.
Because the dongle controller has a resolving list size of 0,
the host entered the host-based resolving path and triggered this bug logic.

The bad effect is that the host keeps scanning forever but never establishes the LE connection.

[huangyulong3]

LGTM.

[huangyulong3]

LGTM.