Hi again!
I'm having a problem while comparing the BlueZ 5 and BlueZ 4 behavior
regarding the name/alias of a device during scanning.
On BlueZ 4 (at least on 4.99), there was a two steps discovery
process. During the first 10 seconds, the adapter will look for new
devices, and during the second 30 seconds, it will ask each device for
further information.
I have here devices like the Monster ClarityHD speakers, or the
Creative WP-350 headsets. Those devices announce a short name with the
Inquiry Result. btmon reveals a "HCI Event: Extended Inquiry Result"
for each one with a short name of 9 chars, respectively "Monster C"
and "Creative " (with a space at the end).
BlueZ 4 will show this name during the first 10 seconds as the name of
the device, but when the adapter goes to the second step, it will
issue a "HCI Command: Remote Name Request" and get the full name, like
"Creative WP-350 Headset" and update the property on the device, still
during discovery.
In the other hand, BlueZ 5 will not issue a "Remote Name Request"
until you attempt a pairing. This is not the best user experience
since no matter how long you leave your scan session on, you will
never get the right name of the device, until you attempt a connection
or a pairing with it.
Even worse, if you had connected to the device before (and you have
the long name in the bluez cache for example), if you scan for new
devices and this device shows up in that scan, bluez will change the
name to the short version.
I'm thinking about sending a Remote Name Request to the new devices
between the "> HCI Event: Inquiry Complete" and the "< HCI Command:
Inquiry". What do you think about this approach? Do you have a better
idea to solve this?
Thanks,
Alex.
Hi Alex,
On Mon, May 06, 2013, Alex Deymo wrote:
> I though about several options and finally choose tho consider the
> short name as an unknown name and thus calling the confirm_name() with
> known_name in FALSE, but also report the device with the short name,
> while we ask for the long name.
>
> This has the advantage of sending the device found signal earlier, but
> may have a problem in the following scenario:
> 1. We have a first call to update_found_devices() with a short name
> and report it to the user.
> 2. We request the full name.
> 3. The device doesn't reply to this request (for any reason)
> 4. We get a second call to update_found_devices() with a short name...
> but since we already know "a name" we don't request the long name.
>
> To avoid this I think the best should be to include the name_complete
> field in the struct btd_device together with the name. What do you
> think?
I'm not completely sure about this. In theory you could have a (broken
or malicious) device with page scan disabled but inquiry scan enabled
and such a device would be causing us to block all other baseband
activity while we wait for a page timeout to happen each time we request
its name. Since we anyway re-request the name when connecting this might
not be worth it.
Johan
Hi Vinicius,
On Fri, May 3, 2013 at 6:55 PM, Vinicius Gomes
<[email protected]> wrote:
> Hi Alex,
>
> I don't know if this is what you already had in mind, but I would
> start on the userspace side, src/adapter.c:4052
> (update_found_devices()), and make it send the confirm name command in
> the cases that we only have the short name. It should cause the remote
> name to be requested.
Thanks for the pointer. I managed to solve the problem of updating the
already known long name with the new short name in that function, and
after some time debugging between the kernel module and the userland
daemon I also found that the problem of the "Remote Name Request" not
being sent is because confirm_name() is called with a known_name in
TRUE since we already known "a name".
I though about several options and finally choose tho consider the
short name as an unknown name and thus calling the confirm_name() with
known_name in FALSE, but also report the device with the short name,
while we ask for the long name.
This has the advantage of sending the device found signal earlier, but
may have a problem in the following scenario:
1. We have a first call to update_found_devices() with a short name
and report it to the user.
2. We request the full name.
3. The device doesn't reply to this request (for any reason)
4. We get a second call to update_found_devices() with a short name...
but since we already know "a name" we don't request the long name.
To avoid this I think the best should be to include the name_complete
field in the struct btd_device together with the name. What do you
think?
I'm sending a proposed patch with this implementation.
Thanks!
Alex.
Hi Alex,
On Fri, May 3, 2013 at 10:14 PM, Alex Deymo <[email protected]> wrote:
> Hi again!
>
> I'm having a problem while comparing the BlueZ 5 and BlueZ 4 behavior
> regarding the name/alias of a device during scanning.
>
> On BlueZ 4 (at least on 4.99), there was a two steps discovery
> process. During the first 10 seconds, the adapter will look for new
> devices, and during the second 30 seconds, it will ask each device for
> further information.
>
> I have here devices like the Monster ClarityHD speakers, or the
> Creative WP-350 headsets. Those devices announce a short name with the
> Inquiry Result. btmon reveals a "HCI Event: Extended Inquiry Result"
> for each one with a short name of 9 chars, respectively "Monster C"
> and "Creative " (with a space at the end).
>
> BlueZ 4 will show this name during the first 10 seconds as the name of
> the device, but when the adapter goes to the second step, it will
> issue a "HCI Command: Remote Name Request" and get the full name, like
> "Creative WP-350 Headset" and update the property on the device, still
> during discovery.
>
> In the other hand, BlueZ 5 will not issue a "Remote Name Request"
> until you attempt a pairing. This is not the best user experience
> since no matter how long you leave your scan session on, you will
> never get the right name of the device, until you attempt a connection
> or a pairing with it.
>
> Even worse, if you had connected to the device before (and you have
> the long name in the bluez cache for example), if you scan for new
> devices and this device shows up in that scan, bluez will change the
> name to the short version.
>
> I'm thinking about sending a Remote Name Request to the new devices
> between the "> HCI Event: Inquiry Complete" and the "< HCI Command:
> Inquiry". What do you think about this approach? Do you have a better
> idea to solve this?
I don't know if this is what you already had in mind, but I would
start on the userspace side, src/adapter.c:4052
(update_found_devices()), and make it send the confirm name command in
the cases that we only have the short name. It should cause the remote
name to be requested.
>
> Thanks,
> Alex.
> --
> 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
Cheers,
--
Vinicius