Apologies, forgot to copy this to the mailing list. > Begin forwarded message: > > From: Alex Coplan <alex.coplan@xxxxxxxxxxxx> > Subject: Re: Possible bug: D-Bus Advertising API does not generate first section of advertising payload > Date: 3 August 2016 at 13:20:04 BST > To: Luiz Augusto von Dentz <luiz.dentz@xxxxxxxxx> > > Hi Luiz, > >> On 3 Aug 2016, at 12:17, Luiz Augusto von Dentz <luiz.dentz@xxxxxxxxx> wrote: >> >> Hi Alex, >> >> On Wed, Aug 3, 2016 at 1:32 PM, Alex Coplan <alex.coplan@xxxxxxxxxxxx> wrote: >>> Hi both, >>> >>>> On 3 Aug 2016, at 11:19, Luiz Augusto von Dentz <luiz.dentz@xxxxxxxxx> wrote: >>>> >>>> Hi Alex, Vinicius, >>>> >>>> On Tue, Aug 2, 2016 at 8:26 PM, Vinicius Costa Gomes >>>> <vinicius.gomes@xxxxxxxxx> wrote: >>>>> Hi Alex, >>>>> >>>>> Alex Coplan <alex.coplan@xxxxxxxxxxxx> writes: >>>>> >>>>>> 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. >>>> >>>> Not sure where you got this from but 1a is not formatted according to >>>> the CSS, bits 5-7 are reserved also a broadcast shall not set LE >>>> General Discoverable Mode so this is very odd. >>> >>> This packet was generated by the code that I linked to on GitHub. That >>> code is also broken because it sets the packets to be connectable (ADV_IND) >>> instead of ADV_NONCONN_IND as it should be for a Beacon advertisement. >> >> Actually this is upstream and indeed is is not using the correct >> packet type as you said, but then the flags don't many any sense >> anymore, perhaps you can try changing it there to see how it would >> work with ADV_NONCONN_IND. >> >>>> But Im not sure if it is referring to the octet 0 as in the table >>>> bellow it or we should just send the setting the size to 1 and >>>> followed by type and no fields, if the intention is to save space, >>>> which I think it is, the omitting the flag makes a lot more sense >>>> specially since none of the flags fields applies to a broadcaster. >>> >>> Thanks for this. I also wonder whether setting the size to 1 in the case of zero >>> flags would fix the issue here. Clearly, omitting this part of the payload >>> altogether is breaking this case. >> >> Try that with ibeacon.c and let us know. > > I’ve just tried a couple of things using ibeacon.c. > > Unfortunately, I couldn’t get the packet without the flags field to > work on iOS; this packet simply isn’t recognised: > > 1D 01 01 1A FF 4C 00 02 15 56 5C A5 BE 7A DF 4F 7B B2 68 91 > F4 08 D7 70 CD 00 2A 00 35 E3 00 00 > > > However, setting the flags to zero and keeping them in there works > fine: > > 1E 02 01 00 1A FF 4C 00 02 15 56 5C A5 BE 7A DF 4F 7B B2 68 > 91 F4 08 D7 70 CD 00 0B 00 0C E3 00 > > Perhaps the flags should be included even if they are zero? > > Thanks, > 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
