Bluez blottoothctl扫描与hcitool扫描 [英] Bluez blotoothctl scan vs hcitool scan
问题描述
我正在Raspberry Pi(Bester和Stretch)上运行bluez 5.50.我有一个ble传感器设备，仅在按下传感器设备上的按钮时才发布数据.因此，广告是异步的，并且它们之间没有定期广告(并且所有数据包都是唯一的，没有重复).我遇到了与Bluez的问题，尽管一旦收到数据包，Bluez似乎在接下来的大约11秒钟内不会再报告来自该设备的任何其他数据包(有时间隔会更短).这与bluetoothctl命令行工具以及我自己的c ++应用程序一起使用(基于bluez client/main.c示例).在这两种情况下，在开始扫描之前，我都要清除扫描过滤器，将transport设置为le，然后将重复数据报告设置为on.相反，在运行hcitool扫描时，我看到了来自传感器的所有数据包(它甚至似乎正在报告在不同广告渠道上广播的所有3个副本).所以我的问题是，有没有办法通过dbus api来获取那些丢失的广告，可能还需要一些其他设置?如果不是，那么可以从C ++中使用hci api，它应该可以解决问题吗?任何帮助表示感谢，谢谢！
I'm running bluez 5.50 on a Raspberry Pi (both Buster and Stretch). I have a ble sensor device that advertises data only when a button on the sensor device is pressed. So advertisements are asynchronous and there are no periodic advertisements in between (and all packets are unique, no duplicates). I'm having an issue with Bluez though where once a packet is received, Bluez seems to not report any additional packets from the device for the next approximately 11 seconds (very occasionally the interval is shorter). This is with the bluetoothctl line command tool as well as my own c++ application (based off the bluez client/main.c example). In both cases before starting a scan I clear the scan filter, set transport to le, and set duplicate-data reporting on. Conversely, when running hcitool scan I see all the packets from the sensor (it even seems to be reporting all 3 copies broadcast on the different advertisement channels). So my question is, is there a way to get those missing advertisements through the dbus api, possibly some additional setting somewhere? If not, is the hci api okay to use from c++ and should it do the trick? Any help appreciated, thanks!
根据Alex的问题进行编辑-
Edited per Alex's questions -
您是否尝试下载最新的bluez(5.53) https://git.kernel.org/pub/scm/bluetooth/bluez.git 吗?
还没有，只是想检查一下是否可能是事先知道的东西.
Not yet, just wanted to check and see if this might be something known beforehand.
您是否正在使用hcitool scan或sudo hcitool lescan?如果您正在运行hcitool扫描，则说明您正在拾取经典的蓝牙(不是低能耗数据包).hcitool是已弃用的工具.我发现sudo hcitool lescan仅适用于BLE 4.x控制器.该功能在5.x控制器上失败.
Are you using hcitool scan or sudo hcitool lescan? If you are running hcitool scan, you are picking up bluetooth classic (not low energy packets). hcitool is a deprecated tool. I've found that sudo hcitool lescan only works with BLE 4.x controllers. The function fails on 5.x controller.
hcitool lescan(在根目录下)，是的，硬件是Pi Zero/W和P3，所以是BLE 4.x控制器(我假设)
hcitool lescan (under root), and yes, the hardware is a Pi Zero/W and a P3 so BLE 4.x controllers (I assume)
您是否尝试过运行sudo btmon来查看扫描期间的所有HCI通信?
Have you tried running sudo btmon to see all of the HCI communication during scanning?
我有但不记得我所看到的东西，除了它与其他任何东西都没有矛盾，即丢失了带有dbus api和hci的数据包
I have but can't remember exactly what I saw other than it didn't contradict anything else, i.e. missing packets w/ dbus api vs hci
您能否提供使用蓝牙的代码，例如:
Can you provide code for your use of bluetoothctl, ie:
$bluetoothctl
[bluetooth]# menu scan
[bluetooth]# clear
[bluetooth]# transport le
[bluetooth]# duplicated-data on
[bluetooth]# back
[bluetooth]# scan on
总是完全如您所言...
always exactly as you've noted...
您还可以提供hciconfig -a的结果吗?
Could you also provide the results of hciconfig -a
--- Results (P Zero) -
hci0: Type: Primary Bus: UART
BD Address: B8:27:EB:79:2E:3F ACL MTU: 1021:8 SCO MTU: 64:1
UP RUNNING
RX bytes:55476 acl:126 sco:0 events:2012 errors:0
TX bytes:6956 acl:114 sco:0 commands:444 errors:0
Features: 0xbf 0xfe 0xcf 0xfe 0xdb 0xff 0x7b 0x87
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy: RSWITCH SNIFF
Link mode: SLAVE ACCEPT
Name: 'HubPi01'
Class: 0x000000
Service Classes: Unspecified
Device Class: Miscellaneous,
HCI Version: 4.1 (0x7) Revision: 0x168
LMP Version: 4.1 (0x7) Subversion: 0x2209
Manufacturer: Broadcom Corporation (15)
--- Results (P3) -
hci0: Type: Primary Bus: UART
BD Address: B8:27:EB:2B:A2:A3 ACL MTU: 1021:8 SCO MTU: 64:1
UP RUNNING
RX bytes:10995 acl:0 sco:0 events:390 errors:0
TX bytes:2145 acl:0 sco:0 commands:91 errors:0
Features: 0xbf 0xfe 0xcf 0xfe 0xdb 0xff 0x7b 0x87
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy: RSWITCH SNIFF
Link mode: SLAVE ACCEPT
Name: 'HubPi02'
Class: 0x000000
Service Classes: Unspecified
Device Class: Miscellaneous,
HCI Version: 4.1 (0x7) Revision: 0x168
LMP Version: 4.1 (0x7) Subversion: 0x2209
Manufacturer: Broadcom Corporation (15)
下面是一次扫描，扫描时间约20秒(删除所有无关的数据包)，我大约每2秒按下一次传感器上的按钮，然后再放下2秒钟再放开.第一块来自bluetoothctl，第二个来自"hcidump --raw".(在第二个树莓派上).前四个字节蓝牙数据包中的数据是一个小端字节序号传感器为每个新数据包递增.下一个字节表示一个按钮上/下动作.您可以看到蓝牙报告的数据包编号为05df，05e5、05e9.在原始转储中，序列号位于顶行的末尾.那里您可以看到所有数据包都按顺序排列，报告了1至3次(我认为是报告它捕获的所有广告渠道).所有数据包都存在05df至hcidump扫描中的05e9.最后是"hcitool lescan --duplicates"的输出，我不太确定它是如何映射的...
Below is a scan covering about 20 seconds (editing out all unrelated packets), where I'm pressing down the button on the sensor about every 2 seconds and then holding it down for another 2 seconds before letting it up. The first chunk is from bluetoothctl, the second from "hcidump --raw" (on a second raspberry pi). The first four bytes in the bluetoothctl packet data is a little endian packet seq number incremented by the sensor for each new packet. The next byte indicates a button up/down action. You can see bluetoothctl reported packets numbered 05df, 05e5, 05e9. In the raw dump the seq number is at the end of the top line. There you can see all packets are in order, reported 1 to 3 times (I assume it is reporting all advertising channels it catches). All packets are present 05df to 05e9 in the hcidump scan. Lastly is the output from "hcitool lescan --duplicates", which I'm not really sure how it maps...
------ bluetoothctl
.
[NEW] Device E2:15:00:01:73:96 E2-15-00-01-73-96
[CHG] Device E2:15:00:01:73:96 RSSI: -46
[CHG] Device E2:15:00:01:73:96 ManufacturerData Key: 0x03da
[CHG] Device E2:15:00:01:73:96 ManufacturerData Value:
df 05 00 00 10 a1 ac 8a b4 .........
[CHG] Device E2:15:00:01:73:96 RSSI: -45
[CHG] Device E2:15:00:01:73:96 ManufacturerData Key: 0x03da
[CHG] Device E2:15:00:01:73:96 ManufacturerData Value:
e5 05 00 00 10 e7 4f 67 6e ......Ogn
.
[CHG] Device E2:15:00:01:73:96 RSSI: -65
[CHG] Device E2:15:00:01:73:96 ManufacturerData Key: 0x03da
[CHG] Device E2:15:00:01:73:96 ManufacturerData Value:
e9 05 00 00 10 f4 f9 f8 7d ........}
---------- hcidump --raw
> 04 3E 19 02 01 03 01 96 73 01 00 15 E2 0D 0C FF DA 03 DF 05
00 00 10 A1 AC 8A B4 C3
> 04 3E 19 02 01 03 01 96 73 01 00 15 E2 0D 0C FF DA 03 DF 05
00 00 10 A1 AC 8A B4 BE
> 04 3E 19 02 01 03 01 96 73 01 00 15 E2 0D 0C FF DA 03 E0 05
00 00 11 11 0F 3E 24 B6
> 04 3E 19 02 01 03 01 96 73 01 00 15 E2 0D 0C FF DA 03 E1 05
00 00 10 F7 68 07 50 BE
> 04 3E 19 02 01 03 01 96 73 01 00 15 E2 0D 0C FF DA 03 E1 05
00 00 10 F7 68 07 50 CF
> 04 3E 19 02 01 03 01 96 73 01 00 15 E2 0D 0C FF DA 03 E1 05
00 00 10 F7 68 07 50 BA
> 04 3E 19 02 01 03 01 96 73 01 00 15 E2 0D 0C FF DA 03 E2 05
00 00 11 1D 18 A8 2A BF
> 04 3E 19 02 01 03 01 96 73 01 00 15 E2 0D 0C FF DA 03 E2 05
00 00 11 1D 18 A8 2A C0
> 04 3E 19 02 01 03 01 96 73 01 00 15 E2 0D 0C FF DA 03 E2 05
00 00 11 1D 18 A8 2A B8
> 04 3E 19 02 01 03 01 96 73 01 00 15 E2 0D 0C FF DA 03 E3 05
00 00 10 E2 29 C7 F7 BB
> 04 3E 19 02 01 03 01 96 73 01 00 15 E2 0D 0C FF DA 03 E4 05
00 00 11 57 F0 5C 76 BD
> 04 3E 19 02 01 03 01 96 73 01 00 15 E2 0D 0C FF DA 03 E4 05
00 00 11 57 F0 5C 76 C1
> 04 3E 19 02 01 03 01 96 73 01 00 15 E2 0D 0C FF DA 03 E5 05
00 00 10 E7 4F 67 6E CA
> 04 3E 19 02 01 03 01 96 73 01 00 15 E2 0D 0C FF DA 03 E6 05
00 00 11 77 63 92 CE C0
> 04 3E 19 02 01 03 01 96 73 01 00 15 E2 0D 0C FF DA 03 E6 05
00 00 11 77 63 92 CE BA
> 04 3E 19 02 01 03 01 96 73 01 00 15 E2 0D 0C FF DA 03 E6 05
00 00 11 77 63 92 CE BE
> 04 3E 19 02 01 03 01 96 73 01 00 15 E2 0D 0C FF DA 03 E7 05
00 00 10 2D 52 48 C2 BD
> 04 3E 19 02 01 03 01 96 73 01 00 15 E2 0D 0C FF DA 03 E8 05
00 00 11 EE 32 20 9D BD
> 04 3E 19 02 01 03 01 96 73 01 00 15 E2 0D 0C FF DA 03 E8 05
00 00 11 EE 32 20 9D C1
> 04 3E 19 02 01 03 01 96 73 01 00 15 E2 0D 0C FF DA 03 E9 05
00 00 10 F4 F9 F8 7D BC
------- hcitool lescan --duplicates
E2:15:00:01:73:96 (unknown)
E2:15:00:01:73:96 (unknown)
E2:15:00:01:73:96 (unknown)
E2:15:00:01:73:96 (unknown)
E2:15:00:01:73:96 (unknown)
E2:15:00:01:73:96 (unknown)
E2:15:00:01:73:96 (unknown)
推荐答案
Have you tried downloading the latest bluez (5.53) https://git.kernel.org/pub/scm/bluetooth/bluez.git ?
您是否正在使用 hcitool scan 或 sudo hcitool lescan ?如果您正在运行 hcitool scan ，则说明您正在选择蓝牙经典设备(不是低能耗的数据包). hcitool 是已弃用的工具.我发现 sudo hcitool lescan 仅适用于BLE 4.x控制器.该功能在5.x控制器上失败.
Are you using hcitool scan or sudo hcitool lescan? If you are running hcitool scan, you are picking up bluetooth classic (not low energy packets). hcitool is a deprecated tool. I've found that sudo hcitool lescan only works with BLE 4.x controllers. The function fails on 5.x controller.
您是否尝试过运行 sudo btmon 来查看扫描过程中的所有HCI通信?
Have you tried running sudo btmon to see all of the HCI communication during scanning?
您能否提供使用 bluetoothctl 的代码，即:
Can you provide code for your use of bluetoothctl, ie:
$bluetoothctl
[bluetooth]# menu scan
[bluetooth]# clear
[bluetooth]# transport le
[bluetooth]# duplicated-data on
[bluetooth]# back
[bluetooth]# scan on
您还可以提供 hciconfig -a
这篇关于Bluez blottoothctl扫描与hcitool扫描的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
