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 <[email protected]>
zephyrproject-rtos · Sep 7, 2017 · f43e4e0 · f43e4e0
1 parent fa5f231
commit f43e4e0
Showing 1 changed file with 1 addition and 10 deletions.
diff --git a/subsys/bluetooth/controller/ll_sw/ctrl.c b/subsys/bluetooth/controller/ll_sw/ctrl.c
@@ -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) {