Bluetooth: Controller: hci: Wrong opcode when handling CTE req failed

HCI_LE_CTE_Request_Failed may be generated in case received LL_CTE_RSP
PDU didn't contain CTE or if peer rejected the request. HCI function
encode_data_ctrl responsible for dispatching received control PDUs
should not expect a PDU with PDU_DATA_LLCTRL_TYPE_CTE_REQ opcode.
It should never happen. The correct opcode here is PDU_DATA_LLCTRL_TYPE-
_CTE_RSP.

Result of this issue is an assert when LL_CTE_RSP PDU is received
but it does not include CTE.

The commit fixes the problem.

Signed-off-by: Piotr Pryga <piotr.pryga@nordicsemi.no>
This commit is contained in:
Piotr Pryga 2022-04-13 07:44:02 +02:00 committed by Marti Bolivar
commit b53657a058

View file

@ -7913,7 +7913,7 @@ static void encode_data_ctrl(struct node_rx_pdu *node_rx,
#endif /* CONFIG_BT_CTLR_DATA_LENGTH */ #endif /* CONFIG_BT_CTLR_DATA_LENGTH */
#if defined(CONFIG_BT_CTLR_DF_CONN_CTE_REQ) #if defined(CONFIG_BT_CTLR_DF_CONN_CTE_REQ)
case PDU_DATA_LLCTRL_TYPE_CTE_REQ: case PDU_DATA_LLCTRL_TYPE_CTE_RSP:
le_df_cte_req_failed(BT_HCI_CTE_REQ_STATUS_RSP_WITHOUT_CTE, handle, buf); le_df_cte_req_failed(BT_HCI_CTE_REQ_STATUS_RSP_WITHOUT_CTE, handle, buf);
break; break;
#endif /* CONFIG_BT_CTLR_DF_CONN_CTE_REQ */ #endif /* CONFIG_BT_CTLR_DF_CONN_CTE_REQ */