This patch proposes an extension to the D-Bus Device API to allow
an application access to the last EIR data received from a device
in inquiry or advertising mode.
Rationale is that increasing numbers of LE profiles are using custom
fields in the advertising and scan response reports to carry important
information. e.g. the Anki Drive peripherals include necessary
information in the advertiesment that is not replicated in the GATT
Service they export.
It would be nice if it were possible to support these profiles at the
application layer without extending BlueZ every time via a plugin.
Since EIR has a variable-length type field, more complex parsing
would require applications registering the types with BlueZ in advance
putting a higher complexity burden on the daemon, including resolving
conflicts where types overlap. Exposing the raw EIR data to the
application allows them to deal with all such problems in whatever
manner they require.
---
doc/device-api.txt | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/doc/device-api.txt b/doc/device-api.txt
index 577ee60..9620ec0 100644
--- a/doc/device-api.txt
+++ b/doc/device-api.txt
@@ -193,3 +193,8 @@ Properties string Address [readonly]
Received Signal Strength Indicator of the remote
device (inquiry or advertising).
+
+ array{byte} EIR [readonly, optional]
+
+ Last received EIR data from the remote device
+ during inquiry or advertising.
--
1.9.3 (Apple Git-50)
On Fri, Jun 27, 2014 at 12:55 PM, Marcel Holtmann <[email protected]> wro=
te:
>> This patch proposes an extension to the D-Bus Device API to allow
>> an application access to the last EIR data received from a device
>> in inquiry or advertising mode.
>>
> in general I have no objections in exposing the EIR and AD information. H=
owever I do not like to use EIR as property key. I know that on mgmt API we=
simply went with EIR_Data, but on the D-Bus API we most likely need to fin=
d a name that is a bit more generic and allows to represent EIR and AD info=
rmation.
>
Thinking about this a little bit more, I'm not sure this should be a
Device property either. The advertisement data isn't really a property
of the device, but a property of the advertisement itself.
A peripheral could theoretically send different advertisements, a
weird example might be a peripheral sending a non-connectable
undirected advertisement generally, and a connectable directed
advertisement to us directly, with different AD.
This seems to fold back nicely into the discussion about a "Find
Devices" API, intended for applications and separate from the
StartDiscovery API. If that were an "agent" mode, it could look
something like this:
<- Search( { Data: "FF4C000214" }, agent_object_path )
-> DeviceFound( device_object_path, data )
-> DeviceFound( device_object_path, data )
-> DeviceFound( device_object_path, data )
Where data in the agent method is the unparsed advertisement data, if
the application is interested in it. The above example is looking for
an iBeacon by presence of a specific data structure, so the app
probably wants the unparsed data parameter and doesn't care so much
about the object path.
But looking for heart rate monitors might be:
<- Search( { UUID: "180D" }, agent_object_path )
-> DeviceFound( device_object_path, data )
-> DeviceFound( device_object_path, data )
-> DeviceFound( device_object_path, data )
In which case the application probably just wants the device object path.
If this is broadly along the lines you're thinking, I'll draft a doc
to begin discussion.
Scott
--=20
Have you ever, ever felt like this?
Had strange things happen? Are you going round the twist?
Hi Scott,
>>> This patch proposes an extension to the D-Bus Device API to allow
>>> an application access to the last EIR data received from a device
>>> in inquiry or advertising mode.
>>>
>> in general I have no objections in exposing the EIR and AD information. However I do not like to use EIR as property key. I know that on mgmt API we simply went with EIR_Data, but on the D-Bus API we most likely need to find a name that is a bit more generic and allows to represent EIR and AD information.
>>
>
> I did indeed just copy the mgmt API terminology here, since it's
> obviously _also_ not just the AD report but also the SR report as well
> since they're concatenated in the kernel during active scanning.
maybe something generic like InformationData. Honestly I do not know yet. I do however have bad feeling with calling it just EIR.
>> One important thing we have to consider are dual-mode devices that are found via LE and BR/EDR. With dual-mode topology from Bluetooth 4.1 this will become a real possibility and we want them to show under one object path. I think we need to brainstorm a little on how this can be done best.
>>
>
> The other interesting issue for 4.1 dual-mode topology, which turns
> out to be somewhat related, is that if there's only one object path
> for a BR/EDR/LE dual-mode device, which bearer is connected when the
> application calls org.bluez.Device1.Connect ?
Simple answer without overthinking it is both.
> At least the ConnectToProfile call makes that explicit since there's a
> Profile object, but even then, if the device supports LE L2CAP
> Connection Oriented Channels, do you want that profile connected over
> the BR/EDR or LE bearer if the device supports both?
We do not have services that will expose L2CAP Connection Oriented channels on both BR/EDR and LE and use the same UUID. The classic BR/EDR profiles will not be mapped over LE at this moment.
> But that method isn't used for establishing the GATT connection on the
> LE bearer. (And then you have the whole GATT over BR/EDR thing to
> worry about too).
The database is suppose to be the same. And honestly with dual-mode topology, the GATT over BR/EDR is essentially pointless. You will be just doing it over LE which is way simpler.
> (I also don't remember reading any limitation that a BR/EDR/LE device
> _must_ use its Public address during LE Advertisement, but you'd know
> better than me on that. Would there be a case where we see advertising
> from a device, that on pairing/connection turns out to be, via
> receiving IRK, a BR/EDR device we already knew about, and thus we'd
> have to deal with device objects merging?)
There is no requirement to use your public address in advertising. You can always use random private address.
And public address on BR/EDR and RPA on LE can be the case. The iPhone being the prime example here. And we already merge the objects together as good as we can. Johan can explain this since I have to admit I spaced out when he told me on how he did it. Or I just imagined it, which is possible ;)
If you have seen my proposal for Privacy mode 0x02, then I think that we are going for using public address when we are discoverable and RPA when non-discoverable. That allows us to avoid trackability in the most cases and still allow for a smoother operation during pairing.
Regards
Marcel
On Fri, Jun 27, 2014 at 12:55 PM, Marcel Holtmann <[email protected]> wro=
te:
>> This patch proposes an extension to the D-Bus Device API to allow
>> an application access to the last EIR data received from a device
>> in inquiry or advertising mode.
>>
> in general I have no objections in exposing the EIR and AD information. H=
owever I do not like to use EIR as property key. I know that on mgmt API we=
simply went with EIR_Data, but on the D-Bus API we most likely need to fin=
d a name that is a bit more generic and allows to represent EIR and AD info=
rmation.
>
I did indeed just copy the mgmt API terminology here, since it's
obviously _also_ not just the AD report but also the SR report as well
since they're concatenated in the kernel during active scanning.
> One important thing we have to consider are dual-mode devices that are fo=
und via LE and BR/EDR. With dual-mode topology from Bluetooth 4.1 this will=
become a real possibility and we want them to show under one object path. =
I think we need to brainstorm a little on how this can be done best.
>
The other interesting issue for 4.1 dual-mode topology, which turns
out to be somewhat related, is that if there's only one object path
for a BR/EDR/LE dual-mode device, which bearer is connected when the
application calls org.bluez.Device1.Connect ?
At least the ConnectToProfile call makes that explicit since there's a
Profile object, but even then, if the device supports LE L2CAP
Connection Oriented Channels, do you want that profile connected over
the BR/EDR or LE bearer if the device supports both?
But that method isn't used for establishing the GATT connection on the
LE bearer. (And then you have the whole GATT over BR/EDR thing to
worry about too).
(I also don't remember reading any limitation that a BR/EDR/LE device
_must_ use its Public address during LE Advertisement, but you'd know
better than me on that. Would there be a case where we see advertising
from a device, that on pairing/connection turns out to be, via
receiving IRK, a BR/EDR device we already knew about, and thus we'd
have to deal with device objects merging?)
Scott
--=20
Have you ever, ever felt like this?
Had strange things happen? Are you going round the twist?
Hi Scott,
> This patch proposes an extension to the D-Bus Device API to allow
> an application access to the last EIR data received from a device
> in inquiry or advertising mode.
>
> Rationale is that increasing numbers of LE profiles are using custom
> fields in the advertising and scan response reports to carry important
> information. e.g. the Anki Drive peripherals include necessary
> information in the advertiesment that is not replicated in the GATT
> Service they export.
>
> It would be nice if it were possible to support these profiles at the
> application layer without extending BlueZ every time via a plugin.
>
> Since EIR has a variable-length type field, more complex parsing
> would require applications registering the types with BlueZ in advance
> putting a higher complexity burden on the daemon, including resolving
> conflicts where types overlap. Exposing the raw EIR data to the
> application allows them to deal with all such problems in whatever
> manner they require.
> ---
> doc/device-api.txt | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/doc/device-api.txt b/doc/device-api.txt
> index 577ee60..9620ec0 100644
> --- a/doc/device-api.txt
> +++ b/doc/device-api.txt
> @@ -193,3 +193,8 @@ Properties string Address [readonly]
>
> Received Signal Strength Indicator of the remote
> device (inquiry or advertising).
> +
> + array{byte} EIR [readonly, optional]
> +
> + Last received EIR data from the remote device
> + during inquiry or advertising.
in general I have no objections in exposing the EIR and AD information. However I do not like to use EIR as property key. I know that on mgmt API we simply went with EIR_Data, but on the D-Bus API we most likely need to find a name that is a bit more generic and allows to represent EIR and AD information.
One important thing we have to consider are dual-mode devices that are found via LE and BR/EDR. With dual-mode topology from Bluetooth 4.1 this will become a real possibility and we want them to show under one object path. I think we need to brainstorm a little on how this can be done best.
Regards
Marcel
Hi Scott,
>>> The main missing SIG defined fields which don't have properties would be:
>>>
>>> - TX Power (CSSv4 1.5)
>>
>> we should do the proper math here and provide Pathloss when discovered (again, similar disappearance to RSSI).
>>
>
> We'd still need the RSSI property because certain existing peripherals
> are placing the TX Power in the manufacturer data, which means the app
> would have to calculate path loss itself.
the idea was not to remove RSSI property. The idea was to add Pathloss property additionally instead of just adding TX Power property.
> Is there a circumstance in which additional manuf data could make the
> path loss calculation more accurate?
No. The reason why iBeacons have them in the manufacturer data is that there is no space for the TX Power element.
>>> - URL (https://www.bluetooth.org/DocMan/handlers/DownloadDoc.ashx?doc_id=287247)
>>
>> Is that one new? Could be. That seems to be dead simple and can really just get its own property.
>>
>
> Yeah, some guys here are working on a prototype and sticking URLs in
> the name field ... Robin Heydon saw it and decided that was useful
> enough to declare a standard field for it.
>
> Still at NWP, I don't think the CSWG has proposed assigned numbers
> changes yet, but worth keeping an eye on.
Becomes tricky size wise, but once it is official, we can easily support that one.
Regards
Marcel
On Tue, Jul 1, 2014 at 9:14 AM, Marcel Holtmann <[email protected]> wrote:
>> The main missing SIG defined fields which don't have properties would be:
>>
>> - TX Power (CSSv4 1.5)
>
> we should do the proper math here and provide Pathloss when discovered (again, similar disappearance to RSSI).
>
We'd still need the RSSI property because certain existing peripherals
are placing the TX Power in the manufacturer data, which means the app
would have to calculate path loss itself.
Is there a circumstance in which additional manuf data could make the
path loss calculation more accurate?
>> - URL (https://www.bluetooth.org/DocMan/handlers/DownloadDoc.ashx?doc_id=287247)
>
> Is that one new? Could be. That seems to be dead simple and can really just get its own property.
>
Yeah, some guys here are working on a prototype and sticking URLs in
the name field ... Robin Heydon saw it and decided that was useful
enough to declare a standard field for it.
Still at NWP, I don't think the CSWG has proposed assigned numbers
changes yet, but worth keeping an eye on.
Scott
--
Have you ever, ever felt like this?
Had strange things happen? Are you going round the twist?
Hi Scott,
>>>> This would place the EIR/AD/SR data in the device objects as a property then?
>>>
>>> we could do that, but I would like to discuss this a bit more. For example we might not duplicate the information that we have properties for. For example device name or appearance.
>>
>> coming to think about it, we might should just focus on the manufacturer specific field and make sure that gets exposed over D-Bus. The other ones are Bluetooth SIG defined and we can define good properties for it.
>>
>
> The main missing SIG defined fields which don't have properties would be:
>
> - TX Power (CSSv4 1.5)
we should do the proper math here and provide Pathloss when discovered (again, similar disappearance to RSSI).
> - URL (https://www.bluetooth.org/DocMan/handlers/DownloadDoc.ashx?doc_id=287247)
Is that one new? Could be. That seems to be dead simple and can really just get its own property.
> All of the others are reasonably internal to BlueZ and not of interest
> to applications.
Examples would be Service Solicitation as mentioned before. However there bluetoothd should just combine all fields into a single array with UUID-128.
>> We could add a property with array{uint16,array{byte}} that allows us to provide all the manufacturer information we find. On BR/EDR they are pretty static and would just stay around. On LE they would be removed (same as RSSI) once the result becomes invalid. For dual-mode devices found on both transports we just combine them.
>>
>
> If multiple fields of manufacturer data for the same manufacturer are
> found, we'd just duplicate them in the array? e.g.
>
> [
> ( 004C, [ 01, 08, ... ] ),
> ( 004C, [ 02, 15, ... ] )
> ]
>
> For a fruit-flavored device acting as both an Airdrop target and an
> iBeacon (this seems to be how they show up - but could be a side
> effect of one field being in AD and one in SR)
That is what I am thinking is the safest. Same as on BR/EDR they will give you the product name so you can pick the right icon. I also think that for manufacturer specific entries it is explicitly allowed to show up more than once.
Regards
Marcel
On Tue, Jul 1, 2014 at 8:58 AM, Marcel Holtmann <[email protected]> wrote=
:
>>> This would place the EIR/AD/SR data in the device objects as a property=
then?
>>
>> we could do that, but I would like to discuss this a bit more. For examp=
le we might not duplicate the information that we have properties for. For =
example device name or appearance.
>
> coming to think about it, we might should just focus on the manufacturer =
specific field and make sure that gets exposed over D-Bus. The other ones a=
re Bluetooth SIG defined and we can define good properties for it.
>
The main missing SIG defined fields which don't have properties would be:
- TX Power (CSSv4 1.5)
- URL (https://www.bluetooth.org/DocMan/handlers/DownloadDoc.ashx?doc_id=
=3D287247)
All of the others are reasonably internal to BlueZ and not of interest
to applications.
> We could add a property with array{uint16,array{byte}} that allows us to =
provide all the manufacturer information we find. On BR/EDR they are pretty=
static and would just stay around. On LE they would be removed (same as RS=
SI) once the result becomes invalid. For dual-mode devices found on both tr=
ansports we just combine them.
>
If multiple fields of manufacturer data for the same manufacturer are
found, we'd just duplicate them in the array? e.g.
[
( 004C, [ 01, 08, ... ] ),
( 004C, [ 02, 15, ... ] )
]
For a fruit-flavored device acting as both an Airdrop target and an
iBeacon (this seems to be how they show up - but could be a side
effect of one field being in AD and one in SR)
Scott
--=20
Have you ever, ever felt like this?
Had strange things happen? Are you going round the twist?
Hi Scott,
>>>>>> This patch proposes an extension to the D-Bus Device API to allow
>>>>>> an application access to the last EIR data received from a device
>>>>>> in inquiry or advertising mode.
>>>>>>
>>>
>>> I think this looks pretty along the lines what I am looking for. However I was thinking in a bit more detail likes this:
>>>
>>> <- Search method call
>>> -> New Device object / Updated device object
>>> -> New Device object / Updated device object
>>> -> Search method return -> array of objects with properties
>>>
>>> So you can treat the search dead simple and just display the results. However that way you can not monitor progress. If you want to monitor progress while search is running, you need to monitor changes to the device objects.
>>>
>>
>> Sounds reasonable, would make it very easy from an application point of view.
>>
>> This would place the EIR/AD/SR data in the device objects as a property then?
>
> we could do that, but I would like to discuss this a bit more. For example we might not duplicate the information that we have properties for. For example device name or appearance.
coming to think about it, we might should just focus on the manufacturer specific field and make sure that gets exposed over D-Bus. The other ones are Bluetooth SIG defined and we can define good properties for it.
We could add a property with array{uint16,array{byte}} that allows us to provide all the manufacturer information we find. On BR/EDR they are pretty static and would just stay around. On LE they would be removed (same as RSSI) once the result becomes invalid. For dual-mode devices found on both transports we just combine them.
Regards
Marcel
Hi Scott,
>>>>> This patch proposes an extension to the D-Bus Device API to allow
>>>>> an application access to the last EIR data received from a device
>>>>> in inquiry or advertising mode.
>>>>>
>>
>> I think this looks pretty along the lines what I am looking for. However I was thinking in a bit more detail likes this:
>>
>> <- Search method call
>> -> New Device object / Updated device object
>> -> New Device object / Updated device object
>> -> Search method return -> array of objects with properties
>>
>> So you can treat the search dead simple and just display the results. However that way you can not monitor progress. If you want to monitor progress while search is running, you need to monitor changes to the device objects.
>>
>
> Sounds reasonable, would make it very easy from an application point of view.
>
> This would place the EIR/AD/SR data in the device objects as a property then?
we could do that, but I would like to discuss this a bit more. For example we might not duplicate the information that we have properties for. For example device name or appearance.
The information would also become invalid once the discovery gets aborted. Similar to the RSSI value where we actually declare the property invalid once discovery is over.
I think we have to see how this works out. We might need a prototype implementation to play with it a little bit.
Regards
Marcel
On Tue, Jul 1, 2014 at 3:42 AM, Marcel Holtmann <[email protected]> wrote:
>>>> This patch proposes an extension to the D-Bus Device API to allow
>>>> an application access to the last EIR data received from a device
>>>> in inquiry or advertising mode.
>>>>
>
> I think this looks pretty along the lines what I am looking for. However I was thinking in a bit more detail likes this:
>
> <- Search method call
> -> New Device object / Updated device object
> -> New Device object / Updated device object
> -> Search method return -> array of objects with properties
>
> So you can treat the search dead simple and just display the results. However that way you can not monitor progress. If you want to monitor progress while search is running, you need to monitor changes to the device objects.
>
Sounds reasonable, would make it very easy from an application point of view.
This would place the EIR/AD/SR data in the device objects as a property then?
Scott
--
Have you ever, ever felt like this?
Had strange things happen? Are you going round the twist?
Hi Scott,
>>> This patch proposes an extension to the D-Bus Device API to allow
>>> an application access to the last EIR data received from a device
>>> in inquiry or advertising mode.
>>>
>> in general I have no objections in exposing the EIR and AD information. However I do not like to use EIR as property key. I know that on mgmt API we simply went with EIR_Data, but on the D-Bus API we most likely need to find a name that is a bit more generic and allows to represent EIR and AD information.
>>
>
> Thinking about this a little bit more, I'm not sure this should be a
> Device property either. The advertisement data isn't really a property
> of the device, but a property of the advertisement itself.
>
> A peripheral could theoretically send different advertisements, a
> weird example might be a peripheral sending a non-connectable
> undirected advertisement generally, and a connectable directed
> advertisement to us directly, with different AD.
that is indeed possible. They can also interleave them with one time targeting a different central.
Keep in mind that there is also something called service solicitation. Meaning a peripheral start indicated that it want a device with service UUID x to find us. iOS is for example using that to filter for the Notification Center stuff.
> This seems to fold back nicely into the discussion about a "Find
> Devices" API, intended for applications and separate from the
> StartDiscovery API. If that were an "agent" mode, it could look
> something like this:
>
> <- Search( { Data: "FF4C000214" }, agent_object_path )
> -> DeviceFound( device_object_path, data )
> -> DeviceFound( device_object_path, data )
> -> DeviceFound( device_object_path, data )
>
> Where data in the agent method is the unparsed advertisement data, if
> the application is interested in it. The above example is looking for
> an iBeacon by presence of a specific data structure, so the app
> probably wants the unparsed data parameter and doesn't care so much
> about the object path.
>
> But looking for heart rate monitors might be:
>
> <- Search( { UUID: "180D" }, agent_object_path )
> -> DeviceFound( device_object_path, data )
> -> DeviceFound( device_object_path, data )
> -> DeviceFound( device_object_path, data )
>
> In which case the application probably just wants the device object path.
>
>
> If this is broadly along the lines you're thinking, I'll draft a doc
> to begin discussion.
I think this looks pretty along the lines what I am looking for. However I was thinking in a bit more detail likes this:
<- Search method call
-> New Device object / Updated device object
-> New Device object / Updated device object
-> Search method return -> array of objects with properties
So you can treat the search dead simple and just display the results. However that way you can not monitor progress. If you want to monitor progress while search is running, you need to monitor changes to the device objects.
Regards
Marcel