使用 BlueZ 堆栈作为外围设备时的有效负载错误 [英] Wrong payload when using BlueZ stack as peripheral

查看:32
本文介绍了使用 BlueZ 堆栈作为外围设备时的有效负载错误的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我尝试按照 davidgyoung 在这个问题.以下是我使用的命令:

I tried to follow the steps provided by davidgyoung in this question. Here are the commands I use:

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".

Note that I can't use the advised command hciconfig hci0 leadv 0 because it will throw the error Warning: unknown command - "0".

但是,当我尝试从另一台设备读出(例如使用 hcidump --raw)广告包中的有效负载时,我得到如下输出:

However, when I try to read out (e.g. with a hcidump --raw) the payload in the advertised package from another device I'm getting an output like this:

hcitool lescan --duplicates 输出片段(两个条目一遍又一遍地重复,但从 MAC 上看,它应该是同一台设备):

hcitool lescan -- duplicates output snippet (both entries are repeated over and over again, looking at the MAC it should be the same device, though):

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 输出:

I'm using Bluez 5.26 and CSR4.0 dongles.
This is the hciconfig output of the advertisier:

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

这是来自扫描仪"的 hciconfig 输出:

And this is the hciconfig output from the 'scanner':

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

我错过了什么才能让它工作?

What did I miss to get it to work?

更新:
按照 David 的建议,我将 cmd 值更改为

Update:
Following David's advice I changed the cmd values to

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 输出的有效载荷部分)

but still gibberish payloads (payload portion of the hcidump --raw output)

af:08:0a:02:02:01:02
b7:08:0a:02:02:01:02
be:08:0a:02:02:01:02
...

更新 2:
按照下一个建议,我尝试在有效负载中添加一些 00:

Update 2:
Following the next advice I tried adding some 00 to the payload:

< 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 输出

> 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 有意义吗?还是可能与硬件有关,我应该尝试使用不同的蓝牙加密狗?

So still no joy.
Would it make sense to try a different (maybe older) version of bluez? Or can it be hardware related and I should try to get different Bluetooth dongles?

更新 3:
对适用于 David 的 bluez 5.21 进行了同样的尝试.

Update 3:
Tried the same with bluez 5.21 which works for David.

这是 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".

The hostname has changed (tested on the third machine so far), so the output is a bit different but I still don't see 'hello world' anywhere.

在这一点上,任何想法都非常受欢迎!

At this point any ideas are more than welcome!

更新 4:
尝试了不同的硬件加密狗(大卫建议的 IOGEAR GBU521W6),现在看起来很有希望!

Update 4:
Tried a different hardware dongle (IOGEAR GBU521W6 as suggested by David) and this looks very promising now!

使用此广告配置时:

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,我可以获得完整的有效负载:

As you can see the payload is almost complete, but the last char is missing. By changing the length attribute to 11 I get the full payload:

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.

So for the future (and different payloads): the required length seems to be the bytes of the payload (without the length attribute) - 17 in this case.

重要提示:它对我来说不适用于 bluez 5.26,我现在使用的是 bluez 5.21.

Important: It does not work with bluez 5.26 for me, I'm using bluez 5.21 now.

推荐答案

两个问题:

首先,为了让 BlueZ 进行广告,您提供的字节序列必须包含有效的 BLE 广告标头,最少为 8 个字节.因此,要宣传helloworld",您实际上需要发送:

First, in order to get BlueZ to advertise, the byte sequence you supply must include a valid BLE advertisement header, which is a minimum of 8 bytes. So to advertise "helloworld" you actually need to send:

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

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 个字节是标头,接下来的 10 个字节是编码为 8 位 ASCII 的字符串helloworld".

The first 8 bytes are the header and the next 10 bytes are the string "helloworld" encoded as 8-bit ASCII.

前 8 个字节可以这样分解:

The first 8 bytes can be broken down like this:

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)

请注意,此标头包含两个不同长度的字段,如果您更改helloworld"有效负载的长度,则必须对其进行调整.此外,出于实验目的,欢迎您使用任意两个字节作为所需的公司标识符.

Note that this header contains two different length fields that you must adjust if you change the length of the "helloworld" payload. Also, for experimentation purposes, you are welcome to use any two bytes for the company identifier that you want.

其次,您无法使用 hcitool lescan 命令查看检测到的广告的原始字节.要查看原始字节,您必须在结合 hcidump 命令.详情请看这里:https://stackoverflow.com/a/21790504/1461050

Second, you can't see the raw bytes of a detected advertisement with the hcitool lescan command. To see the raw bytes, you have to use this command in combination with the hcidump command. See here for details: https://stackoverflow.com/a/21790504/1461050

这篇关于使用 BlueZ 堆栈作为外围设备时的有效负载错误的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆