Bluetooth: controller: Workaround for Unknown Rsp during Enc Setup

Some old peer central controllers respond with Unknown
Response PDU to our local Slave Initiated Feature Request
after the peer initiated the Encryption Setup Procedure.

The peer has voilated the Bluetooth Specification by sending
the Unknown Response during the Encryption Setup Procedure,
but as a workaround to IOP with such controller our local
implementation is updated to not disconnect the connection
but accept the voilating Unknown Response PDU.

Relates to #12362.

Signed-off-by: Vinayak Kariappa Chettimada <vich@nordicsemi.no>
This commit is contained in:
Vinayak Kariappa Chettimada 2019-03-01 16:02:45 +05:30 committed by Carles Cufí
commit 5f2099fb63
2 changed files with 14 additions and 0 deletions

View file

@ -3422,6 +3422,13 @@ static inline bool isr_rx_conn_enc_unexpected(struct connection *conn,
(opcode != PDU_DATA_LLCTRL_TYPE_REJECT_EXT_IND)))) ||
(conn->role &&
((!conn->refresh &&
/* As a workaround to IOP with some old peer controllers that
* respond with Unknown Rsp PDU to our local Slave Initiated
* Feature request during Encryption Setup initiated by the
* peer, we accept this Unknown Rsp PDU during the Encryption
* setup procedure in progress.
*/
(opcode != PDU_DATA_LLCTRL_TYPE_UNKNOWN_RSP) &&
(opcode != PDU_DATA_LLCTRL_TYPE_TERMINATE_IND) &&
(opcode != PDU_DATA_LLCTRL_TYPE_START_ENC_RSP) &&
(opcode != PDU_DATA_LLCTRL_TYPE_REJECT_IND) &&