* Possible bug: D-Bus Advertising API does not generate first section of advertising payload
@ 2016-08-02 14:40 Alex Coplan
2016-08-02 17:26 ` Vinicius Costa Gomes
0 siblings, 1 reply; 5+ messages in thread
From: Alex Coplan @ 2016-08-02 14:40 UTC (permalink / raw)
To: linux-bluetooth
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
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: Possible bug: D-Bus Advertising API does not generate first section of advertising payload 2016-08-02 14:40 Possible bug: D-Bus Advertising API does not generate first section of advertising payload Alex Coplan @ 2016-08-02 17:26 ` Vinicius Costa Gomes 2016-08-03 10:19 ` Luiz Augusto von Dentz 0 siblings, 1 reply; 5+ messages in thread From: Vinicius Costa Gomes @ 2016-08-02 17:26 UTC (permalink / raw) To: Alex Coplan, linux-bluetooth Hi Alex, Alex Coplan <alex.coplan@starleaf.com> 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. > > 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. Quoting the specification (Core Specification Supplement v6, part A, Section 1.3.1, page 12): "The Flags data type shall be included when any of the Flag bits are non-zero and the advertising packet is connectable, otherwise the Flags data type may be omitted. All octets that are 0x00 are not transmitted as long as all other octets after that octet are also 0x00." I guess BlueZ (the kernel side in this case, around net/bluetooth/hci_request.c:1081) interprets this as if the flags are zero, they can be omitted. It seems that the correct interpretation would be that it could be omitted only if the rest of the advertising payload was all zeroes. (nice diagrams btw :-) > > Regards, > Alex > > -- > To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html Cheers, -- Vinicius ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Possible bug: D-Bus Advertising API does not generate first section of advertising payload 2016-08-02 17:26 ` Vinicius Costa Gomes @ 2016-08-03 10:19 ` Luiz Augusto von Dentz 2016-08-03 10:32 ` Alex Coplan 0 siblings, 1 reply; 5+ messages in thread From: Luiz Augusto von Dentz @ 2016-08-03 10:19 UTC (permalink / raw) To: Vinicius Costa Gomes; +Cc: Alex Coplan, linux-bluetooth@vger.kernel.org Hi Alex, Vinicius, On Tue, Aug 2, 2016 at 8:26 PM, Vinicius Costa Gomes <vinicius.gomes@intel.com> wrote: > Hi Alex, > > Alex Coplan <alex.coplan@starleaf.com> 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. >> >> 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. > > Quoting the specification (Core Specification Supplement v6, part A, > Section 1.3.1, page 12): > > "The Flags data type shall be included when any of the Flag bits are > non-zero and the advertising packet is connectable, otherwise the Flags > data type may be omitted. All octets that are 0x00 are not transmitted > as long as all other octets after that octet are also 0x00." > > I guess BlueZ (the kernel side in this case, around > net/bluetooth/hci_request.c:1081) interprets this as if the flags are > zero, they can be omitted. It seems that the correct interpretation would > be that it could be omitted only if the rest of the advertising payload > was all zeroes. I don't were someone would interpret that or perhaps you are talking about: 'The Flags field may be zero or more octets long.' 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. > (nice diagrams btw :-) > >> >> Regards, >> Alex >> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html > > Cheers, > -- > Vinicius > -- > To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Luiz Augusto von Dentz ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Possible bug: D-Bus Advertising API does not generate first section of advertising payload 2016-08-03 10:19 ` Luiz Augusto von Dentz @ 2016-08-03 10:32 ` Alex Coplan 2016-08-03 11:17 ` Luiz Augusto von Dentz 0 siblings, 1 reply; 5+ messages in thread From: Alex Coplan @ 2016-08-03 10:32 UTC (permalink / raw) To: Luiz Augusto von Dentz Cc: Vinicius Costa Gomes, linux-bluetooth@vger.kernel.org Hi both, > On 3 Aug 2016, at 11:19, Luiz Augusto von Dentz <luiz.dentz@gmail.com> wrote: > > Hi Alex, Vinicius, > > On Tue, Aug 2, 2016 at 8:26 PM, Vinicius Costa Gomes > <vinicius.gomes@intel.com> wrote: >> Hi Alex, >> >> Alex Coplan <alex.coplan@starleaf.com> 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. > >>> >>> 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. >> >> Quoting the specification (Core Specification Supplement v6, part A, >> Section 1.3.1, page 12): >> >> "The Flags data type shall be included when any of the Flag bits are >> non-zero and the advertising packet is connectable, otherwise the Flags >> data type may be omitted. All octets that are 0x00 are not transmitted >> as long as all other octets after that octet are also 0x00." >> >> I guess BlueZ (the kernel side in this case, around >> net/bluetooth/hci_request.c:1081) interprets this as if the flags are >> zero, they can be omitted. It seems that the correct interpretation would >> be that it could be omitted only if the rest of the advertising payload >> was all zeroes. > > I don't were someone would interpret that or perhaps you are talking about: > > 'The Flags field may be zero or more octets long.' > > 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. > >> (nice diagrams btw :-) >> >>> >>> Regards, >>> Alex >>> >>> -- >>> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in >>> the body of a message to majordomo@vger.kernel.org >>> More majordomo info at http://vger.kernel.org/majordomo-info.html >> >> Cheers, >> -- >> Vinicius >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html 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. Cheers, Alex ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Possible bug: D-Bus Advertising API does not generate first section of advertising payload 2016-08-03 10:32 ` Alex Coplan @ 2016-08-03 11:17 ` Luiz Augusto von Dentz 0 siblings, 0 replies; 5+ messages in thread From: Luiz Augusto von Dentz @ 2016-08-03 11:17 UTC (permalink / raw) To: Alex Coplan; +Cc: Vinicius Costa Gomes, linux-bluetooth@vger.kernel.org Hi Alex, On Wed, Aug 3, 2016 at 1:32 PM, Alex Coplan <alex.coplan@starleaf.com> wrote: > Hi both, > >> On 3 Aug 2016, at 11:19, Luiz Augusto von Dentz <luiz.dentz@gmail.com> wrote: >> >> Hi Alex, Vinicius, >> >> On Tue, Aug 2, 2016 at 8:26 PM, Vinicius Costa Gomes >> <vinicius.gomes@intel.com> wrote: >>> Hi Alex, >>> >>> Alex Coplan <alex.coplan@starleaf.com> 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. -- Luiz Augusto von Dentz ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2016-08-03 11:17 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2016-08-02 14:40 Possible bug: D-Bus Advertising API does not generate first section of advertising payload Alex Coplan 2016-08-02 17:26 ` Vinicius Costa Gomes 2016-08-03 10:19 ` Luiz Augusto von Dentz 2016-08-03 10:32 ` Alex Coplan 2016-08-03 11:17 ` Luiz Augusto von Dentz
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.
