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:
parent
51e3cecb31
commit
b53657a058
1 changed files with 1 additions and 1 deletions
|
@ -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 */
|
||||||
|
|
Loading…
Add table
Add a link
Reference in a new issue