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:
parent
6e2501dd25
commit
5f2099fb63
2 changed files with 14 additions and 0 deletions
|
@ -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) &&
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue