Wrong payload when using BlueZ stack as peripheral

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.

score 7 · Accepted Answer · edited May 23 '17 at 12:16

7

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

edited May 23 '17 at 12:16

Community

1
1

answered Feb 01 '15 at 13:32

davidgyoung

63,876
14
121
204

thanks, makes sense, but still not receiving what I want to send (see updated question). – marce Feb 01 '15 at 14:33
See my updated answer with instructions on how to see the raw bytes when scanning. – davidgyoung Feb 01 '15 at 18:19
I'm already using `hcidump --raw` (just stripped the non-payload infos in the update of the OP, should have clarified that better). I checked the question you linked, but except filtering which I consider a second step once I can have the payload appear anywhere I don't see any other step I missed? – marce Feb 01 '15 at 19:06
Hmmmm.... try adding a dozen or so extra 00 bytes on the end of your advetisement. I have seen BlueZ reject shot advertisements sometimes. Also, these instructions have been tested on a GBU521 dongle. It is possible that a different dongle may not completely work with BlueZ. Which one are you using? – davidgyoung Feb 01 '15 at 20:06
Another thing you might try is to use a different detector app (plenty are available for Android and iOS) so you can see it is the transmitter or receiver are what is causing the problem. – davidgyoung Feb 01 '15 at 20:07
Tried adding zeros without success. I'm using two Raspberry Pis, so commandline it is I'm afraid, but I can try to hack a WP test app which I will do now. Do you think testing an older bluez version could be worth a try? – marce Feb 03 '15 at 14:46
Using the WP BLE API it does not find the peripheral, while anotzher linux box sees the adv reports, so it may be a WP problem or something is very fishy. – marce Feb 03 '15 at 15:35
I'm not sure what WP stands for here. Do you have a BLE-capable smarthphone you can use to try to see the advertisements? Yes, you could try an older BlueZ version. We have tested with 5.21 successfully. – davidgyoung Feb 03 '15 at 16:41
Heh, I suppose Windows Phone is so unpopular it does not deserve an abbreviation ;) Will try with and 5.21 and report back! – marce Feb 03 '15 at 17:10
Apologies on missing the WP reference! Unfortunately, Windows Phones 8.1 cannot be used to see beacons. You'll have to wait for Windows 10. See here: http://stackoverflow.com/a/26234432/1461050 – davidgyoung Feb 03 '15 at 18:48
No worries, there are reasons it's not widely used ;-) Using bluez 5.21 didn't improve the situation. Do you have any other ideas what I could try? – marce Feb 03 '15 at 21:21
It's sounding to me like it is an issue of the hardware dongle, unfortunately. I would try to get your hands on a different one. The IOGear GBU521 is known to work. – davidgyoung Feb 03 '15 at 22:07
Thanks for the hint, ordered two GBU521W, delivery is due friday so I hope I can report back on Saturday. – marce Feb 04 '15 at 08:48
It seems to work now, the new dongle did the trick! Just curious about the length attributes, I suppose I'm still not fully understanding them (see OP). Maybe update your answer with the hardware hint to have it complete and then I'll accept it. Thanks for your help! – marce Feb 06 '15 at 10:56

Wrong payload when using BlueZ stack as peripheral

1 Answers1

Linked