什么会导致从机在 BLE 加密过程中不发送 LL_START_ENC_RSP？
What could cause the slave not to send LL_START_ENC_RSP during BLE encryption procedure ?
在BLE连接的加密过程中，master和slave进行3次握手来验证加密。我面临这样一种情况，从站不发送此握手的最后一部分，即消息 LL_START_ENC_RSP，在以下握手示意图中显示为红色：
发生这种情况是否有特定原因？我所说的指定是指一个不特定于实现的原因。
BLE 核心规范 4.2 说明了这一点：
When the Link Layer of the slave receives an LL_START_ENC_RSP PDU it
shall transmit an LL_START_ENC_RSP PDU. This packet shall be sent
encrypted.
但这并没有说明从机不发送这个数据包的任何条件。
此时slave会不会认为它拥有与当前Master关联的Long Term Key（因为如果不是这样slave就不会开始3次握手，对吧？），但其 LTK 不正确且解密失败？如果它发生了，会不会有断开连接消息，而不是什么都没有？
由于我是 BLE 的新手，所以我不知道如何分析或解释这个问题，所以任何帮助将不胜感激。在 BLE 嗅探器的帮助下观察了消息的存在和不存在。
注意：图 1 是 Robin Heydon 的书的图 7-26 的复制：Bluetooth Low Energy The Developer's handbook。
根据规范，第三条消息总是要发送的。如果没有发送，说明执行有bug。
如果slave有错误的LTK，slave将不会接受master的LL_START_ENC_RSP。如果发生这种情况，link 将在监督超时后被丢弃，因为从站永远不会确认该数据包。
请注意，为了让嗅探器成功解密数据包，它需要知道 LTK。如果嗅探器在配对过程中运行，Nordic 的嗅探器程序将捕获 LTK。
在BLE连接的加密过程中，master和slave进行3次握手来验证加密。我面临这样一种情况，从站不发送此握手的最后一部分，即消息 LL_START_ENC_RSP，在以下握手示意图中显示为红色：
发生这种情况是否有特定原因？我所说的指定是指一个不特定于实现的原因。
BLE 核心规范 4.2 说明了这一点：
When the Link Layer of the slave receives an LL_START_ENC_RSP PDU it shall transmit an LL_START_ENC_RSP PDU. This packet shall be sent encrypted.
但这并没有说明从机不发送这个数据包的任何条件。
此时slave会不会认为它拥有与当前Master关联的Long Term Key（因为如果不是这样slave就不会开始3次握手，对吧？），但其 LTK 不正确且解密失败？如果它发生了，会不会有断开连接消息，而不是什么都没有？
由于我是 BLE 的新手，所以我不知道如何分析或解释这个问题，所以任何帮助将不胜感激。在 BLE 嗅探器的帮助下观察了消息的存在和不存在。
注意：图 1 是 Robin Heydon 的书的图 7-26 的复制：Bluetooth Low Energy The Developer's handbook。
根据规范，第三条消息总是要发送的。如果没有发送，说明执行有bug。
如果slave有错误的LTK，slave将不会接受master的LL_START_ENC_RSP。如果发生这种情况，link 将在监督超时后被丢弃，因为从站永远不会确认该数据包。
请注意，为了让嗅探器成功解密数据包，它需要知道 LTK。如果嗅探器在配对过程中运行，Nordic 的嗅探器程序将捕获 LTK。