Possible bug: D-Bus Advertising API does not generate first section of advertising payload

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi all,

I’m experiencing a bit of trouble using the BlueZ D-Bus API for broadcast advertising. In particular, I’m trying to generate iBeacon advertisements using the API.

So far, I have successfully used the D-Bus API to implement LE peripheral advertising (Type = ‘peripheral’). However, getting BlueZ to generate well-formed iBeacon packets is proving problematic.

In the process of debugging, I used hcidump to obtain the advertising payload produced by my code. I have a reference implementation using the HCI socket API to generate iBeacon advertisements, and this works well. Here is the advertising payload generated by the HCI code (which I obtained from here: https://github.com/carsonmcdonald/bluez-ibeacon/blob/master/bluez-beacon/ibeacon.c).

==============================================================
      Working advertising payload generated by HCI code
==============================================================
                                                           
  Total    AD 0   Ad            AD 1   Ad     Apple Inc   
  Length   Len    Type  Flags   Len    Type   ---------   
    |      |      |      |      |      |      |       |   
    1e     02     01     1a     1a     ff     4c     00   

    iBeacon
    Prefix        . . . . . . .  U   U   I   D  . . . .
    ---------     -------------------------------------
    |       |     |
    02     15     56     5c     a5     be     7a     df

    . . . . . .  U   U   I   D  . . . . . . . . . . . .
    ---------------------------------------------------
    4f     7b     b2     68     91     f4     08     d7

    . . . . .     Major=10      Minor=10      Tx
    ---------     ---------     ---------     Power  Padding
            |     |       |     |       |     |      |   
    70     cd     00     0a     00     0a     cf     00

============================================================

I am using the terminology from this packet diagram (http://www.argenox.com/wp-content/uploads/ibeacon-packet-format.png). Packets containing this advertising payload are correctly recognised by iOS devices as iBeacon packets.

In my D-Bus code, I am sending advertisements to BlueZ with the following parameters:
 - Type = 'broadcast'
 - ServiceUUIDs = []
 - ManufacturerData = { 0x4C: 02 15 [UUID] 00 0a 00 0a } (2 byte manufacturer ID + 22 bytes of data)
 - SolicitUUIDs = []
 - ServiceData = []
 - IncludeTxPower = True

This follows the iBeacon spec as closely as possible. Unfortuantely, the packets generated by BlueZ are not recognised by iOS devices! On closer inspection, it becomes apparent why this is the case:

==============================================================
     Broken advertisement payload generated by D-Bus code
==============================================================

                                      iBeacon
  Total   AD 1   Ad     Apple Inc     Prefix        .  . 
  Length  Len    Type   ---------     ---------     -----
   |      |      |      |       |     |       |     |
   1d     19     ff     4c     00     02     15     56

   .  .  .  .  .  .   U   U   I   D   .  .  .  .  .  . 
   ---------------------------------------------------
   5c     a5     be     7a     df     4f     7b     b2

   .  .  .  .  .  .   U   U   I   D  .  .  .  .     Major
   --------------------------------------------     -----
                                              |     |
   68     91     f4     08     d7     70     cd     00

          Minor=10      Tx      ? ? ? ?       Padding
  --      ---------     Power? ---------     ---------
   |      |       |     |      |       |     |       |
   0a     00     0a     02     0a     08     00     00

==============================================================

The most obvious difference between this packet and the correct one is that this packet is missing the AD 0 section! BlueZ fails to emit this part of the advertisement packet altogether. I assume that without this section, the packet is sufficiently malformed that devices cannot recognise it as an iBeacon packet.

Is this a bug, or am I missing something? Any help or advice would be greatly appreciated.

Regards,
Alex

--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Bluez Devel]     [Linux Wireless Networking]     [Linux Wireless Personal Area Networking]     [Linux ATH6KL]     [Linux USB Devel]     [Linux Media Drivers]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Big List of Linux Books]

  Powered by Linux