接收蓝牙广告数据包的时间超过规格最大值

Posted 2023-03-05

【中文标题】接收蓝牙广告数据包的时间超过规格最大值

【英文标题】：Receiving Bluetooth Advertisement packets longer than specification max

【发布时间】：2017-12-01 20:53:22

【问题描述】：

我正在运行一个 android 应用程序（自定义）来扫描附近的蓝牙低功耗设备，我注意到某些设备的广告数据包比规范规定的要长。扫描设备是运行 Android 6.0 的 Nexus 5。

我在 ScanResult 对象 result.getScanRecord().getBytes(); 上使用以下行来获取字节数组

我知道 ScanRecord 的字节数组实际上是由广告数据（不包括 mac 地址）和扫描响应构成的，所以我预计每个 31 个字节，总共 62 个字节。这是我收到的总数组的大小，但看起来广告数据使其进入数组的响应部分。格式遵循规范，其中 GAP 的第一个字节是长度，下一个字节是 GAP 类型，下一个 length-1 字节是数据。

但是使用这种格式，相关设备的数据字段会延伸到响应部分。这是十六进制数组的示例，每个 GAP 位于不同的行：

02 01 06  (flags)
0D FF DF 00 57 30 46 30 30 33 43 45 56 5A (manufacturer specific data)
11 07 6D 69 73 66 69 74 A6 34 4A 7D 7F 95 01(<-expected end of advertise) 00 DA 3D (UUID, 128-bit)
07 09 46 6F 73 73 69 6C   (device name)
03 03 12 18   (UUID, 16-bit)
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 (leftover bytes)

我并不真正关心扫描响应数据，但我很困惑如果 BLE 设备符合 4.2 规范，它如何发送大于 31 字节的广告数据包（我知道蓝牙 5 允许更大的数据包，但是制造商声明它使用 4.2)。我还可以看到设备的名称按应有的方式显示，但在响应部分。

有人知道为什么会出现这种情况吗？谢谢。

【参考方案1】：

可能这些设备根本不遵循规范（要求条目不跨越数据包边界）。所以你的设备可能会发送

02 01 06 0D FF DF 00 57 30 46 30 30 33 43 45 56 5A 11 07 6D 69 73 66 69 74 A6 34 4A 7D 7F 95

作为广告数据和

01 00 DA 3D 07 09 46 6F 73 73 69 6C 03 03 12 18

作为扫描响应数据。例如，您可以在 HCI 日志中查看这是否正确。如果是这样，您应该向该 BLE 设备的制造商投诉。

【讨论】：

我可以看到可能是这种情况，但是响应的第一部分具有实际上不存在的 GAP 类型，然后以下 GAP 的长度将远高于本规范中通告的数据包的最大大小。 HCI 日志应该在扫描设备上，对吗？我应该看看那个