Bluetooth: controller: Fix assert on peer unknown rsp
Fixed an assert when peer responded with unknown rsp to slave feature request when an existing another control procedure was in progress. This assert happened with a BT v4.0 peer implementation that was performing a channel map update and local controller initiated a slave feature request, receiving an unknown response. Signed-off-by: Vinayak Kariappa Chettimada <vich@nordicsemi.no>
This commit is contained in:
parent
fa5f231e4d
commit
f43e4e0637
1 changed files with 1 additions and 10 deletions
|
@ -2794,16 +2794,7 @@ isr_rx_conn_pkt_ctrl(struct radio_pdu_node_rx *radio_pdu_node_rx,
|
|||
#endif /* CONFIG_BT_CTLR_LE_PING */
|
||||
|
||||
case PDU_DATA_LLCTRL_TYPE_UNKNOWN_RSP:
|
||||
if (_radio.conn_curr->llcp_req != _radio.conn_curr->llcp_ack) {
|
||||
/* reset ctrl procedure */
|
||||
_radio.conn_curr->llcp_ack = _radio.conn_curr->llcp_req;
|
||||
|
||||
switch (_radio.conn_curr->llcp_type) {
|
||||
default:
|
||||
LL_ASSERT(0);
|
||||
break;
|
||||
}
|
||||
|
||||
if (0) {
|
||||
#if defined(CONFIG_BT_CTLR_DATA_LENGTH)
|
||||
} else if (_radio.conn_curr->llcp_length.req !=
|
||||
_radio.conn_curr->llcp_length.ack) {
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue