I have a bluetooth beacon device that advertises a name depending on
its configuration (connectable or not).
Sadly, in Bluez, the first time it sees it while advertising its name,
it caches it which is nice for future discovery.
Except it doesn't because I don't want to see this name while it
advertises in non-connectable state as it is "not" the same device
anymore (sort of).
I guess what I'm asking is if we can make Device name aware of the
connectable state and only use it if it matches state when it was
cached.
See some btmon trace of what it looks like in both configurations:
> HCI Event: LE Meta Event (0x3e) plen 42 [hci0] 5.600723
LE Advertising Report (0x02)
Num reports: 1
Event type: Non connectable undirected - ADV_NONCONN_IND (0x03)
Address type: Random (0x01)
Address: D0:65:68:C3:6E:88 (Static)
Data length: 30
Flags: 0x06
LE General Discoverable Mode
BR/EDR Not Supported
16-bit Service UUIDs (complete): 1 entry
Google (0xfeaa)
Service Data (UUID 0xfeaa): 10de0263662e706879736963616c2d77656208
RSSI: -80 dBm (0xb0)
@ Device Found: D0:65:68:C3:6E:88 (2) rssi -80 flags 0x0004
02 01 06 03 03 aa fe 16 16 aa fe 10 de 02 63 66 ..............cf
2e 70 68 79 73 69 63 61 6c 2d 77 65 62 08 .physical-web.
> HCI Event: LE Meta Event (0x3e) plen 37 [hci0] 114.202975
LE Advertising Report (0x02)
Num reports: 1
Event type: Connectable undirected - ADV_IND (0x00)
Address type: Random (0x01)
Address: D0:65:68:C3:6E:88 (Static)
Data length: 25
Flags: 0x06
LE General Discoverable Mode
BR/EDR Not Supported
128-bit Service UUIDs (complete): 1 entry
a3c87500-8ed3-4bdf-8a39-a01bebede295
Appearance: Tag (0x0200)
RSSI: -63 dBm (0xc1)
> HCI Event: LE Meta Event (0x3e) plen 38 [hci0] 114.205892
LE Advertising Report (0x02)
Num reports: 1
Event type: Scan response - SCAN_RSP (0x04)
Address type: Random (0x01)
Address: D0:65:68:C3:6E:88 (Static)
Data length: 26
Name (complete): Eddystone Config:beta
TX power: -18 dBm
RSSI: -61 dBm (0xc3)
@ Device Found: D0:65:68:C3:6E:88 (2) rssi -61 flags 0x0000
02 01 06 11 07 95 e2 ed eb 1b a0 39 8a df 4b d3 ...........9..K.
8e 00 75 c8 a3 03 19 00 02 16 09 45 64 64 79 73 ..u........Eddys
74 6f 6e 65 20 43 6f 6e 66 69 67 3a 62 65 74 61 tone Config:beta
02 0a ee ...
Thank your Marcel for the clarification.
As Luiz mentioned previously though, as random static addresses can be
used by other devices, it may makes sense to avoid caching their name.
Would you agree?
On Thu, Jun 23, 2016 at 3:29 PM, Marcel Holtmann <[email protected]> wrot=
e:
> Hi Francois,
>
>> I have a bluetooth beacon device that advertises a name depending on
>> its configuration (connectable or not).
>> Sadly, in Bluez, the first time it sees it while advertising its name,
>> it caches it which is nice for future discovery.
>> Except it doesn't because I don't want to see this name while it
>> advertises in non-connectable state as it is "not" the same device
>> anymore (sort of).
>> I guess what I'm asking is if we can make Device name aware of the
>> connectable state and only use it if it matches state when it was
>> cached.
>
> yikes, this is super tricky. If the device uses the same address, then it=
is the same device. If it is not the same device, then it should use two d=
ifferent addresses (sort of a dual personality).
>
> Please keep in mind that a lot of device identity is based around either =
the public address or the static random address. We even clarified that as =
identity address in the latest specification. The mode has nothing to do wi=
th it. It makes it even more complicated since a device can be in broadcast=
er and peripheral role at the same time. It is just a matter of instantiati=
ng a second link layer state machine. However even in that case my advise i=
s two use two different addresses if they are independent.
>
> Regards
>
> Marcel
>
Thank your Marcel for the clarification.
As Luiz mentioned previously though, as random static addresses can be used
by other devices, it may makes sense to avoid caching their name. Would you
agree?
On Thu, Jun 23, 2016 at 3:29 PM Marcel Holtmann <[email protected]> wrote:
> Hi Francois,
>
> > I have a bluetooth beacon device that advertises a name depending on
> > its configuration (connectable or not).
> > Sadly, in Bluez, the first time it sees it while advertising its name,
> > it caches it which is nice for future discovery.
> > Except it doesn't because I don't want to see this name while it
> > advertises in non-connectable state as it is "not" the same device
> > anymore (sort of).
> > I guess what I'm asking is if we can make Device name aware of the
> > connectable state and only use it if it matches state when it was
> > cached.
>
> yikes, this is super tricky. If the device uses the same address, then it
> is the same device. If it is not the same device, then it should use two
> different addresses (sort of a dual personality).
>
> Please keep in mind that a lot of device identity is based around either
> the public address or the static random address. We even clarified that as
> identity address in the latest specification. The mode has nothing to do
> with it. It makes it even more complicated since a device can be in
> broadcaster and peripheral role at the same time. It is just a matter of
> instantiating a second link layer state machine. However even in that case
> my advise is two use two different addresses if they are independent.
>
> Regards
>
> Marcel
>
>
Hi Francois,
> I have a bluetooth beacon device that advertises a name depending on
> its configuration (connectable or not).
> Sadly, in Bluez, the first time it sees it while advertising its name,
> it caches it which is nice for future discovery.
> Except it doesn't because I don't want to see this name while it
> advertises in non-connectable state as it is "not" the same device
> anymore (sort of).
> I guess what I'm asking is if we can make Device name aware of the
> connectable state and only use it if it matches state when it was
> cached.
yikes, this is super tricky. If the device uses the same address, then it is the same device. If it is not the same device, then it should use two different addresses (sort of a dual personality).
Please keep in mind that a lot of device identity is based around either the public address or the static random address. We even clarified that as identity address in the latest specification. The mode has nothing to do with it. It makes it even more complicated since a device can be in broadcaster and peripheral role at the same time. It is just a matter of instantiating a second link layer state machine. However even in that case my advise is two use two different addresses if they are independent.
Regards
Marcel
Here's what says BLUETOOTH SPECIFICATION Version 4.2 [Vol 3, Part C],
The advertising data shall be formatted using the Advertising Data (AD) type
format as defined in [[Core Specification Supplement], Part A, Section 1.3. A
device in the broadcast mode shall not set the ‘LE General Discoverable Mode’
flag or the ‘LE Limited Discoverable Mode’ flag in the Flags AD Type as defined
in [Core Specification Supplement], Part A, Section 1.3.
This seems clear to me that discoverable flag shall not be used in
broadcaster mode.
Which improvements would you make to the CSS?
On Thu, Jun 23, 2016 at 12:10 PM, Luiz Augusto von Dentz
<[email protected]> wrote:
> Hi François,
>
> On Thu, Jun 23, 2016 at 12:27 PM, François Beaufort
> <[email protected]> wrote:
>> On Wed, Jun 22, 2016 at 6:35 PM, Luiz Augusto von Dentz
>> <[email protected]> wrote:
>>> Hi François,
>>>
>>> On Wed, Jun 22, 2016 at 2:10 PM, François Beaufort
>>> <[email protected]> wrote:
>>>> I have a bluetooth beacon device that advertises a name depending on
>>>> its configuration (connectable or not).
>>>> Sadly, in Bluez, the first time it sees it while advertising its name,
>>>> it caches it which is nice for future discovery.
>>>> Except it doesn't because I don't want to see this name while it
>>>> advertises in non-connectable state as it is "not" the same device
>>>> anymore (sort of).
>>>> I guess what I'm asking is if we can make Device name aware of the
>>>> connectable state and only use it if it matches state when it was
>>>> cached.
>>>
>>> Not sure I understand the problem correctly but in case the device
>>> changes for one reason or the other it shall change its identity
>>> address, so the device is at fault here as it doesn't change its
>>> address, what it should have happened is that it uses one random
>>> static for beacon mode and another for connectable mode or even better
>>> use rpa for connectable mode so it can be associate properly.
>>>
>>> That said I guess we could deal a little bit better in regarding of
>>> random static addresses, since they can be used by other devices
>>> caching their name may not be a good idea so we should probably take a
>>> similar approach as to other device settings that are not stored for
>>> random address.
>>>
>>
>> Which part of BlueZ code should I have a look at if I want to
>> contribute back to implement this feature?
>>
>>>> See some btmon trace of what it looks like in both configurations:
>>>>
>>>>> HCI Event: LE Meta Event (0x3e) plen 42 [hci0] 5.600723
>>>> LE Advertising Report (0x02)
>>>> Num reports: 1
>>>> Event type: Non connectable undirected - ADV_NONCONN_IND (0x03)
>>>> Address type: Random (0x01)
>>>> Address: D0:65:68:C3:6E:88 (Static)
>>>> Data length: 30
>>>> Flags: 0x06
>>>> LE General Discoverable Mode
>>>
>>> Btw, the only reason you are seeing this beacon is because it is
>>> marked as discoverable which iirc is wrong since this flag only apply
>>> for connectable peripherals, without this it won't show on regular
>>> discovery, to make beacons visible Im proposing to include them only
>>> if the application has set a filter so we don't clutter regular device
>>> creation dialogs with beacons that cannot be paired.
>>>
>>
>> I'll see if I can update firmware to NOT use "LE General Discoverable
>> Mode" flag there as you're right, it shouldn't be set according to the
>> Bluetooth Spec for a device that simply broadcasts.
>
> Maybe it is a good idea to file an issue to the CSS to mention that
> discoverable flag shall not be used in broadcaster mode, or to clarify
> that on the specification if that was not the intention. This has
> caused already some confusion before and Im afraid it will continue if
> we don't do something about it.
>
>>
>>>> BR/EDR Not Supported
>>>> 16-bit Service UUIDs (complete): 1 entry
>>>> Google (0xfeaa)
>>>> Service Data (UUID 0xfeaa): 10de0263662e706879736963616c2d77656208
>>>> RSSI: -80 dBm (0xb0)
>>>> @ Device Found: D0:65:68:C3:6E:88 (2) rssi -80 flags 0x0004
>>>> 02 01 06 03 03 aa fe 16 16 aa fe 10 de 02 63 66 ..............cf
>>>>
>>>> 2e 70 68 79 73 69 63 61 6c 2d 77 65 62 08 .physical-web.
>>>>
>>>>
>>>>
>>>>> HCI Event: LE Meta Event (0x3e) plen 37 [hci0] 114.202975
>>>> LE Advertising Report (0x02)
>>>> Num reports: 1
>>>> Event type: Connectable undirected - ADV_IND (0x00)
>>>> Address type: Random (0x01)
>>>> Address: D0:65:68:C3:6E:88 (Static)
>>>> Data length: 25
>>>> Flags: 0x06
>>>> LE General Discoverable Mode
>>>> BR/EDR Not Supported
>>>> 128-bit Service UUIDs (complete): 1 entry
>>>> a3c87500-8ed3-4bdf-8a39-a01bebede295
>>>> Appearance: Tag (0x0200)
>>>> RSSI: -63 dBm (0xc1)
>>>>> HCI Event: LE Meta Event (0x3e) plen 38 [hci0] 114.205892
>>>> LE Advertising Report (0x02)
>>>> Num reports: 1
>>>> Event type: Scan response - SCAN_RSP (0x04)
>>>> Address type: Random (0x01)
>>>> Address: D0:65:68:C3:6E:88 (Static)
>>>> Data length: 26
>>>> Name (complete): Eddystone Config:beta
>>>> TX power: -18 dBm
>>>> RSSI: -61 dBm (0xc3)
>>>> @ Device Found: D0:65:68:C3:6E:88 (2) rssi -61 flags 0x0000
>>>> 02 01 06 11 07 95 e2 ed eb 1b a0 39 8a df 4b d3 ...........9..K.
>>>> 8e 00 75 c8 a3 03 19 00 02 16 09 45 64 64 79 73 ..u........Eddys
>>>> 74 6f 6e 65 20 43 6f 6e 66 69 67 3a 62 65 74 61 tone Config:beta
>>>> 02 0a ee ...
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
>>>> the body of a message to [email protected]
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>
>>>
>>>
>>> --
>>> Luiz Augusto von Dentz
>
>
>
> --
> Luiz Augusto von Dentz
Hi François,
On Thu, Jun 23, 2016 at 12:27 PM, François Beaufort
<[email protected]> wrote:
> On Wed, Jun 22, 2016 at 6:35 PM, Luiz Augusto von Dentz
> <[email protected]> wrote:
>> Hi François,
>>
>> On Wed, Jun 22, 2016 at 2:10 PM, François Beaufort
>> <[email protected]> wrote:
>>> I have a bluetooth beacon device that advertises a name depending on
>>> its configuration (connectable or not).
>>> Sadly, in Bluez, the first time it sees it while advertising its name,
>>> it caches it which is nice for future discovery.
>>> Except it doesn't because I don't want to see this name while it
>>> advertises in non-connectable state as it is "not" the same device
>>> anymore (sort of).
>>> I guess what I'm asking is if we can make Device name aware of the
>>> connectable state and only use it if it matches state when it was
>>> cached.
>>
>> Not sure I understand the problem correctly but in case the device
>> changes for one reason or the other it shall change its identity
>> address, so the device is at fault here as it doesn't change its
>> address, what it should have happened is that it uses one random
>> static for beacon mode and another for connectable mode or even better
>> use rpa for connectable mode so it can be associate properly.
>>
>> That said I guess we could deal a little bit better in regarding of
>> random static addresses, since they can be used by other devices
>> caching their name may not be a good idea so we should probably take a
>> similar approach as to other device settings that are not stored for
>> random address.
>>
>
> Which part of BlueZ code should I have a look at if I want to
> contribute back to implement this feature?
>
>>> See some btmon trace of what it looks like in both configurations:
>>>
>>>> HCI Event: LE Meta Event (0x3e) plen 42 [hci0] 5.600723
>>> LE Advertising Report (0x02)
>>> Num reports: 1
>>> Event type: Non connectable undirected - ADV_NONCONN_IND (0x03)
>>> Address type: Random (0x01)
>>> Address: D0:65:68:C3:6E:88 (Static)
>>> Data length: 30
>>> Flags: 0x06
>>> LE General Discoverable Mode
>>
>> Btw, the only reason you are seeing this beacon is because it is
>> marked as discoverable which iirc is wrong since this flag only apply
>> for connectable peripherals, without this it won't show on regular
>> discovery, to make beacons visible Im proposing to include them only
>> if the application has set a filter so we don't clutter regular device
>> creation dialogs with beacons that cannot be paired.
>>
>
> I'll see if I can update firmware to NOT use "LE General Discoverable
> Mode" flag there as you're right, it shouldn't be set according to the
> Bluetooth Spec for a device that simply broadcasts.
Maybe it is a good idea to file an issue to the CSS to mention that
discoverable flag shall not be used in broadcaster mode, or to clarify
that on the specification if that was not the intention. This has
caused already some confusion before and Im afraid it will continue if
we don't do something about it.
>
>>> BR/EDR Not Supported
>>> 16-bit Service UUIDs (complete): 1 entry
>>> Google (0xfeaa)
>>> Service Data (UUID 0xfeaa): 10de0263662e706879736963616c2d77656208
>>> RSSI: -80 dBm (0xb0)
>>> @ Device Found: D0:65:68:C3:6E:88 (2) rssi -80 flags 0x0004
>>> 02 01 06 03 03 aa fe 16 16 aa fe 10 de 02 63 66 ..............cf
>>>
>>> 2e 70 68 79 73 69 63 61 6c 2d 77 65 62 08 .physical-web.
>>>
>>>
>>>
>>>> HCI Event: LE Meta Event (0x3e) plen 37 [hci0] 114.202975
>>> LE Advertising Report (0x02)
>>> Num reports: 1
>>> Event type: Connectable undirected - ADV_IND (0x00)
>>> Address type: Random (0x01)
>>> Address: D0:65:68:C3:6E:88 (Static)
>>> Data length: 25
>>> Flags: 0x06
>>> LE General Discoverable Mode
>>> BR/EDR Not Supported
>>> 128-bit Service UUIDs (complete): 1 entry
>>> a3c87500-8ed3-4bdf-8a39-a01bebede295
>>> Appearance: Tag (0x0200)
>>> RSSI: -63 dBm (0xc1)
>>>> HCI Event: LE Meta Event (0x3e) plen 38 [hci0] 114.205892
>>> LE Advertising Report (0x02)
>>> Num reports: 1
>>> Event type: Scan response - SCAN_RSP (0x04)
>>> Address type: Random (0x01)
>>> Address: D0:65:68:C3:6E:88 (Static)
>>> Data length: 26
>>> Name (complete): Eddystone Config:beta
>>> TX power: -18 dBm
>>> RSSI: -61 dBm (0xc3)
>>> @ Device Found: D0:65:68:C3:6E:88 (2) rssi -61 flags 0x0000
>>> 02 01 06 11 07 95 e2 ed eb 1b a0 39 8a df 4b d3 ...........9..K.
>>> 8e 00 75 c8 a3 03 19 00 02 16 09 45 64 64 79 73 ..u........Eddys
>>> 74 6f 6e 65 20 43 6f 6e 66 69 67 3a 62 65 74 61 tone Config:beta
>>> 02 0a ee ...
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
>>> the body of a message to [email protected]
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>>
>>
>> --
>> Luiz Augusto von Dentz
--
Luiz Augusto von Dentz
On Wed, Jun 22, 2016 at 6:35 PM, Luiz Augusto von Dentz
<[email protected]> wrote:
> Hi François,
>
> On Wed, Jun 22, 2016 at 2:10 PM, François Beaufort
> <[email protected]> wrote:
>> I have a bluetooth beacon device that advertises a name depending on
>> its configuration (connectable or not).
>> Sadly, in Bluez, the first time it sees it while advertising its name,
>> it caches it which is nice for future discovery.
>> Except it doesn't because I don't want to see this name while it
>> advertises in non-connectable state as it is "not" the same device
>> anymore (sort of).
>> I guess what I'm asking is if we can make Device name aware of the
>> connectable state and only use it if it matches state when it was
>> cached.
>
> Not sure I understand the problem correctly but in case the device
> changes for one reason or the other it shall change its identity
> address, so the device is at fault here as it doesn't change its
> address, what it should have happened is that it uses one random
> static for beacon mode and another for connectable mode or even better
> use rpa for connectable mode so it can be associate properly.
>
> That said I guess we could deal a little bit better in regarding of
> random static addresses, since they can be used by other devices
> caching their name may not be a good idea so we should probably take a
> similar approach as to other device settings that are not stored for
> random address.
>
Which part of BlueZ code should I have a look at if I want to
contribute back to implement this feature?
>> See some btmon trace of what it looks like in both configurations:
>>
>>> HCI Event: LE Meta Event (0x3e) plen 42 [hci0] 5.600723
>> LE Advertising Report (0x02)
>> Num reports: 1
>> Event type: Non connectable undirected - ADV_NONCONN_IND (0x03)
>> Address type: Random (0x01)
>> Address: D0:65:68:C3:6E:88 (Static)
>> Data length: 30
>> Flags: 0x06
>> LE General Discoverable Mode
>
> Btw, the only reason you are seeing this beacon is because it is
> marked as discoverable which iirc is wrong since this flag only apply
> for connectable peripherals, without this it won't show on regular
> discovery, to make beacons visible Im proposing to include them only
> if the application has set a filter so we don't clutter regular device
> creation dialogs with beacons that cannot be paired.
>
I'll see if I can update firmware to NOT use "LE General Discoverable
Mode" flag there as you're right, it shouldn't be set according to the
Bluetooth Spec for a device that simply broadcasts.
>> BR/EDR Not Supported
>> 16-bit Service UUIDs (complete): 1 entry
>> Google (0xfeaa)
>> Service Data (UUID 0xfeaa): 10de0263662e706879736963616c2d77656208
>> RSSI: -80 dBm (0xb0)
>> @ Device Found: D0:65:68:C3:6E:88 (2) rssi -80 flags 0x0004
>> 02 01 06 03 03 aa fe 16 16 aa fe 10 de 02 63 66 ..............cf
>>
>> 2e 70 68 79 73 69 63 61 6c 2d 77 65 62 08 .physical-web.
>>
>>
>>
>>> HCI Event: LE Meta Event (0x3e) plen 37 [hci0] 114.202975
>> LE Advertising Report (0x02)
>> Num reports: 1
>> Event type: Connectable undirected - ADV_IND (0x00)
>> Address type: Random (0x01)
>> Address: D0:65:68:C3:6E:88 (Static)
>> Data length: 25
>> Flags: 0x06
>> LE General Discoverable Mode
>> BR/EDR Not Supported
>> 128-bit Service UUIDs (complete): 1 entry
>> a3c87500-8ed3-4bdf-8a39-a01bebede295
>> Appearance: Tag (0x0200)
>> RSSI: -63 dBm (0xc1)
>>> HCI Event: LE Meta Event (0x3e) plen 38 [hci0] 114.205892
>> LE Advertising Report (0x02)
>> Num reports: 1
>> Event type: Scan response - SCAN_RSP (0x04)
>> Address type: Random (0x01)
>> Address: D0:65:68:C3:6E:88 (Static)
>> Data length: 26
>> Name (complete): Eddystone Config:beta
>> TX power: -18 dBm
>> RSSI: -61 dBm (0xc3)
>> @ Device Found: D0:65:68:C3:6E:88 (2) rssi -61 flags 0x0000
>> 02 01 06 11 07 95 e2 ed eb 1b a0 39 8a df 4b d3 ...........9..K.
>> 8e 00 75 c8 a3 03 19 00 02 16 09 45 64 64 79 73 ..u........Eddys
>> 74 6f 6e 65 20 43 6f 6e 66 69 67 3a 62 65 74 61 tone Config:beta
>> 02 0a ee ...
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
>> the body of a message to [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
>
> --
> Luiz Augusto von Dentz
Hi François,
On Wed, Jun 22, 2016 at 2:10 PM, François Beaufort
<[email protected]> wrote:
> I have a bluetooth beacon device that advertises a name depending on
> its configuration (connectable or not).
> Sadly, in Bluez, the first time it sees it while advertising its name,
> it caches it which is nice for future discovery.
> Except it doesn't because I don't want to see this name while it
> advertises in non-connectable state as it is "not" the same device
> anymore (sort of).
> I guess what I'm asking is if we can make Device name aware of the
> connectable state and only use it if it matches state when it was
> cached.
Not sure I understand the problem correctly but in case the device
changes for one reason or the other it shall change its identity
address, so the device is at fault here as it doesn't change its
address, what it should have happened is that it uses one random
static for beacon mode and another for connectable mode or even better
use rpa for connectable mode so it can be associate properly.
That said I guess we could deal a little bit better in regarding of
random static addresses, since they can be used by other devices
caching their name may not be a good idea so we should probably take a
similar approach as to other device settings that are not stored for
random address.
> See some btmon trace of what it looks like in both configurations:
>
>> HCI Event: LE Meta Event (0x3e) plen 42 [hci0] 5.600723
> LE Advertising Report (0x02)
> Num reports: 1
> Event type: Non connectable undirected - ADV_NONCONN_IND (0x03)
> Address type: Random (0x01)
> Address: D0:65:68:C3:6E:88 (Static)
> Data length: 30
> Flags: 0x06
> LE General Discoverable Mode
Btw, the only reason you are seeing this beacon is because it is
marked as discoverable which iirc is wrong since this flag only apply
for connectable peripherals, without this it won't show on regular
discovery, to make beacons visible Im proposing to include them only
if the application has set a filter so we don't clutter regular device
creation dialogs with beacons that cannot be paired.
> BR/EDR Not Supported
> 16-bit Service UUIDs (complete): 1 entry
> Google (0xfeaa)
> Service Data (UUID 0xfeaa): 10de0263662e706879736963616c2d77656208
> RSSI: -80 dBm (0xb0)
> @ Device Found: D0:65:68:C3:6E:88 (2) rssi -80 flags 0x0004
> 02 01 06 03 03 aa fe 16 16 aa fe 10 de 02 63 66 ..............cf
>
> 2e 70 68 79 73 69 63 61 6c 2d 77 65 62 08 .physical-web.
>
>
>
>> HCI Event: LE Meta Event (0x3e) plen 37 [hci0] 114.202975
> LE Advertising Report (0x02)
> Num reports: 1
> Event type: Connectable undirected - ADV_IND (0x00)
> Address type: Random (0x01)
> Address: D0:65:68:C3:6E:88 (Static)
> Data length: 25
> Flags: 0x06
> LE General Discoverable Mode
> BR/EDR Not Supported
> 128-bit Service UUIDs (complete): 1 entry
> a3c87500-8ed3-4bdf-8a39-a01bebede295
> Appearance: Tag (0x0200)
> RSSI: -63 dBm (0xc1)
>> HCI Event: LE Meta Event (0x3e) plen 38 [hci0] 114.205892
> LE Advertising Report (0x02)
> Num reports: 1
> Event type: Scan response - SCAN_RSP (0x04)
> Address type: Random (0x01)
> Address: D0:65:68:C3:6E:88 (Static)
> Data length: 26
> Name (complete): Eddystone Config:beta
> TX power: -18 dBm
> RSSI: -61 dBm (0xc3)
> @ Device Found: D0:65:68:C3:6E:88 (2) rssi -61 flags 0x0000
> 02 01 06 11 07 95 e2 ed eb 1b a0 39 8a df 4b d3 ...........9..K.
> 8e 00 75 c8 a3 03 19 00 02 16 09 45 64 64 79 73 ..u........Eddys
> 74 6f 6e 65 20 43 6f 6e 66 69 67 3a 62 65 74 61 tone Config:beta
> 02 0a ee ...
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Luiz Augusto von Dentz