将 BlueZ 堆栈用作外围设备时的有效载荷错误
Wrong payload when using BlueZ stack as peripheral
我尝试按照 davidgyoung 在 this question 中提供的步骤进行操作。以下是我使用的命令：
hciconfig hci0 up
hciconfig hci0 noleadv
hcitool -i hci0 cmd 0x08 0x0008 48 45 4c 4c 4f 57 4f 52 4c 44
hciconfig hci0 leadv
这给了我这个输出：
LE set advertise enable on hci0 returned status 12
< HCI Command: ogf 0x08, ocf 0x0008, plen 10
48 45 4C 4C 4F 57 4F 52 4C 44
> HCI Event: 0x0e plen 4
01 08 20 12
请注意，我不能使用建议的命令 hciconfig hci0 leadv 0，因为它会抛出错误 Warning: unknown command - "0"。
然而，当我尝试从另一台设备读取（例如使用 hcidump --raw）广告包中的有效负载时，我得到如下输出：
hcitool lescan -- duplicates 输出片段（两个条目一遍又一遍地重复，但从 MAC 来看它应该是同一台设备）：
00:1A:7D:DA:71:14 mint17-0
00:1A:7D:DA:71:14 (unknown)
匹配 hcidump --raw 输出片段：
> 04 3E 16 02 01 04 00 14 71 DA 7D 1A 00 0A 09 09 6D 69 6E 74 31 37 2D 30 BE
> 04 3E 12 02 01 00 00 14 71 DA 7D 1A 00 06 02 01 02 02 0A 08 AD
我正在使用 Bluez 5.26 和 CSR4.0 加密狗。
这是广告商的 hciconfig 输出：
hci0: Type: BR/EDR Bus: USB
BD Address: 00:1A:7D:DA:71:14 ACL MTU: 310:10 SCO MTU: 64:8
UP RUNNING PSCAN ISCAN
RX bytes:1242 acl:0 sco:0 events:77 errors:0
TX bytes:2079 acl:0 sco:0 commands:77 errors:0
这是 'scanner' 的 hciconfig 输出：
hci0: Type: BR/EDR Bus: USB
BD Address: 00:1A:7D:DA:71:13 ACL MTU: 310:10 SCO MTU: 64:8
UP RUNNING PSCAN ISCAN
RX bytes:11753 acl:0 sco:0 events:552 errors:0
TX bytes:1842 acl:0 sco:0 commands:75 errors:0
我错过了什么让它工作？
更新：
按照 David 的建议，我将 cmd 值更改为
hcitool -i hci0 cmd 0x08 0x0008 10 02 01 1a 0c ff 18 01 48 45 4c 4c 4f 57 4f 52 4c 44
得到这个输出
< HCI Command: ogf 0x08, ocf 0x0008, plen 18
10 02 01 1A 0C FF 18 01 48 45 4C 4C 4F 57 4F 52 4C 44
> HCI Event: 0x0e plen 4
01 08 20 12
但有效载荷仍然是乱码（hcidump --raw 输出的有效载荷部分）
af:08:0a:02:02:01:02
b7:08:0a:02:02:01:02
be:08:0a:02:02:01:02
...
更新二：
按照下一条建议，我尝试向有效载荷中添加一些 00：
< HCI Command: ogf 0x08, ocf 0x0008, plen 42
10 02 01 1A 0C FF 18 01 48 45 4C 4C 4F 57 4F 52 4C 44 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00
> HCI Event: 0x0e plen 4
01 08 20 12
这里是 hcidump --raw output
> 04 3E 16 02 01 04 00 14 71 DA 7D 1A 00 0A 09 09 6D 69 6E 74
31 37 2D 30 BF
> 04 3E 12 02 01 00 00 14 71 DA 7D 1A 00 06 02 01 02 02 0A 08
AC
> 04 3E 12 02 01 00 00 14 71 DA 7D 1A 00 06 02 01 02 02 0A 08
BF
> 04 3E 16 02 01 04 00 14 71 DA 7D 1A 00 0A 09 09 6D 69 6E 74
31 37 2D 30 BF
> 04 3E 12 02 01 00 00 14 71 DA 7D 1A 00 06 02 01 02 02 0A 08
AD
所以还是不开心。
尝试不同的（也许是旧的）版本的 bluez 有意义吗？或者它可能与硬件相关，我应该尝试获得不同的蓝牙加密狗？
更新 3：
对适用于 David 的 bluez 5.21 进行了同样的尝试。
这是 hcidump --raw 输出的片段
> 04 3E 0C 02 01 04 00 14 71 DA 7D 1A 00 00 D7
> 04 3E 22 02 01 00 00 14 71 DA 7D 1A 00 16 02 01 0A 02 0A 08
0F 09 72 73 73 6D 74 2D 63 6C 69 65 6E 74 2D 30 D4
> 04 3E 0C 02 01 04 00 14 71 DA 7D 1A 00 00 D4
> 04 3E 22 02 01 00 00 14 71 DA 7D 1A 00 16 02 01 0A 02 0A 08
0F 09 72 73 73 6D 74 2D 63 6C 69 65 6E 74 2D 30 D2
主机名已更改（目前已在第三台机器上测试），因此输出有点不同，但我仍然没有在任何地方看到 'hello world'。
此时欢迎任何想法！
更新四：
尝试了不同的硬件加密狗（IOGEAR GBU521W6，正如 David 所建议的那样），现在看起来很有前途！
使用此广告配置时：
hcitool -i hci0 cmd 0x08 0x0008 10 02 01 1a 0c ff 18 01 48 45 4c 4c 4f 57 4f 52 4c 44
我得到这个 hcidump --raw 输出：
> 04 3E 1C 02 01 00 00 BA D0 63 70 F3 5C 10 02 01 1A 0C FF 18 01 48 45 4C 4C 4F 57 4F 52 4C B5
如您所见，有效负载几乎已完成，但缺少最后一个字符。通过将长度属性更改为 11，我得到了完整的有效负载：
hcitool -i hci0 cmd 0x08 0x0008 11 02 01 1a 0c ff 18 01 48 45 4c 4c 4f 57 4f 52 4c 44
----
> 04 3E 1D 02 01 00 00 BA D0 63 70 F3 5C 11 02 01 1A 0C FF 18 01 48 45 4C 4C 4F 57 4F 52 4C 44 AB
所以对于未来（和不同的有效载荷）：所需的长度似乎是有效载荷的字节数（没有长度属性）- 在这种情况下为 17。
重要提示： 它不适用于我的 bluez 5.26，我现在正在使用 bluez 5.21。
两期：
首先，为了让 BlueZ 进行通告，您提供的字节序列必须包含有效的 BLE 通告 header，最少为 8 个字节。所以要宣传 "helloworld" 你实际上需要发送：
sudo hcitool -i hci0 cmd 0x08 0x0008 10 02 01 1a 0c ff 18 01 48 45 4c 4c 4f 57 4f 52 4c 44
前 8 个字节是 header，接下来的 10 个字节是编码为 8 位 ASCII 的字符串 "helloworld"。
前8个字节可以这样分解：
10 # Total length of the advertising packet
02 # Number of bytes that follow in first AD structure
01 # Flags AD type
1A # Flags value 0x1A = 000011010
bit 0 (OFF) LE Limited Discoverable Mode
bit 1 (ON) LE General Discoverable Mode
bit 2 (OFF) BR/EDR Not Supported
bit 3 (ON) Simultaneous LE and BR/EDR to Same Device Capable (controller)
bit 4 (ON) Simultaneous LE and BR/EDR to Same Device Capable (Host)
0C # Number of bytes that follow in second (and last) AD structure
FF # Manufacturer specific data AD type
18 01 # Company identifier code (0x0118 == Radius Networks)
请注意，此 header 包含两个不同的长度字段，如果您更改 "helloworld" 有效负载的长度，则必须调整这两个字段。此外，出于实验目的，欢迎您使用任意两个字节作为您想要的公司标识符。
其次，您无法使用 hcitool lescan 命令查看检测到的广告的原始字节。 要查看原始字节，您必须使用此命令结合 hcidump 命令。详情请看这里：https://whosebug.com/a/21790504/1461050
我尝试按照 davidgyoung 在 this question 中提供的步骤进行操作。以下是我使用的命令：
hciconfig hci0 up
hciconfig hci0 noleadv
hcitool -i hci0 cmd 0x08 0x0008 48 45 4c 4c 4f 57 4f 52 4c 44
hciconfig hci0 leadv
这给了我这个输出：
LE set advertise enable on hci0 returned status 12
< HCI Command: ogf 0x08, ocf 0x0008, plen 10
48 45 4C 4C 4F 57 4F 52 4C 44
> HCI Event: 0x0e plen 4
01 08 20 12
请注意，我不能使用建议的命令 hciconfig hci0 leadv 0，因为它会抛出错误 Warning: unknown command - "0"。
然而，当我尝试从另一台设备读取（例如使用 hcidump --raw）广告包中的有效负载时，我得到如下输出：
hcitool lescan -- duplicates 输出片段（两个条目一遍又一遍地重复，但从 MAC 来看它应该是同一台设备）：
00:1A:7D:DA:71:14 mint17-0
00:1A:7D:DA:71:14 (unknown)
匹配 hcidump --raw 输出片段：
> 04 3E 16 02 01 04 00 14 71 DA 7D 1A 00 0A 09 09 6D 69 6E 74 31 37 2D 30 BE
> 04 3E 12 02 01 00 00 14 71 DA 7D 1A 00 06 02 01 02 02 0A 08 AD
我正在使用 Bluez 5.26 和 CSR4.0 加密狗。
这是广告商的 hciconfig 输出：
hci0: Type: BR/EDR Bus: USB
BD Address: 00:1A:7D:DA:71:14 ACL MTU: 310:10 SCO MTU: 64:8
UP RUNNING PSCAN ISCAN
RX bytes:1242 acl:0 sco:0 events:77 errors:0
TX bytes:2079 acl:0 sco:0 commands:77 errors:0
这是 'scanner' 的 hciconfig 输出：
hci0: Type: BR/EDR Bus: USB
BD Address: 00:1A:7D:DA:71:13 ACL MTU: 310:10 SCO MTU: 64:8
UP RUNNING PSCAN ISCAN
RX bytes:11753 acl:0 sco:0 events:552 errors:0
TX bytes:1842 acl:0 sco:0 commands:75 errors:0
我错过了什么让它工作？
更新：
按照 David 的建议，我将 cmd 值更改为
hcitool -i hci0 cmd 0x08 0x0008 10 02 01 1a 0c ff 18 01 48 45 4c 4c 4f 57 4f 52 4c 44
得到这个输出
< HCI Command: ogf 0x08, ocf 0x0008, plen 18
10 02 01 1A 0C FF 18 01 48 45 4C 4C 4F 57 4F 52 4C 44
> HCI Event: 0x0e plen 4
01 08 20 12
但有效载荷仍然是乱码（hcidump --raw 输出的有效载荷部分）
af:08:0a:02:02:01:02
b7:08:0a:02:02:01:02
be:08:0a:02:02:01:02
...
更新二：
按照下一条建议，我尝试向有效载荷中添加一些 00：
< HCI Command: ogf 0x08, ocf 0x0008, plen 42
10 02 01 1A 0C FF 18 01 48 45 4C 4C 4F 57 4F 52 4C 44 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00
> HCI Event: 0x0e plen 4
01 08 20 12
这里是 hcidump --raw output
> 04 3E 16 02 01 04 00 14 71 DA 7D 1A 00 0A 09 09 6D 69 6E 74
31 37 2D 30 BF
> 04 3E 12 02 01 00 00 14 71 DA 7D 1A 00 06 02 01 02 02 0A 08
AC
> 04 3E 12 02 01 00 00 14 71 DA 7D 1A 00 06 02 01 02 02 0A 08
BF
> 04 3E 16 02 01 04 00 14 71 DA 7D 1A 00 0A 09 09 6D 69 6E 74
31 37 2D 30 BF
> 04 3E 12 02 01 00 00 14 71 DA 7D 1A 00 06 02 01 02 02 0A 08
AD
所以还是不开心。
尝试不同的（也许是旧的）版本的 bluez 有意义吗？或者它可能与硬件相关，我应该尝试获得不同的蓝牙加密狗？
更新 3：
对适用于 David 的 bluez 5.21 进行了同样的尝试。
这是 hcidump --raw 输出的片段
> 04 3E 0C 02 01 04 00 14 71 DA 7D 1A 00 00 D7
> 04 3E 22 02 01 00 00 14 71 DA 7D 1A 00 16 02 01 0A 02 0A 08
0F 09 72 73 73 6D 74 2D 63 6C 69 65 6E 74 2D 30 D4
> 04 3E 0C 02 01 04 00 14 71 DA 7D 1A 00 00 D4
> 04 3E 22 02 01 00 00 14 71 DA 7D 1A 00 16 02 01 0A 02 0A 08
0F 09 72 73 73 6D 74 2D 63 6C 69 65 6E 74 2D 30 D2
主机名已更改（目前已在第三台机器上测试），因此输出有点不同，但我仍然没有在任何地方看到 'hello world'。
此时欢迎任何想法！
更新四：
尝试了不同的硬件加密狗（IOGEAR GBU521W6，正如 David 所建议的那样），现在看起来很有前途！
使用此广告配置时：
hcitool -i hci0 cmd 0x08 0x0008 10 02 01 1a 0c ff 18 01 48 45 4c 4c 4f 57 4f 52 4c 44
我得到这个 hcidump --raw 输出：
> 04 3E 1C 02 01 00 00 BA D0 63 70 F3 5C 10 02 01 1A 0C FF 18 01 48 45 4C 4C 4F 57 4F 52 4C B5
如您所见，有效负载几乎已完成，但缺少最后一个字符。通过将长度属性更改为 11，我得到了完整的有效负载：
hcitool -i hci0 cmd 0x08 0x0008 11 02 01 1a 0c ff 18 01 48 45 4c 4c 4f 57 4f 52 4c 44
----
> 04 3E 1D 02 01 00 00 BA D0 63 70 F3 5C 11 02 01 1A 0C FF 18 01 48 45 4C 4C 4F 57 4F 52 4C 44 AB
所以对于未来（和不同的有效载荷）：所需的长度似乎是有效载荷的字节数（没有长度属性）- 在这种情况下为 17。
重要提示： 它不适用于我的 bluez 5.26，我现在正在使用 bluez 5.21。
两期：
首先，为了让 BlueZ 进行通告，您提供的字节序列必须包含有效的 BLE 通告 header，最少为 8 个字节。所以要宣传 "helloworld" 你实际上需要发送：
sudo hcitool -i hci0 cmd 0x08 0x0008 10 02 01 1a 0c ff 18 01 48 45 4c 4c 4f 57 4f 52 4c 44
前 8 个字节是 header，接下来的 10 个字节是编码为 8 位 ASCII 的字符串 "helloworld"。
前8个字节可以这样分解：
10 # Total length of the advertising packet
02 # Number of bytes that follow in first AD structure
01 # Flags AD type
1A # Flags value 0x1A = 000011010
bit 0 (OFF) LE Limited Discoverable Mode
bit 1 (ON) LE General Discoverable Mode
bit 2 (OFF) BR/EDR Not Supported
bit 3 (ON) Simultaneous LE and BR/EDR to Same Device Capable (controller)
bit 4 (ON) Simultaneous LE and BR/EDR to Same Device Capable (Host)
0C # Number of bytes that follow in second (and last) AD structure
FF # Manufacturer specific data AD type
18 01 # Company identifier code (0x0118 == Radius Networks)
请注意，此 header 包含两个不同的长度字段，如果您更改 "helloworld" 有效负载的长度，则必须调整这两个字段。此外，出于实验目的，欢迎您使用任意两个字节作为您想要的公司标识符。
其次，您无法使用 hcitool lescan 命令查看检测到的广告的原始字节。 要查看原始字节，您必须使用此命令结合 hcidump 命令。详情请看这里：https://whosebug.com/a/21790504/1461050