Bluetooth: Host: Extended advertising reports may block the host

[Thalley]

Is your enhancement proposal related to a problem? Please describe.
In the case that we are doing scanning in a very busy environment (e.g. hundreds of extended advertising reports per second), then the host will receive so many events that it may effectively block the host from working, if it receives more reports than it can handle. Many reports may cause the events to be queued, and thus calling an HCI command (e.g. bt_le_scan_stop()) will timeout waiting for the return event.

This is only an issue for extended advertising reports (BT_HCI_EVT_LE_EXT_ADVERTISING_REPORT) as legacy reports (BT_HCI_EVT_LE_ADVERTISING_REPORT) are usually marked as discardable, e.g. by

		if (rx.evt.evt == BT_HCI_EVT_LE_META_EVENT &&
		    (rx.hdr[sizeof(*hdr)] == BT_HCI_EVT_LE_ADVERTISING_REPORT)) {
			BT_DBG("Marking adv report as discardable");
			rx.discardable = true;
		}

Due to the reassembly requirements of extended advertising, we cannot just discard all extended reports (we could potentially discard reports with the status BT_HCI_LE_ADV_EVT_TYPE_DATA_STATUS_COMPLETE). We could only discard the ones marked as legacy or complete. This is because if we did, the reassembler would run out of sync.

This is basically a performance issue, and thus not marked as a bug.

Describe the solution you'd like
Ideally we'd find some way of discard extended advertising reports, so that we can just discard them and keep the number of events queued small, thus eliminating the issue with HCI command events.

Describe alternatives you've considered
A small work around is discard all advertising reports once bt_le_scan_set_enable(BT_HCI_LE_SCAN_DISABLE); has been called. It is safe to assume that the upper layers do not care about any queued reports once this has been called, and that may help to clear the queued reports.

Additional context
This was found doing UPF and was happening often as extended advertising was used extensively. The issue appeared using the nRF5340.

[Thalley]

@rugeGerritsen This is the host issued I mentioned at the UPF when receiving many scan reports.

[rugeGerritsen]

@Thalley, thanks for creating this issue. Unfortunately, I think there is no way we can know what extended advertising reports we can discard, and that is also true for reports with data status set to BT_HCI_LE_ADV_EVT_TYPE_DATA_STATUS_COMPLETE. The problem is that we don't know if such a report is both first and last or only last.

Example: We receive advertising reports from one advertiser. It generates three sets of reports, A, B, and C. Each of the sets contain three partial reports (A1, A2, A3, B1, ...).

Let's now say that we receive them all in order. In that case A3, B3 and C3 will have its data status set to BT_HCI_LE_ADV_EVT_TYPE_DATA_STATUS_COMPLETE.

Discarding A3 will result in invalid reassembly as it will concatenate A and B.

I believe that this is an issue in the spec. It restricts the architecture of the system to have a host that polls for events rather than a controller pushing events. This is especially an issue for systems where the controller and host are not running on the same core or device.

[hermabe]

If we discard any An we must discard all previously reassembled reports from A (A1, ... , A(n-1)) and keep discarding until we get a report from A with data_status==complete. However, to do this we sort of have to do the reassembly anyway. The current implementation should not reassemble reports from different advertisers, but we will run into this warning, and future reports will be incomplete.

[alwa-nordic]

This is basically a performance issue, and thus not marked as a bug.

I think we can upgrade this to a bug because it sounds quite serious. The trigger is external (other devices advertising a lot) and it results in a unresponsive device.

[Thalley]

This is basically a performance issue, and thus not marked as a bug.

I think we can upgrade this to a bug because it sounds quite serious. The trigger is external (other devices advertising a lot) and it results in a unresponsive device.

That is a good point. Basically it allows other devices to DoS the Zephyr host.