我正在使用 Windows 蓝牙 LE GATT 库连接并配对支持 BLE 的设备 D。由于 D 的存储空间有限,如果与它绑定的 N 个以上的客户端,那么它将删除第一个长期密钥在绑定期间创建的对。
假设删除此密钥对的设备是启用 Windows 的机器。我们称它为 W。下次 W 尝试与 D 连接时,当它接收到来自 W 的 LTK_Request_Event 时,它以 Long_Term_Key_Requested_Negative_Reply 响应,W 终止连接。
但这就是事情变得真正令人恼火的地方。尽管 Windows BLE 堆栈似乎知道此响应(因为它断开连接),但这似乎并没有被下游传送到使用蓝牙 LE GATT 库的应用程序。实际上,从应用程序的角度来看,配对请求将返回“已配对”,并不表示出现任何问题。当然,一旦应用程序尝试访问受保护的特征,它就无法访问,而且到目前为止,这是配对不成功的唯一迹象。更糟糕的是,它收到的错误并不一致。有时,它会“无法访问”。有时,它会出现协议错误。其他时候,它会收到 ABORT。
现在,作为一种启发式方法,我可以使用对这种情况的检测作为尝试重新配对的标准。不幸的是,这并不理想,因为这些错误实际上并不意味着设备不再支持 LTK,而是可能指示其他问题,例如设备超出范围。
有什么方法可以检测到现有的 LTK 已被设备拒绝?