Wrong payload when using BlueZ stack as peripheral - linux

Question

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
Which gives me this output:
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
Note that I can't use the advised command hciconfig hci0 leadv 0 because it will throw the error Warning: unknown command - "0".
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 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)
matching hcidump --raw output snippet:
> 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
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
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?
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
getting this output
< 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
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
...
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
And here the 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
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?
Update 3:
Tried the same with bluez 5.21 which works for David.
Here's a snippet of the hcidump --raw output
> 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
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!
Update 4:
Tried a different hardware dongle (IOGEAR GBU521W6 as suggested by David) and this looks very promising now!
When using this advertising config:
hcitool -i hci0 cmd 0x08 0x0008 10 02 01 1a 0c ff 18 01 48 45 4c 4c 4f 57 4f 52 4c 44
I get this hcidump --raw output:
> 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
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
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.
Important: It does not work with bluez 5.26 for me, I'm using bluez 5.21 now.

Answer 1

Two issues:
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
The first 8 bytes are the header and the next 10 bytes are the string "helloworld" encoded as 8-bit ASCII.
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)
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.
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