LE mouse reconnect problem

LE mouse reconnect problem

[Ryan Press]

I have a Microsoft Arc mouse, Surface edition.  This uses Bluetooth
Low Energy.  Under dual boot Windows 8.1 I can connect this mouse, and
it will reconnect just fine if I turn the mouse off/on or Bluetooth
off/on.

In Fedora rawhide I have Bluez 5.18-2.  I can pair this mouse just
fine, and it will continue to work until I turn the mouse off/on or
turn the computer off/on.  Then it won't reconnect automatically.  If
I go into bluetoothctl I can connect it again and it will then work.

I looked at bluetoothd and it seems to be doing the LE scan with:
bluetoothd[2356]: src/adapter.c:trigger_passive_scanning()
bluetoothd[2356]: src/adapter.c:passive_scanning_complete() status 0x00
bluetoothd[2356]: src/adapter.c:discovering_callback() hci0 type 6 discovering 1

I look also at hcidump and I see:
< HCI Command: LE Set Random Address (0x08|0x0005) plen 6
    bdaddr 39:6D:E2:EC:17:37
> HCI Event: Command Complete (0x0e) plen 4
    LE Set Random Address (0x08|0x0005) ncmd 1
    status 0x00
< HCI Command: LE Set Scan Parameters (0x08|0x000b) plen 7
    type 0x01 (active)
    interval 11.250ms window 11.250ms
    own address: 0x01 (Random) policy: All
> HCI Event: Command Complete (0x0e) plen 4
    LE Set Scan Parameters (0x08|0x000b) ncmd 1
    status 0x00
< HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2
    value 0x01 (scanning enabled)
    filter duplicates 0x01 (enabled)
> HCI Event: Command Complete (0x0e) plen 4
    LE Set Scan Enable (0x08|0x000c) ncmd 2
    status 0x00
< HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2
    value 0x00 (scanning disabled)
    filter duplicates 0x00 (disabled)


It doesn't seem to be finding anything?  Is there something else I should try?

Thanks,
Ryan

Re: LE mouse reconnect problem

[Luiz Augusto von Dentz]

Hi Ryan,

On Wed, Jun 25, 2014 at 5:27 AM, Ryan Press <ryan@presslab.us> wrote:
> I have a Microsoft Arc mouse, Surface edition.  This uses Bluetooth
> Low Energy.  Under dual boot Windows 8.1 I can connect this mouse, and
> it will reconnect just fine if I turn the mouse off/on or Bluetooth
> off/on.
>
> In Fedora rawhide I have Bluez 5.18-2.  I can pair this mouse just
> fine, and it will continue to work until I turn the mouse off/on or
> turn the computer off/on.  Then it won't reconnect automatically.  If
> I go into bluetoothctl I can connect it again and it will then work.
>
> I looked at bluetoothd and it seems to be doing the LE scan with:
> bluetoothd[2356]: src/adapter.c:trigger_passive_scanning()
> bluetoothd[2356]: src/adapter.c:passive_scanning_complete() status 0x00
> bluetoothd[2356]: src/adapter.c:discovering_callback() hci0 type 6 discovering 1
>
> I look also at hcidump and I see:
> < HCI Command: LE Set Random Address (0x08|0x0005) plen 6
>     bdaddr 39:6D:E2:EC:17:37
>> HCI Event: Command Complete (0x0e) plen 4
>     LE Set Random Address (0x08|0x0005) ncmd 1
>     status 0x00
> < HCI Command: LE Set Scan Parameters (0x08|0x000b) plen 7
>     type 0x01 (active)
>     interval 11.250ms window 11.250ms
>     own address: 0x01 (Random) policy: All
>> HCI Event: Command Complete (0x0e) plen 4
>     LE Set Scan Parameters (0x08|0x000b) ncmd 1
>     status 0x00
> < HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2
>     value 0x01 (scanning enabled)
>     filter duplicates 0x01 (enabled)
>> HCI Event: Command Complete (0x0e) plen 4
>     LE Set Scan Enable (0x08|0x000c) ncmd 2
>     status 0x00
> < HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2
>     value 0x00 (scanning disabled)
>     filter duplicates 0x00 (disabled)
>
>
> It doesn't seem to be finding anything?  Is there something else I should try?

Does it continue to scan or it scan a single time and stops, and have
you paired or just connect?


-- 
Luiz Augusto von Dentz

Fwd: LE mouse reconnect problem

[Ryan Press]

Hi Luiz,

Yes it will repeat the scan every few seconds.

I paired the device in the Gnome applet.  In the bluetoothctl I could
see the pair and trust messages like so:

[NEW] Device C5:8C:97:E6:9C:81 Arc Touch Mouse SE
[CHG] Device C5:8C:97:E6:9C:81 Connected: yes
[CHG] Device C5:8C:97:E6:9C:81 UUIDs:
    00001800-0000-1000-8000-00805f9b34fb
    00001801-0000-1000-8000-00805f9b34fb
    0000180a-0000-1000-8000-00805f9b34fb
    0000180f-0000-1000-8000-00805f9b34fb
    00001812-0000-1000-8000-00805f9b34fb
[CHG] Device C5:8C:97:E6:9C:81 Paired: yes
[CHG] Device C5:8C:97:E6:9C:81 Trusted: yes
[CHG] Device C5:8C:97:E6:9C:81 Modalias: usb:v045Ep07F3d0001

Thanks,

Ryan


On Jun 25, 2014 12:08 AM, "Luiz Augusto von Dentz" <luiz.dentz@gmail.com> wrote:
>
> Hi Ryan,
>
> On Wed, Jun 25, 2014 at 5:27 AM, Ryan Press <ryan@presslab.us> wrote:
> > I have a Microsoft Arc mouse, Surface edition.  This uses Bluetooth
> > Low Energy.  Under dual boot Windows 8.1 I can connect this mouse, and
> > it will reconnect just fine if I turn the mouse off/on or Bluetooth
> > off/on.
> >
> > In Fedora rawhide I have Bluez 5.18-2.  I can pair this mouse just
> > fine, and it will continue to work until I turn the mouse off/on or
> > turn the computer off/on.  Then it won't reconnect automatically.  If
> > I go into bluetoothctl I can connect it again and it will then work.
> >
> > I looked at bluetoothd and it seems to be doing the LE scan with:
> > bluetoothd[2356]: src/adapter.c:trigger_passive_scanning()
> > bluetoothd[2356]: src/adapter.c:passive_scanning_complete() status 0x00
> > bluetoothd[2356]: src/adapter.c:discovering_callback() hci0 type 6 discovering 1
> >
> > I look also at hcidump and I see:
> > < HCI Command: LE Set Random Address (0x08|0x0005) plen 6
> >     bdaddr 39:6D:E2:EC:17:37
> >> HCI Event: Command Complete (0x0e) plen 4
> >     LE Set Random Address (0x08|0x0005) ncmd 1
> >     status 0x00
> > < HCI Command: LE Set Scan Parameters (0x08|0x000b) plen 7
> >     type 0x01 (active)
> >     interval 11.250ms window 11.250ms
> >     own address: 0x01 (Random) policy: All
> >> HCI Event: Command Complete (0x0e) plen 4
> >     LE Set Scan Parameters (0x08|0x000b) ncmd 1
> >     status 0x00
> > < HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2
> >     value 0x01 (scanning enabled)
> >     filter duplicates 0x01 (enabled)
> >> HCI Event: Command Complete (0x0e) plen 4
> >     LE Set Scan Enable (0x08|0x000c) ncmd 2
> >     status 0x00
> > < HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2
> >     value 0x00 (scanning disabled)
> >     filter duplicates 0x00 (disabled)
> >
> >
> > It doesn't seem to be finding anything?  Is there something else I should try?
>
> Does it continue to scan or it scan a single time and stops, and have
> you paired or just connect?
>
>
> --
> Luiz Augusto von Dentz

Re: LE mouse reconnect problem

[Luiz Augusto von Dentz]

Hi Ryan,

On Wed, Jun 25, 2014 at 4:23 PM, Ryan Press <ryan@presslab.us> wrote:
> Hi Luiz,
>
> Yes it will repeat the scan every few seconds.
>
> I paired the device in the Gnome applet.  In the bluetoothctl I could
> see the pair and trust messages like so:
>
> [NEW] Device C5:8C:97:E6:9C:81 Arc Touch Mouse SE
> [CHG] Device C5:8C:97:E6:9C:81 Connected: yes
> [CHG] Device C5:8C:97:E6:9C:81 UUIDs:
>     00001800-0000-1000-8000-00805f9b34fb
>     00001801-0000-1000-8000-00805f9b34fb
>     0000180a-0000-1000-8000-00805f9b34fb
>     0000180f-0000-1000-8000-00805f9b34fb
>     00001812-0000-1000-8000-00805f9b34fb
> [CHG] Device C5:8C:97:E6:9C:81 Paired: yes
> [CHG] Device C5:8C:97:E6:9C:81 Trusted: yes
> [CHG] Device C5:8C:97:E6:9C:81 Modalias: usb:v045Ep07F3d0001
>
> Thanks,
>
> Ryan
>
>
> On Jun 25, 2014 12:08 AM, "Luiz Augusto von Dentz" <luiz.dentz@gmail.com> wrote:
>>
>> Hi Ryan,
>>
>> On Wed, Jun 25, 2014 at 5:27 AM, Ryan Press <ryan@presslab.us> wrote:
>> > I have a Microsoft Arc mouse, Surface edition.  This uses Bluetooth
>> > Low Energy.  Under dual boot Windows 8.1 I can connect this mouse, and
>> > it will reconnect just fine if I turn the mouse off/on or Bluetooth
>> > off/on.
>> >
>> > In Fedora rawhide I have Bluez 5.18-2.  I can pair this mouse just
>> > fine, and it will continue to work until I turn the mouse off/on or
>> > turn the computer off/on.  Then it won't reconnect automatically.  If
>> > I go into bluetoothctl I can connect it again and it will then work.
>> >
>> > I looked at bluetoothd and it seems to be doing the LE scan with:
>> > bluetoothd[2356]: src/adapter.c:trigger_passive_scanning()
>> > bluetoothd[2356]: src/adapter.c:passive_scanning_complete() status 0x00
>> > bluetoothd[2356]: src/adapter.c:discovering_callback() hci0 type 6 discovering 1
>> >
>> > I look also at hcidump and I see:
>> > < HCI Command: LE Set Random Address (0x08|0x0005) plen 6
>> >     bdaddr 39:6D:E2:EC:17:37
>> >> HCI Event: Command Complete (0x0e) plen 4
>> >     LE Set Random Address (0x08|0x0005) ncmd 1
>> >     status 0x00
>> > < HCI Command: LE Set Scan Parameters (0x08|0x000b) plen 7
>> >     type 0x01 (active)
>> >     interval 11.250ms window 11.250ms
>> >     own address: 0x01 (Random) policy: All
>> >> HCI Event: Command Complete (0x0e) plen 4
>> >     LE Set Scan Parameters (0x08|0x000b) ncmd 1
>> >     status 0x00
>> > < HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2
>> >     value 0x01 (scanning enabled)
>> >     filter duplicates 0x01 (enabled)
>> >> HCI Event: Command Complete (0x0e) plen 4
>> >     LE Set Scan Enable (0x08|0x000c) ncmd 2
>> >     status 0x00
>> > < HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2
>> >     value 0x00 (scanning disabled)
>> >     filter duplicates 0x00 (disabled)
>> >
>> >
>> > It doesn't seem to be finding anything?  Is there something else I should try?
>>
>> Does it continue to scan or it scan a single time and stops, and have
>> you paired or just connect?

Can you try with current master, we have applied a few patches for reconnection.


-- 
Luiz Augusto von Dentz

Re: LE mouse reconnect problem

[Ryan Press]

Hi Luiz,

I have compiled and install the git Bluez.

It's the same as before, I can pair it and it will work, but it won't
automatically reconnect.  Using bluetoothctl and "connect" command I
can manually reconnect.

Thanks for the help.

Ryan


On Fri, Jun 27, 2014 at 1:32 AM, Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
> Hi Ryan,
>
> On Wed, Jun 25, 2014 at 4:23 PM, Ryan Press <ryan@presslab.us> wrote:
>> Hi Luiz,
>>
>> Yes it will repeat the scan every few seconds.
>>
>> I paired the device in the Gnome applet.  In the bluetoothctl I could
>> see the pair and trust messages like so:
>>
>> [NEW] Device C5:8C:97:E6:9C:81 Arc Touch Mouse SE
>> [CHG] Device C5:8C:97:E6:9C:81 Connected: yes
>> [CHG] Device C5:8C:97:E6:9C:81 UUIDs:
>>     00001800-0000-1000-8000-00805f9b34fb
>>     00001801-0000-1000-8000-00805f9b34fb
>>     0000180a-0000-1000-8000-00805f9b34fb
>>     0000180f-0000-1000-8000-00805f9b34fb
>>     00001812-0000-1000-8000-00805f9b34fb
>> [CHG] Device C5:8C:97:E6:9C:81 Paired: yes
>> [CHG] Device C5:8C:97:E6:9C:81 Trusted: yes
>> [CHG] Device C5:8C:97:E6:9C:81 Modalias: usb:v045Ep07F3d0001
>>
>> Thanks,
>>
>> Ryan
>>
>>
>> On Jun 25, 2014 12:08 AM, "Luiz Augusto von Dentz" <luiz.dentz@gmail.com> wrote:
>>>
>>> Hi Ryan,
>>>
>>> On Wed, Jun 25, 2014 at 5:27 AM, Ryan Press <ryan@presslab.us> wrote:
>>> > I have a Microsoft Arc mouse, Surface edition.  This uses Bluetooth
>>> > Low Energy.  Under dual boot Windows 8.1 I can connect this mouse, and
>>> > it will reconnect just fine if I turn the mouse off/on or Bluetooth
>>> > off/on.
>>> >
>>> > In Fedora rawhide I have Bluez 5.18-2.  I can pair this mouse just
>>> > fine, and it will continue to work until I turn the mouse off/on or
>>> > turn the computer off/on.  Then it won't reconnect automatically.  If
>>> > I go into bluetoothctl I can connect it again and it will then work.
>>> >
>>> > I looked at bluetoothd and it seems to be doing the LE scan with:
>>> > bluetoothd[2356]: src/adapter.c:trigger_passive_scanning()
>>> > bluetoothd[2356]: src/adapter.c:passive_scanning_complete() status 0x00
>>> > bluetoothd[2356]: src/adapter.c:discovering_callback() hci0 type 6 discovering 1
>>> >
>>> > I look also at hcidump and I see:
>>> > < HCI Command: LE Set Random Address (0x08|0x0005) plen 6
>>> >     bdaddr 39:6D:E2:EC:17:37
>>> >> HCI Event: Command Complete (0x0e) plen 4
>>> >     LE Set Random Address (0x08|0x0005) ncmd 1
>>> >     status 0x00
>>> > < HCI Command: LE Set Scan Parameters (0x08|0x000b) plen 7
>>> >     type 0x01 (active)
>>> >     interval 11.250ms window 11.250ms
>>> >     own address: 0x01 (Random) policy: All
>>> >> HCI Event: Command Complete (0x0e) plen 4
>>> >     LE Set Scan Parameters (0x08|0x000b) ncmd 1
>>> >     status 0x00
>>> > < HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2
>>> >     value 0x01 (scanning enabled)
>>> >     filter duplicates 0x01 (enabled)
>>> >> HCI Event: Command Complete (0x0e) plen 4
>>> >     LE Set Scan Enable (0x08|0x000c) ncmd 2
>>> >     status 0x00
>>> > < HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2
>>> >     value 0x00 (scanning disabled)
>>> >     filter duplicates 0x00 (disabled)
>>> >
>>> >
>>> > It doesn't seem to be finding anything?  Is there something else I should try?
>>>
>>> Does it continue to scan or it scan a single time and stops, and have
>>> you paired or just connect?
>
> Can you try with current master, we have applied a few patches for reconnection.
>
>
> --
> Luiz Augusto von Dentz

Re: LE mouse reconnect problem

[Luiz Augusto von Dentz]

Hi Ryan,

On Sat, Jun 28, 2014 at 6:50 PM, Ryan Press <ryan@presslab.us> wrote:
> Hi Luiz,
>
> I have compiled and install the git Bluez.
>
> It's the same as before, I can pair it and it will work, but it won't
> automatically reconnect.  Using bluetoothctl and "connect" command I
> can manually reconnect.
>

No top posting please. Im running out of ideas, are you sure the mouse
is advertising using the same address?

>
>
> On Fri, Jun 27, 2014 at 1:32 AM, Luiz Augusto von Dentz
> <luiz.dentz@gmail.com> wrote:
>> Hi Ryan,
>>
>> On Wed, Jun 25, 2014 at 4:23 PM, Ryan Press <ryan@presslab.us> wrote:
>>> Hi Luiz,
>>>
>>> Yes it will repeat the scan every few seconds.
>>>
>>> I paired the device in the Gnome applet.  In the bluetoothctl I could
>>> see the pair and trust messages like so:
>>>
>>> [NEW] Device C5:8C:97:E6:9C:81 Arc Touch Mouse SE
>>> [CHG] Device C5:8C:97:E6:9C:81 Connected: yes
>>> [CHG] Device C5:8C:97:E6:9C:81 UUIDs:
>>>     00001800-0000-1000-8000-00805f9b34fb
>>>     00001801-0000-1000-8000-00805f9b34fb
>>>     0000180a-0000-1000-8000-00805f9b34fb
>>>     0000180f-0000-1000-8000-00805f9b34fb
>>>     00001812-0000-1000-8000-00805f9b34fb
>>> [CHG] Device C5:8C:97:E6:9C:81 Paired: yes
>>> [CHG] Device C5:8C:97:E6:9C:81 Trusted: yes
>>> [CHG] Device C5:8C:97:E6:9C:81 Modalias: usb:v045Ep07F3d0001
>>>
>>> Thanks,
>>>
>>> Ryan
>>>
>>>
>>> On Jun 25, 2014 12:08 AM, "Luiz Augusto von Dentz" <luiz.dentz@gmail.com> wrote:
>>>>
>>>> Hi Ryan,
>>>>
>>>> On Wed, Jun 25, 2014 at 5:27 AM, Ryan Press <ryan@presslab.us> wrote:
>>>> > I have a Microsoft Arc mouse, Surface edition.  This uses Bluetooth
>>>> > Low Energy.  Under dual boot Windows 8.1 I can connect this mouse, and
>>>> > it will reconnect just fine if I turn the mouse off/on or Bluetooth
>>>> > off/on.
>>>> >
>>>> > In Fedora rawhide I have Bluez 5.18-2.  I can pair this mouse just
>>>> > fine, and it will continue to work until I turn the mouse off/on or
>>>> > turn the computer off/on.  Then it won't reconnect automatically.  If
>>>> > I go into bluetoothctl I can connect it again and it will then work.
>>>> >
>>>> > I looked at bluetoothd and it seems to be doing the LE scan with:
>>>> > bluetoothd[2356]: src/adapter.c:trigger_passive_scanning()
>>>> > bluetoothd[2356]: src/adapter.c:passive_scanning_complete() status 0x00
>>>> > bluetoothd[2356]: src/adapter.c:discovering_callback() hci0 type 6 discovering 1
>>>> >
>>>> > I look also at hcidump and I see:
>>>> > < HCI Command: LE Set Random Address (0x08|0x0005) plen 6
>>>> >     bdaddr 39:6D:E2:EC:17:37
>>>> >> HCI Event: Command Complete (0x0e) plen 4
>>>> >     LE Set Random Address (0x08|0x0005) ncmd 1
>>>> >     status 0x00
>>>> > < HCI Command: LE Set Scan Parameters (0x08|0x000b) plen 7
>>>> >     type 0x01 (active)
>>>> >     interval 11.250ms window 11.250ms
>>>> >     own address: 0x01 (Random) policy: All
>>>> >> HCI Event: Command Complete (0x0e) plen 4
>>>> >     LE Set Scan Parameters (0x08|0x000b) ncmd 1
>>>> >     status 0x00
>>>> > < HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2
>>>> >     value 0x01 (scanning enabled)
>>>> >     filter duplicates 0x01 (enabled)
>>>> >> HCI Event: Command Complete (0x0e) plen 4
>>>> >     LE Set Scan Enable (0x08|0x000c) ncmd 2
>>>> >     status 0x00
>>>> > < HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2
>>>> >     value 0x00 (scanning disabled)
>>>> >     filter duplicates 0x00 (disabled)
>>>> >
>>>> >
>>>> > It doesn't seem to be finding anything?  Is there something else I should try?
>>>>
>>>> Does it continue to scan or it scan a single time and stops, and have
>>>> you paired or just connect?
>>
>> Can you try with current master, we have applied a few patches for reconnection.
>>
>>
>> --
>> Luiz Augusto von Dentz



-- 
Luiz Augusto von Dentz

Re: LE mouse reconnect problem

[Ryan Press]

On Sat, Jun 28, 2014 at 12:22 PM, Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
> On Sat, Jun 28, 2014 at 6:50 PM, Ryan Press <ryan@presslab.us> wrote:
>> On Fri, Jun 27, 2014 at 1:32 AM, Luiz Augusto von Dentz
>> <luiz.dentz@gmail.com> wrote:
>>> Hi Ryan,
>>>
>>> On Wed, Jun 25, 2014 at 4:23 PM, Ryan Press <ryan@presslab.us> wrote:
>>>> Hi Luiz,
>>>>
>>>> Yes it will repeat the scan every few seconds.
>>>>
>>>> I paired the device in the Gnome applet.  In the bluetoothctl I could
>>>> see the pair and trust messages like so:
>>>>
>>>> [NEW] Device C5:8C:97:E6:9C:81 Arc Touch Mouse SE
>>>> [CHG] Device C5:8C:97:E6:9C:81 Connected: yes
>>>> [CHG] Device C5:8C:97:E6:9C:81 UUIDs:
>>>>     00001800-0000-1000-8000-00805f9b34fb
>>>>     00001801-0000-1000-8000-00805f9b34fb
>>>>     0000180a-0000-1000-8000-00805f9b34fb
>>>>     0000180f-0000-1000-8000-00805f9b34fb
>>>>     00001812-0000-1000-8000-00805f9b34fb
>>>> [CHG] Device C5:8C:97:E6:9C:81 Paired: yes
>>>> [CHG] Device C5:8C:97:E6:9C:81 Trusted: yes
>>>> [CHG] Device C5:8C:97:E6:9C:81 Modalias: usb:v045Ep07F3d0001
>>>>
>>>> Thanks,
>>>>
>>>> Ryan
>>>>
>>>>
>>>> On Jun 25, 2014 12:08 AM, "Luiz Augusto von Dentz" <luiz.dentz@gmail.com> wrote:
>>>>>
>>>>> Hi Ryan,
>>>>>
>>>>> On Wed, Jun 25, 2014 at 5:27 AM, Ryan Press <ryan@presslab.us> wrote:
>>>>> > I have a Microsoft Arc mouse, Surface edition.  This uses Bluetooth
>>>>> > Low Energy.  Under dual boot Windows 8.1 I can connect this mouse, and
>>>>> > it will reconnect just fine if I turn the mouse off/on or Bluetooth
>>>>> > off/on.
>>>>> >
>>>>> > In Fedora rawhide I have Bluez 5.18-2.  I can pair this mouse just
>>>>> > fine, and it will continue to work until I turn the mouse off/on or
>>>>> > turn the computer off/on.  Then it won't reconnect automatically.  If
>>>>> > I go into bluetoothctl I can connect it again and it will then work.
>>>>> >
>>>>> > I looked at bluetoothd and it seems to be doing the LE scan with:
>>>>> > bluetoothd[2356]: src/adapter.c:trigger_passive_scanning()
>>>>> > bluetoothd[2356]: src/adapter.c:passive_scanning_complete() status 0x00
>>>>> > bluetoothd[2356]: src/adapter.c:discovering_callback() hci0 type 6 discovering 1
>>>>> >
>>>>> > I look also at hcidump and I see:
>>>>> > < HCI Command: LE Set Random Address (0x08|0x0005) plen 6
>>>>> >     bdaddr 39:6D:E2:EC:17:37
>>>>> >> HCI Event: Command Complete (0x0e) plen 4
>>>>> >     LE Set Random Address (0x08|0x0005) ncmd 1
>>>>> >     status 0x00
>>>>> > < HCI Command: LE Set Scan Parameters (0x08|0x000b) plen 7
>>>>> >     type 0x01 (active)
>>>>> >     interval 11.250ms window 11.250ms
>>>>> >     own address: 0x01 (Random) policy: All
>>>>> >> HCI Event: Command Complete (0x0e) plen 4
>>>>> >     LE Set Scan Parameters (0x08|0x000b) ncmd 1
>>>>> >     status 0x00
>>>>> > < HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2
>>>>> >     value 0x01 (scanning enabled)
>>>>> >     filter duplicates 0x01 (enabled)
>>>>> >> HCI Event: Command Complete (0x0e) plen 4
>>>>> >     LE Set Scan Enable (0x08|0x000c) ncmd 2
>>>>> >     status 0x00
>>>>> > < HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2
>>>>> >     value 0x00 (scanning disabled)
>>>>> >     filter duplicates 0x00 (disabled)
>>>>> >
>>>>> >
>>>>> > It doesn't seem to be finding anything?  Is there something else I should try?
>>>>>
>>>>> Does it continue to scan or it scan a single time and stops, and have
>>>>> you paired or just connect?
>>>
>>> Can you try with current master, we have applied a few patches for reconnection.
>>>
>>>
>>> --
>>> Luiz Augusto von Dentz
>> Hi Luiz,
>>
>> I have compiled and install the git Bluez.
>>
>> It's the same as before, I can pair it and it will work, but it won't
>> automatically reconnect.  Using bluetoothctl and "connect" command I
>> can manually reconnect.
>>
>
> No top posting please. Im running out of ideas, are you sure the mouse
> is advertising using the same address?

I just tested with "hcitool lescan" and it connected okay.  So I
looked at a "hcidump" for the hcitool scan and for the Bluez scan and
they are a bit different.

Here is the one from "hcitool lescan":

HCI sniffer - Bluetooth packet analyzer ver 5.20
device: hci0 snap_len: 1500 filter: 0xffffffffffffffff
2014-06-28 12:54:01.421267 < HCI Command: LE Set Scan Parameters
(0x08|0x000b) plen 7
    type 0x01 (active)
    interval 10.000ms window 10.000ms
    own address: 0x00 (Public) policy: All
2014-06-28 12:54:01.422140 > HCI Event: Command Complete (0x0e) plen 4
    LE Set Scan Parameters (0x08|0x000b) ncmd 1
    status 0x00
2014-06-28 12:54:01.422238 < HCI Command: LE Set Scan Enable
(0x08|0x000c) plen 2
    value 0x01 (scanning enabled)
    filter duplicates 0x01 (enabled)
2014-06-28 12:54:01.423144 > HCI Event: Command Complete (0x0e) plen 4
    LE Set Scan Enable (0x08|0x000c) ncmd 2
    status 0x00
2014-06-28 12:54:01.425141 > HCI Event: LE Meta Event (0x3e) plen 12
    LE Advertising Report
      ADV_DIRECT_IND - Connectable directed advertising (1)
      bdaddr C5:8C:97:E9:9C:81 (Random)
      RSSI: -35
2014-06-28 12:54:01.425333 < HCI Command: LE Set Scan Enable
(0x08|0x000c) plen 2
    value 0x00 (scanning disabled)
    filter duplicates 0x00 (disabled)
2014-06-28 12:54:01.429161 > HCI Event: Command Complete (0x0e) plen 4
    LE Set Scan Enable (0x08|0x000c) ncmd 2
    status 0x00
2014-06-28 12:54:01.429409 < HCI Command: LE Create Connection
(0x08|0x000d) plen 25
    bdaddr C5:8C:97:E9:9C:81 type 1
    interval 96 window 48 initiator_filter 0
    own_bdaddr_type 0 min_interval 40 max_interval 56
    latency 0 supervision_to 42 min_ce 0 max_ce 0
2014-06-28 12:54:01.430157 > HCI Event: Command Status (0x0f) plen 4
    LE Create Connection (0x08|0x000d) status 0x00 ncmd 2
2014-06-28 12:54:01.433220 > HCI Event: LE Meta Event (0x3e) plen 19
    LE Connection Complete
      status 0x00 handle 3585, role master
      bdaddr C5:8C:97:E9:9C:81 (Random)
2014-06-28 12:54:01.433476 < HCI Command: LE Set Scan Enable
(0x08|0x000c) plen 2
    value 0x00 (scanning disabled)
    filter duplicates 0x01 (enabled)
2014-06-28 12:54:01.434141 > HCI Event: Command Complete (0x0e) plen 4
    LE Set Scan Enable (0x08|0x000c) ncmd 1
    status 0x0c
    Error: Command Disallowed
2014-06-28 12:54:01.434206 < HCI Command: LE Start Encryption
(0x08|0x0019) plen 28
2014-06-28 12:54:01.435140 > HCI Event: Command Status (0x0f) plen 4
    LE Start Encryption (0x08|0x0019) status 0x00 ncmd 1
2014-06-28 12:54:01.848191 > HCI Event: Encrypt Change (0x08) plen 4
    status 0x00 handle 3585 encrypt 0x01
2014-06-28 12:54:01.848461 < ACL data: handle 3585 flags 0x00 dlen 11
    ATT: Read By Type req (0x08)
      start 0x000c, end 0x0010
      type-uuid 0x2803
2014-06-28 12:54:01.918203 > HCI Event: Number of Completed Packets
(0x13) plen 5
    handle 3585 packets 1
2014-06-28 12:54:01.988079 > ACL data: handle 3585 flags 0x02 dlen 20
    ATT: Read By Type resp (0x09)
      length: 7
        handle 0x000d, value 0x02 0x0e 0x00 0x29 0x2a
        handle 0x000f, value 0x02 0x10 0x00 0x50 0x2a
2014-06-28 12:54:01.988364 < ACL data: handle 3585 flags 0x00 dlen 7
    ATT: MTU req (0x02)
      client rx mtu 672
2014-06-28 12:54:02.058200 > HCI Event: Number of Completed Packets
(0x13) plen 5
    handle 3585 packets 1
2014-06-28 12:54:02.127941 > ACL data: handle 3585 flags 0x02 dlen 7
    ATT: MTU resp (0x03)
      server rx mtu 23
2014-06-28 12:54:02.128174 < ACL data: handle 3585 flags 0x00 dlen 7
    ATT: Read req (0x0a)
      handle 0x0010
2014-06-28 12:54:02.198204 > HCI Event: Number of Completed Packets
(0x13) plen 5
    handle 3585 packets 1
2014-06-28 12:54:02.267972 > ACL data: handle 3585 flags 0x02 dlen 12
    ATT: Read resp (0x0b)

And here is the one from the regular bluetoothd:

HCI sniffer - Bluetooth packet analyzer ver 5.20
device: hci0 snap_len: 1500 filter: 0xffffffffffffffff
2014-06-28 12:55:30.229459 < HCI Command: LE Set Scan Enable
(0x08|0x000c) plen 2
    value 0x00 (scanning disabled)
    filter duplicates 0x00 (disabled)
2014-06-28 12:55:30.232444 > HCI Event: Command Complete (0x0e) plen 4
    LE Set Scan Enable (0x08|0x000c) ncmd 2
    status 0x00
2014-06-28 12:55:33.954807 < HCI Command: LE Set Random Address
(0x08|0x0005) plen 6
    bdaddr 00:67:25:80:95:CD
2014-06-28 12:55:33.955419 > HCI Event: Command Complete (0x0e) plen 4
    LE Set Random Address (0x08|0x0005) ncmd 1
    status 0x00
2014-06-28 12:55:33.955494 < HCI Command: LE Set Scan Parameters
(0x08|0x000b) plen 7
    type 0x01 (active)
    interval 11.250ms window 11.250ms
    own address: 0x01 (Random) policy: All
2014-06-28 12:55:33.956440 > HCI Event: Command Complete (0x0e) plen 4
    LE Set Scan Parameters (0x08|0x000b) ncmd 1
    status 0x00
2014-06-28 12:55:33.956509 < HCI Command: LE Set Scan Enable
(0x08|0x000c) plen 2
    value 0x01 (scanning enabled)
    filter duplicates 0x01 (enabled)
2014-06-28 12:55:33.957440 > HCI Event: Command Complete (0x0e) plen 4
    LE Set Scan Enable (0x08|0x000c) ncmd 2
    status 0x00
2014-06-28 12:55:44.213285 < HCI Command: LE Set Scan Enable
(0x08|0x000c) plen 2
    value 0x00 (scanning disabled)
    filter duplicates 0x00 (disabled)
2014-06-28 12:55:44.215502 > HCI Event: Command Complete (0x0e) plen 4
    LE Set Scan Enable (0x08|0x000c) ncmd 2
    status 0x00


It looks like Bluez is using random address and hcitool lescan is
using public address.  I don't know why to use random or public.

hcitool lescan:
    own address: 0x00 (Public) policy: All
bluetoothd:
    own address: 0x01 (Random) policy: All

And the advertise address from the mouse is the same.

hcitool:
    bdaddr C5:8C:97:E9:9C:81 (Random)
bluetoothctl:
[NEW] Device C5:8C:97:E9:9C:81 Arc Touch Mouse SE


Thanks.
Ryan

Re: LE mouse reconnect problem

[Ryan Press]

On Sat, Jun 28, 2014 at 1:07 PM, Ryan Press <ryan@presslab.us> wrote:
> On Sat, Jun 28, 2014 at 12:22 PM, Luiz Augusto von Dentz
> <luiz.dentz@gmail.com> wrote:
>> On Sat, Jun 28, 2014 at 6:50 PM, Ryan Press <ryan@presslab.us> wrote:
>>> On Fri, Jun 27, 2014 at 1:32 AM, Luiz Augusto von Dentz
>>> <luiz.dentz@gmail.com> wrote:
>>>> Hi Ryan,
>>>>
>>>> On Wed, Jun 25, 2014 at 4:23 PM, Ryan Press <ryan@presslab.us> wrote:
>>>>> Hi Luiz,
>>>>>
>>>>> Yes it will repeat the scan every few seconds.
>>>>>
>>>>> I paired the device in the Gnome applet.  In the bluetoothctl I could
>>>>> see the pair and trust messages like so:
>>>>>
>>>>> [NEW] Device C5:8C:97:E6:9C:81 Arc Touch Mouse SE
>>>>> [CHG] Device C5:8C:97:E6:9C:81 Connected: yes
>>>>> [CHG] Device C5:8C:97:E6:9C:81 UUIDs:
>>>>>     00001800-0000-1000-8000-00805f9b34fb
>>>>>     00001801-0000-1000-8000-00805f9b34fb
>>>>>     0000180a-0000-1000-8000-00805f9b34fb
>>>>>     0000180f-0000-1000-8000-00805f9b34fb
>>>>>     00001812-0000-1000-8000-00805f9b34fb
>>>>> [CHG] Device C5:8C:97:E6:9C:81 Paired: yes
>>>>> [CHG] Device C5:8C:97:E6:9C:81 Trusted: yes
>>>>> [CHG] Device C5:8C:97:E6:9C:81 Modalias: usb:v045Ep07F3d0001
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Ryan
>>>>>
>>>>>
>>>>> On Jun 25, 2014 12:08 AM, "Luiz Augusto von Dentz" <luiz.dentz@gmail.com> wrote:
>>>>>>
>>>>>> Hi Ryan,
>>>>>>
>>>>>> On Wed, Jun 25, 2014 at 5:27 AM, Ryan Press <ryan@presslab.us> wrote:
>>>>>> > I have a Microsoft Arc mouse, Surface edition.  This uses Bluetooth
>>>>>> > Low Energy.  Under dual boot Windows 8.1 I can connect this mouse, and
>>>>>> > it will reconnect just fine if I turn the mouse off/on or Bluetooth
>>>>>> > off/on.
>>>>>> >
>>>>>> > In Fedora rawhide I have Bluez 5.18-2.  I can pair this mouse just
>>>>>> > fine, and it will continue to work until I turn the mouse off/on or
>>>>>> > turn the computer off/on.  Then it won't reconnect automatically.  If
>>>>>> > I go into bluetoothctl I can connect it again and it will then work.
>>>>>> >
>>>>>> > I looked at bluetoothd and it seems to be doing the LE scan with:
>>>>>> > bluetoothd[2356]: src/adapter.c:trigger_passive_scanning()
>>>>>> > bluetoothd[2356]: src/adapter.c:passive_scanning_complete() status 0x00
>>>>>> > bluetoothd[2356]: src/adapter.c:discovering_callback() hci0 type 6 discovering 1
>>>>>> >
>>>>>> > I look also at hcidump and I see:
>>>>>> > < HCI Command: LE Set Random Address (0x08|0x0005) plen 6
>>>>>> >     bdaddr 39:6D:E2:EC:17:37
>>>>>> >> HCI Event: Command Complete (0x0e) plen 4
>>>>>> >     LE Set Random Address (0x08|0x0005) ncmd 1
>>>>>> >     status 0x00
>>>>>> > < HCI Command: LE Set Scan Parameters (0x08|0x000b) plen 7
>>>>>> >     type 0x01 (active)
>>>>>> >     interval 11.250ms window 11.250ms
>>>>>> >     own address: 0x01 (Random) policy: All
>>>>>> >> HCI Event: Command Complete (0x0e) plen 4
>>>>>> >     LE Set Scan Parameters (0x08|0x000b) ncmd 1
>>>>>> >     status 0x00
>>>>>> > < HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2
>>>>>> >     value 0x01 (scanning enabled)
>>>>>> >     filter duplicates 0x01 (enabled)
>>>>>> >> HCI Event: Command Complete (0x0e) plen 4
>>>>>> >     LE Set Scan Enable (0x08|0x000c) ncmd 2
>>>>>> >     status 0x00
>>>>>> > < HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2
>>>>>> >     value 0x00 (scanning disabled)
>>>>>> >     filter duplicates 0x00 (disabled)
>>>>>> >
>>>>>> >
>>>>>> > It doesn't seem to be finding anything?  Is there something else I should try?
>>>>>>
>>>>>> Does it continue to scan or it scan a single time and stops, and have
>>>>>> you paired or just connect?
>>>>
>>>> Can you try with current master, we have applied a few patches for reconnection.
>>>>
>>>>
>>>> --
>>>> Luiz Augusto von Dentz
>>> Hi Luiz,
>>>
>>> I have compiled and install the git Bluez.
>>>
>>> It's the same as before, I can pair it and it will work, but it won't
>>> automatically reconnect.  Using bluetoothctl and "connect" command I
>>> can manually reconnect.
>>>
>>
>> No top posting please. Im running out of ideas, are you sure the mouse
>> is advertising using the same address?
>
> I just tested with "hcitool lescan" and it connected okay.  So I
> looked at a "hcidump" for the hcitool scan and for the Bluez scan and
> they are a bit different.
>
> Here is the one from "hcitool lescan":
>
> HCI sniffer - Bluetooth packet analyzer ver 5.20
> device: hci0 snap_len: 1500 filter: 0xffffffffffffffff
> 2014-06-28 12:54:01.421267 < HCI Command: LE Set Scan Parameters
> (0x08|0x000b) plen 7
>     type 0x01 (active)
>     interval 10.000ms window 10.000ms
>     own address: 0x00 (Public) policy: All
> 2014-06-28 12:54:01.422140 > HCI Event: Command Complete (0x0e) plen 4
>     LE Set Scan Parameters (0x08|0x000b) ncmd 1
>     status 0x00
> 2014-06-28 12:54:01.422238 < HCI Command: LE Set Scan Enable
> (0x08|0x000c) plen 2
>     value 0x01 (scanning enabled)
>     filter duplicates 0x01 (enabled)
> 2014-06-28 12:54:01.423144 > HCI Event: Command Complete (0x0e) plen 4
>     LE Set Scan Enable (0x08|0x000c) ncmd 2
>     status 0x00
> 2014-06-28 12:54:01.425141 > HCI Event: LE Meta Event (0x3e) plen 12
>     LE Advertising Report
>       ADV_DIRECT_IND - Connectable directed advertising (1)
>       bdaddr C5:8C:97:E9:9C:81 (Random)
>       RSSI: -35
> 2014-06-28 12:54:01.425333 < HCI Command: LE Set Scan Enable
> (0x08|0x000c) plen 2
>     value 0x00 (scanning disabled)
>     filter duplicates 0x00 (disabled)
> 2014-06-28 12:54:01.429161 > HCI Event: Command Complete (0x0e) plen 4
>     LE Set Scan Enable (0x08|0x000c) ncmd 2
>     status 0x00
> 2014-06-28 12:54:01.429409 < HCI Command: LE Create Connection
> (0x08|0x000d) plen 25
>     bdaddr C5:8C:97:E9:9C:81 type 1
>     interval 96 window 48 initiator_filter 0
>     own_bdaddr_type 0 min_interval 40 max_interval 56
>     latency 0 supervision_to 42 min_ce 0 max_ce 0
> 2014-06-28 12:54:01.430157 > HCI Event: Command Status (0x0f) plen 4
>     LE Create Connection (0x08|0x000d) status 0x00 ncmd 2
> 2014-06-28 12:54:01.433220 > HCI Event: LE Meta Event (0x3e) plen 19
>     LE Connection Complete
>       status 0x00 handle 3585, role master
>       bdaddr C5:8C:97:E9:9C:81 (Random)
> 2014-06-28 12:54:01.433476 < HCI Command: LE Set Scan Enable
> (0x08|0x000c) plen 2
>     value 0x00 (scanning disabled)
>     filter duplicates 0x01 (enabled)
> 2014-06-28 12:54:01.434141 > HCI Event: Command Complete (0x0e) plen 4
>     LE Set Scan Enable (0x08|0x000c) ncmd 1
>     status 0x0c
>     Error: Command Disallowed
> 2014-06-28 12:54:01.434206 < HCI Command: LE Start Encryption
> (0x08|0x0019) plen 28
> 2014-06-28 12:54:01.435140 > HCI Event: Command Status (0x0f) plen 4
>     LE Start Encryption (0x08|0x0019) status 0x00 ncmd 1
> 2014-06-28 12:54:01.848191 > HCI Event: Encrypt Change (0x08) plen 4
>     status 0x00 handle 3585 encrypt 0x01
> 2014-06-28 12:54:01.848461 < ACL data: handle 3585 flags 0x00 dlen 11
>     ATT: Read By Type req (0x08)
>       start 0x000c, end 0x0010
>       type-uuid 0x2803
> 2014-06-28 12:54:01.918203 > HCI Event: Number of Completed Packets
> (0x13) plen 5
>     handle 3585 packets 1
> 2014-06-28 12:54:01.988079 > ACL data: handle 3585 flags 0x02 dlen 20
>     ATT: Read By Type resp (0x09)
>       length: 7
>         handle 0x000d, value 0x02 0x0e 0x00 0x29 0x2a
>         handle 0x000f, value 0x02 0x10 0x00 0x50 0x2a
> 2014-06-28 12:54:01.988364 < ACL data: handle 3585 flags 0x00 dlen 7
>     ATT: MTU req (0x02)
>       client rx mtu 672
> 2014-06-28 12:54:02.058200 > HCI Event: Number of Completed Packets
> (0x13) plen 5
>     handle 3585 packets 1
> 2014-06-28 12:54:02.127941 > ACL data: handle 3585 flags 0x02 dlen 7
>     ATT: MTU resp (0x03)
>       server rx mtu 23
> 2014-06-28 12:54:02.128174 < ACL data: handle 3585 flags 0x00 dlen 7
>     ATT: Read req (0x0a)
>       handle 0x0010
> 2014-06-28 12:54:02.198204 > HCI Event: Number of Completed Packets
> (0x13) plen 5
>     handle 3585 packets 1
> 2014-06-28 12:54:02.267972 > ACL data: handle 3585 flags 0x02 dlen 12
>     ATT: Read resp (0x0b)
>
> And here is the one from the regular bluetoothd:
>
> HCI sniffer - Bluetooth packet analyzer ver 5.20
> device: hci0 snap_len: 1500 filter: 0xffffffffffffffff
> 2014-06-28 12:55:30.229459 < HCI Command: LE Set Scan Enable
> (0x08|0x000c) plen 2
>     value 0x00 (scanning disabled)
>     filter duplicates 0x00 (disabled)
> 2014-06-28 12:55:30.232444 > HCI Event: Command Complete (0x0e) plen 4
>     LE Set Scan Enable (0x08|0x000c) ncmd 2
>     status 0x00
> 2014-06-28 12:55:33.954807 < HCI Command: LE Set Random Address
> (0x08|0x0005) plen 6
>     bdaddr 00:67:25:80:95:CD
> 2014-06-28 12:55:33.955419 > HCI Event: Command Complete (0x0e) plen 4
>     LE Set Random Address (0x08|0x0005) ncmd 1
>     status 0x00
> 2014-06-28 12:55:33.955494 < HCI Command: LE Set Scan Parameters
> (0x08|0x000b) plen 7
>     type 0x01 (active)
>     interval 11.250ms window 11.250ms
>     own address: 0x01 (Random) policy: All
> 2014-06-28 12:55:33.956440 > HCI Event: Command Complete (0x0e) plen 4
>     LE Set Scan Parameters (0x08|0x000b) ncmd 1
>     status 0x00
> 2014-06-28 12:55:33.956509 < HCI Command: LE Set Scan Enable
> (0x08|0x000c) plen 2
>     value 0x01 (scanning enabled)
>     filter duplicates 0x01 (enabled)
> 2014-06-28 12:55:33.957440 > HCI Event: Command Complete (0x0e) plen 4
>     LE Set Scan Enable (0x08|0x000c) ncmd 2
>     status 0x00
> 2014-06-28 12:55:44.213285 < HCI Command: LE Set Scan Enable
> (0x08|0x000c) plen 2
>     value 0x00 (scanning disabled)
>     filter duplicates 0x00 (disabled)
> 2014-06-28 12:55:44.215502 > HCI Event: Command Complete (0x0e) plen 4
>     LE Set Scan Enable (0x08|0x000c) ncmd 2
>     status 0x00
>
>
> It looks like Bluez is using random address and hcitool lescan is
> using public address.  I don't know why to use random or public.
>
> hcitool lescan:
>     own address: 0x00 (Public) policy: All
> bluetoothd:
>     own address: 0x01 (Random) policy: All
>
> And the advertise address from the mouse is the same.
>
> hcitool:
>     bdaddr C5:8C:97:E9:9C:81 (Random)
> bluetoothctl:
> [NEW] Device C5:8C:97:E9:9C:81 Arc Touch Mouse SE
>
>
> Thanks.
> Ryan

Hi Luiz,

I realized that 3.15+ kernel had the LE Privacy support, so I tried
3.14 and my mouse reconnects just fine.  So somehow my mouse does not
work with the new LE Privacy in the kernel.

I couldn't find any way to disable this.  It seems that bluetoothd
just uses the default setting which is LE Privacy enabled.  And I
couldn't find any way in the kernel to disable it via a module option
or sysfs.  Is there some other way I can disable this?

Thanks,
Ryan

Re: LE mouse reconnect problem

[Johan Hedberg]

Hi Ryan,

On Sat, Jun 28, 2014, Ryan Press wrote:
> > It looks like Bluez is using random address and hcitool lescan is
> > using public address.  I don't know why to use random or public.
> >
> > hcitool lescan:
> >     own address: 0x00 (Public) policy: All
> > bluetoothd:
> >     own address: 0x01 (Random) policy: All
> >
> > And the advertise address from the mouse is the same.
> >
> > hcitool:
> >     bdaddr C5:8C:97:E9:9C:81 (Random)
> > bluetoothctl:
> > [NEW] Device C5:8C:97:E9:9C:81 Arc Touch Mouse SE
> >
> >
> > Thanks.
> > Ryan
> 
> Hi Luiz,
> 
> I realized that 3.15+ kernel had the LE Privacy support, so I tried
> 3.14 and my mouse reconnects just fine.  So somehow my mouse does not
> work with the new LE Privacy in the kernel.
> 
> I couldn't find any way to disable this.  It seems that bluetoothd
> just uses the default setting which is LE Privacy enabled.  And I
> couldn't find any way in the kernel to disable it via a module option
> or sysfs.  Is there some other way I can disable this?

What the kernel does is it actually uses a non-resolvable private
address when doing active scanning. You should still be able to get
advertising indications even though you don't get scan responses (as the
remote can only choose to not send you the latter based on your
address). So it's a bit strange you just get complete silence when doing
active scanning with a non-resolvable private address.

It'd be interesting to know whether passive scanning discovers the
device (it should). This is what we should be using, but as the kernel
interface for it is not yet ready we're reusing the Start Discovery mgmt
command which uses active instead of passive scanning.

Btw, it would be *much* better if you used btmon instead of hcidump for
your investigation. It has much more complete decoding of all the
various commands and events. Now we have to guess part of the parameters
that you posted since hcidump doesn't show them.

Johan

Re: LE mouse reconnect problem

[Johan Hedberg]

Hi,

On Sun, Jun 29, 2014, Johan Hedberg wrote:
> On Sat, Jun 28, 2014, Ryan Press wrote:
> > > It looks like Bluez is using random address and hcitool lescan is
> > > using public address.  I don't know why to use random or public.
> > >
> > > hcitool lescan:
> > >     own address: 0x00 (Public) policy: All
> > > bluetoothd:
> > >     own address: 0x01 (Random) policy: All
> > >
> > > And the advertise address from the mouse is the same.
> > >
> > > hcitool:
> > >     bdaddr C5:8C:97:E9:9C:81 (Random)
> > > bluetoothctl:
> > > [NEW] Device C5:8C:97:E9:9C:81 Arc Touch Mouse SE
> > >
> > >
> > > Thanks.
> > > Ryan
> > 
> > Hi Luiz,
> > 
> > I realized that 3.15+ kernel had the LE Privacy support, so I tried
> > 3.14 and my mouse reconnects just fine.  So somehow my mouse does not
> > work with the new LE Privacy in the kernel.
> > 
> > I couldn't find any way to disable this.  It seems that bluetoothd
> > just uses the default setting which is LE Privacy enabled.  And I
> > couldn't find any way in the kernel to disable it via a module option
> > or sysfs.  Is there some other way I can disable this?
> 
> What the kernel does is it actually uses a non-resolvable private
> address when doing active scanning. You should still be able to get
> advertising indications even though you don't get scan responses (as the
> remote can only choose to not send you the latter based on your
> address). So it's a bit strange you just get complete silence when doing
> active scanning with a non-resolvable private address.
> 
> It'd be interesting to know whether passive scanning discovers the
> device (it should). This is what we should be using, but as the kernel
> interface for it is not yet ready we're reusing the Start Discovery mgmt
> command which uses active instead of passive scanning.
> 
> Btw, it would be *much* better if you used btmon instead of hcidump for
> your investigation. It has much more complete decoding of all the
> various commands and events. Now we have to guess part of the parameters
> that you posted since hcidump doesn't show them.

One part I missed: it seems the mouse is using directed advertising:

2014-06-28 12:54:01.425141 > HCI Event: LE Meta Event (0x3e) plen 12
    LE Advertising Report
      ADV_DIRECT_IND - Connectable directed advertising (1)
      bdaddr C5:8C:97:E9:9C:81 (Random)
      RSSI: -35

It's possible that this makes your local controller filter out even the
indications as they don't match the local address.

Johan

Re: LE mouse reconnect problem

[Marcel Holtmann]

Hi Johan,

>>>> It looks like Bluez is using random address and hcitool lescan is
>>>> using public address.  I don't know why to use random or public.
>>>> 
>>>> hcitool lescan:
>>>>   own address: 0x00 (Public) policy: All
>>>> bluetoothd:
>>>>   own address: 0x01 (Random) policy: All
>>>> 
>>>> And the advertise address from the mouse is the same.
>>>> 
>>>> hcitool:
>>>>   bdaddr C5:8C:97:E9:9C:81 (Random)
>>>> bluetoothctl:
>>>> [NEW] Device C5:8C:97:E9:9C:81 Arc Touch Mouse SE
>>>> 
>>>> 
>>>> Thanks.
>>>> Ryan
>>> 
>>> Hi Luiz,
>>> 
>>> I realized that 3.15+ kernel had the LE Privacy support, so I tried
>>> 3.14 and my mouse reconnects just fine.  So somehow my mouse does not
>>> work with the new LE Privacy in the kernel.
>>> 
>>> I couldn't find any way to disable this.  It seems that bluetoothd
>>> just uses the default setting which is LE Privacy enabled.  And I
>>> couldn't find any way in the kernel to disable it via a module option
>>> or sysfs.  Is there some other way I can disable this?
>> 
>> What the kernel does is it actually uses a non-resolvable private
>> address when doing active scanning. You should still be able to get
>> advertising indications even though you don't get scan responses (as the
>> remote can only choose to not send you the latter based on your
>> address). So it's a bit strange you just get complete silence when doing
>> active scanning with a non-resolvable private address.
>> 
>> It'd be interesting to know whether passive scanning discovers the
>> device (it should). This is what we should be using, but as the kernel
>> interface for it is not yet ready we're reusing the Start Discovery mgmt
>> command which uses active instead of passive scanning.
>> 
>> Btw, it would be *much* better if you used btmon instead of hcidump for
>> your investigation. It has much more complete decoding of all the
>> various commands and events. Now we have to guess part of the parameters
>> that you posted since hcidump doesn't show them.
> 
> One part I missed: it seems the mouse is using directed advertising:
> 
> 2014-06-28 12:54:01.425141 > HCI Event: LE Meta Event (0x3e) plen 12
>   LE Advertising Report
>     ADV_DIRECT_IND - Connectable directed advertising (1)
>     bdaddr C5:8C:97:E9:9C:81 (Random)
>     RSSI: -35
> 
> It's possible that this makes your local controller filter out even the
> indications as they don't match the local address.

that is pretty much the issue here. The controller will filter out any ADV_DIRECT_IND that are not directed to the own address that it is currently using. That is mainly the reason why nobody today is using direct advertising since it broken for non-resolvable and resolvable private addresses. This is the first LE device using advertising that I have seen so far.

So when the mouse is discoverable and ready for pairing with a host, you will see these:

> HCI Event: LE Meta Event (0x3e) plen 43
     LE Advertising Report (0x02)
       Num reports: 1
       Event type: Connectable undirected - ADV_IND (0x00)
       Address type: Random (0x01)
       Address: E7:AD:BC:AA:1A:3B (Static)
       Data length: 31
       Name (complete): Arc Touch Mouse SE
       Appearance: Mouse (0x03c2)
       Flags: 0x05
         LE Limited Discoverable Mode
         BR/EDR Not Supported
       16-bit Service UUIDs (complete): 1 entry
         Human Interface Device (0x1812)
       RSSI: -57 dBm (0xc7)
> HCI Event: LE Meta Event (0x3e) plen 12
     LE Advertising Report (0x02)
       Num reports: 1
       Event type: Scan response - SCAN_RSP (0x04)
       Address type: Random (0x01)
       Address: E7:AD:BC:AA:1A:3B (Static)
       Data length: 0
       RSSI: -57 dBm (0xc7)

However once you are paired and you switch it one, you will only see these:

> HCI Event: LE Meta Event (0x3e) plen 12
     LE Advertising Report (0x02)
       Num reports: 1
       Event type: Connectable directed - ADV_DIRECT_IND (0x01)
       Address type: Random (0x01)
       Address: E7:AD:BC:AA:1A:3B (Static)
       Data length: 0
       RSSI: -53 dBm (0xcb)

And for some reason the address also keeps changing if you pair multiple times. The 4th octet (AA) keeps changing when you are pairing the mouse again. It seems a bit like that for every pairing, the mouse generates a new static random address and might actually remember the old one. I have seen direct advertising with the old address as well. So that is an interesting behavior.

The biggest problem here is that even if you are trying to be private and doing everything right, the mouse will broadcast your public address every time it tries to reconnect. So thank you Microsoft for forcing us to be trackable.

At least when we are using resolvable private addresses, we can distribute our IRK to the mouse:

< ACL Data TX: Handle 64 flags 0x00 dlen 11
     SMP: Pairing Request (0x01) len 6
       IO capability: DisplayYesNo (0x01)
       OOB data: Authentication data not present (0x00)
       Authentication requirement: Bonding - MITM (0x05)
       Max encryption key size: 16
       Initiator key distribution: EncKey IdKey Sign (0x07)
       Responder key distribution: EncKey IdKey Sign (0x07)
> ACL Data RX: Handle 64 flags 0x02 dlen 11
     SMP: Pairing Response (0x02) len 6
       IO capability: NoInputNoOutput (0x03)
       OOB data: Authentication data not present (0x00)
       Authentication requirement: Bonding - No MITM (0x01)
       Max encryption key size: 16
       Initiator key distribution: IdKey Sign (0x06)
       Responder key distribution: EncKey (0x01)

< ACL Data TX: Handle 64 flags 0x00 dlen 21
     SMP: Identity Information (0x08) len 16
       Identity resolving key: ba0583710e172dee8e8e8eb70e15d232
< ACL Data TX: Handle 64 flags 0x00 dlen 12
     SMP: Identity Address Information (0x09) len 7
       Address type: Public (0x00)
       Address: 00:02:A2:CC:10:04

The problem with that however is that we will still not get ADV_DIRECT_IND since the mouse will never know with resolvable private address we are using at the moment. So it might use an outdated address and then the controller will filter it out like it will filter it out with non-resolvable private addresses.

In conclusion, we have one clear bug with our experimental passive scanning support. Since passive scanning is not sending SCAN_REQ, we should just scan with our current identity address (public or static random). We tried to be extra safe when doing background scanning, but we forgot to take direct advertising into account.

The takeaway here is that active scanning (discovery) should be done using non-resolvable or resolvable private addresses, while passive scanning (background) should be done using identity address or resolvable private address.

Now the biggest problem is that with 3.15 and 3.16-rcX kernels we would need to go back to using our identity address for discovery. This means active scanning and it means we are broadcasting our identity address to everybody when trying to find this mouse. I rather not do that.

Regards

Marcel

Re: LE mouse reconnect problem

[Ryan Press]

Hi Marcel,

On Sun, Jun 29, 2014 at 2:43 AM, Marcel Holtmann <marcel@holtmann.org> wrot=
e:
> Hi Johan,
>
>>>>> It looks like Bluez is using random address and hcitool lescan is
>>>>> using public address.  I don't know why to use random or public.
>>>>>
>>>>> hcitool lescan:
>>>>>   own address: 0x00 (Public) policy: All
>>>>> bluetoothd:
>>>>>   own address: 0x01 (Random) policy: All
>>>>>
>>>>> And the advertise address from the mouse is the same.
>>>>>
>>>>> hcitool:
>>>>>   bdaddr C5:8C:97:E9:9C:81 (Random)
>>>>> bluetoothctl:
>>>>> [NEW] Device C5:8C:97:E9:9C:81 Arc Touch Mouse SE
>>>>>
>>>>>
>>>>> Thanks.
>>>>> Ryan
>>>>
>>>> Hi Luiz,
>>>>
>>>> I realized that 3.15+ kernel had the LE Privacy support, so I tried
>>>> 3.14 and my mouse reconnects just fine.  So somehow my mouse does not
>>>> work with the new LE Privacy in the kernel.
>>>>
>>>> I couldn't find any way to disable this.  It seems that bluetoothd
>>>> just uses the default setting which is LE Privacy enabled.  And I
>>>> couldn't find any way in the kernel to disable it via a module option
>>>> or sysfs.  Is there some other way I can disable this?
>>>
>>> What the kernel does is it actually uses a non-resolvable private
>>> address when doing active scanning. You should still be able to get
>>> advertising indications even though you don't get scan responses (as th=
e
>>> remote can only choose to not send you the latter based on your
>>> address). So it's a bit strange you just get complete silence when doin=
g
>>> active scanning with a non-resolvable private address.
>>>
>>> It'd be interesting to know whether passive scanning discovers the
>>> device (it should). This is what we should be using, but as the kernel
>>> interface for it is not yet ready we're reusing the Start Discovery mgm=
t
>>> command which uses active instead of passive scanning.
>>>
>>> Btw, it would be *much* better if you used btmon instead of hcidump for
>>> your investigation. It has much more complete decoding of all the
>>> various commands and events. Now we have to guess part of the parameter=
s
>>> that you posted since hcidump doesn't show them.
>>
>> One part I missed: it seems the mouse is using directed advertising:
>>
>> 2014-06-28 12:54:01.425141 > HCI Event: LE Meta Event (0x3e) plen 12
>>   LE Advertising Report
>>     ADV_DIRECT_IND - Connectable directed advertising (1)
>>     bdaddr C5:8C:97:E9:9C:81 (Random)
>>     RSSI: -35
>>
>> It's possible that this makes your local controller filter out even the
>> indications as they don't match the local address.
>
> that is pretty much the issue here. The controller will filter out any AD=
V_DIRECT_IND that are not directed to the own address that it is currently =
using. That is mainly the reason why nobody today is using direct advertisi=
ng since it broken for non-resolvable and resolvable private addresses. Thi=
s is the first LE device using advertising that I have seen so far.
> In conclusion, we have one clear bug with our experimental passive scanni=
ng support. Since passive scanning is not sending SCAN_REQ, we should just =
scan with our current identity address (public or static random). We tried =
to be extra safe when doing background scanning, but we forgot to take dire=
ct advertising into account.

>
> The takeaway here is that active scanning (discovery) should be done usin=
g non-resolvable or resolvable private addresses, while passive scanning (b=
ackground) should be done using identity address or resolvable private addr=
ess.
>
> Now the biggest problem is that with 3.15 and 3.16-rcX kernels we would n=
eed to go back to using our identity address for discovery. This means acti=
ve scanning and it means we are broadcasting our identity address to everyb=
ody when trying to find this mouse. I rather not do that.
>
> Regards
>
> Marcel
>

Thanks guys, especially Marcel!  I have applied your patch and now the
mouse reconnects correctly.

I have one other question with it.  When it first reconnects the mouse
pointer is really jerky, like it's updating really slow.  Then after a
few seconds it is normal; in fact it is very responsive compared to my
old Bluetooth mouse.  With Windows 8.1 it reconnects lightning fast
when I turn it on, and it is not jerky at first.

Bluetooth monitor ver 5.20
=3D New Index: 5C:51:4F:0F:45:9B (BR/EDR,USB,hci0)                [hci0] 0.=
378098
< HCI Command: LE Set Scan Parameters (0x08|0x000b) plen 7      [hci0] 2.29=
1608
        Type: Active (0x01)
        Interval: 11.250 msec (0x0012)
        Window: 11.250 msec (0x0012)
        Own address type: Public (0x00)
        Filter policy: Accept all advertisement (0x00)
> HCI Event: Command Complete (0x0e) plen 4                     [hci0] 2.29=
2495
      LE Set Scan Parameters (0x08|0x000b) ncmd 1
        Status: Success (0x00)
< HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2          [hci0] 2.29=
2569
        Scanning: Enabled (0x01)
        Filter duplicates: Enabled (0x01)
> HCI Event: Command Complete (0x0e) plen 4                     [hci0] 2.29=
3492
      LE Set Scan Enable (0x08|0x000c) ncmd 2
        Status: Success (0x00)
@ Discovering: 0x01 (6)
> HCI Event: LE Meta Event (0x3e) plen 12                       [hci0] 2.29=
7493
      LE Advertising Report (0x02)
        Num reports: 1
        Event type: Connectable directed - ADV_DIRECT_IND (0x01)
        Address type: Random (0x01)
        Address: C5:8C:97:E9:9C:81 (Static)
        Data length: 0
        RSSI: -48 dBm (0xd0)
@ Device Found: C5:8C:97:E9:9C:81 (2) rssi -48 flags 0x0000
< HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2          [hci0] 2.29=
7704
        Scanning: Disabled (0x00)
        Filter duplicates: Disabled (0x00)
> HCI Event: Command Complete (0x0e) plen 4                     [hci0] 2.30=
1506
      LE Set Scan Enable (0x08|0x000c) ncmd 2
        Status: Success (0x00)
@ Discovering: 0x00 (6)
< HCI Command: LE Create Connection (0x08|0x000d) plen 25       [hci0] 2.30=
2027
        Scan interval: 60.000 msec (0x0060)
        Scan window: 30.000 msec (0x0030)
        Filter policy: White list is not used (0x00)
        Peer address type: Random (0x01)
        Peer address: C5:8C:97:E9:9C:81 (Static)
        Own address type: Public (0x00)
        Min connection interval: 50.00 msec (0x0028)
        Max connection interval: 70.00 msec (0x0038)
        Connection latency: 0x0000
        Supervision timeout: 420 msec (0x002a)
        Min connection length: 0.000 msec (0x0000)
        Max connection length: 0.000 msec (0x0000)
> HCI Event: Command Status (0x0f) plen 4                       [hci0] 2.30=
3493
      LE Create Connection (0x08|0x000d) ncmd 2
        Status: Success (0x00)
> HCI Event: LE Meta Event (0x3e) plen 19                       [hci0] 2.30=
8593
      LE Connection Complete (0x01)
        Status: Success (0x00)
        Handle: 3585
        Role: Master (0x00)
        Peer address type: Random (0x01)
        Peer address: C5:8C:97:E9:9C:81 (Static)
        Connection interval: 70.00 msec (0x0038)
        Connection latency: 0.00 msec (0x0000)
        Supervision timeout: 420 msec (0x002a)
        Master clock accuracy: 0x00
@ Device Connected: C5:8C:97:E9:9C:81 (2) flags 0x0000
< HCI Command: LE Start Encryption (0x08|0x0019) plen 28        [hci0] 2.30=
8922
        Handle: 3585
        Random number: 0x42a37f88d3b5619c
        Encrypted diversifier: 0x21e0
        Long term key: 283980ebe520609d7af359b28e996572
> HCI Event: Command Status (0x0f) plen 4                       [hci0] 2.31=
0487
      LE Start Encryption (0x08|0x0019) ncmd 1
        Status: Success (0x00)
> HCI Event: Encryption Change (0x08) plen 4                    [hci0] 2.71=
5586
        Status: Success (0x00)
        Handle: 3585
        Encryption: Enabled with AES-CCM (0x01)
< ACL Data TX: Handle 3585 flags 0x00 dlen 11                   [hci0] 2.71=
5867
      ATT: Read By Type Request (0x08) len 6
        Handle range: 0x000c-0x0010
        Attribute type: Characteristic (0x2803)
> ACL Data RX: Handle 3585 flags 0x02 dlen 16                   [hci0] 2.78=
5254
      ATT: Handle Value Notification (0x1b) len 11
        Handle: 0x0021
          Data: 001500b7ff00000000
> HCI Event: Number of Completed Packets (0x13) plen 5          [hci0] 2.78=
5496
        Num handles: 1
        Handle: 3585
        Count: 1
> ACL Data RX: Handle 3585 flags 0x02 dlen 20                   [hci0] 2.85=
5169
      ATT: Read By Type Response (0x09) len 15
        Attribute data length: 7
        Attribute data list: 2 entries
        Handle: 0x000d
        Value: 020e00292a
        Handle: 0x000f
        Value: 021000502a
< ACL Data TX: Handle 3585 flags 0x00 dlen 7                    [hci0] 2.85=
5447
      ATT: Exchange MTU Request (0x02) len 2
        Client RX MTU: 672
> HCI Event: Number of Completed Packets (0x13) plen 5          [hci0] 2.92=
5588
        Num handles: 1
        Handle: 3585
        Count: 1
> ACL Data RX: Handle 3585 flags 0x02 dlen 7                    [hci0] 2.99=
5043
      ATT: Exchange MTU Response (0x03) len 2
        Server RX MTU: 23
< ACL Data TX: Handle 3585 flags 0x00 dlen 7                    [hci0] 2.99=
5278
      ATT: Read Request (0x0a) len 2
        Handle: 0x0010
> HCI Event: Number of Completed Packets (0x13) plen 5          [hci0] 3.06=
5590
        Num handles: 1
        Handle: 3585
        Count: 1
> ACL Data RX: Handle 3585 flags 0x02 dlen 12                   [hci0] 3.13=
5107
      ATT: Read Response (0x0b) len 7
        Value: 025e04f3070100
> ACL Data RX: Handle 3585 flags 0x02 dlen 16                   [hci0] 7.40=
5125
      LE L2CAP: Connection Parameter Update Request (0x12) ident 2 len 8
        Min interval: 6
        Max interval: 6
        Slave latency: 40
        Timeout multiplier: 300
< ACL Data TX: Handle 3585 flags 0x00 dlen 10                   [hci0] 7.40=
5247
      LE L2CAP: Connection Parameter Update Response (0x13) ident 2 len 2
        Result: Connection Parameters accepted (0x0000)
< HCI Command: LE Connection Update (0x08|0x0013) plen 14       [hci0] 7.40=
5276
        Handle: 3585
        Min connection interval: 7.50 msec (0x0006)
        Max connection interval: 7.50 msec (0x0006)
        Connection latency: 0x0028
        Supervision timeout: 3000 msec (0x012c)
        Min connection length: 0.000 msec (0x0000)
        Max connection length: 0.000 msec (0x0000)
> HCI Event: Command Status (0x0f) plen 4                       [hci0] 7.40=
7611
      LE Connection Update (0x08|0x0013) ncmd 2
        Status: Success (0x00)
> HCI Event: Number of Completed Packets (0x13) plen 5          [hci0] 7.47=
5614
        Num handles: 1
        Handle: 3585
        Count: 1
> HCI Event: LE Meta Event (0x3e) plen 10                       [hci0] 8.03=
5642
      LE Connection Update Complete (0x03)
        Status: Success (0x00)
        Handle: 3585
        Connection interval: 7.50 msec (0x0006)
        Connection latency: 50.00 msec (0x0028)
        Supervision timeout: 3000 msec (0x012c)
> ACL Data RX: Handle 3585 flags 0x02 dlen 16                  [hci0] 11.69=
5162
      ATT: Handle Value Notification (0x1b) len 11
        Handle: 0x0021
          Data: 000000000000000000
> ACL Data RX: Handle 3585 flags 0x02 dlen 16                  [hci0] 11.92=
0069
      ATT: Handle Value Notification (0x1b) len 11
        Handle: 0x0021
          Data: 000000000000000000
> ACL Data RX: Handle 3585 flags 0x02 dlen 16                  [hci0] 11.92=
7662
      ATT: Handle Value Notification (0x1b) len 11
        Handle: 0x0021
          Data: 000000010000000000


I see at first this setting:
        Min connection interval: 50.00 msec (0x0028)
        Max connection interval: 70.00 msec (0x0038)
And later this setting:
        Min connection interval: 7.50 msec (0x0006)
        Max connection interval: 7.50 msec (0x0006)

I guess this is why it's slow at first.  I wonder why it just doesn't
start out at 7.5 ms?  And with the somewhat slower reconnection issue
I believe it's due to bluetoothd not polling as quickly.

Thanks,
Ryan

Re: LE mouse reconnect problem

[Marcel Holtmann]

Hi Ryan,

>>>>>> It looks like Bluez is using random address and hcitool lescan is
>>>>>> using public address.  I don't know why to use random or public.
>>>>>> 
>>>>>> hcitool lescan:
>>>>>>  own address: 0x00 (Public) policy: All
>>>>>> bluetoothd:
>>>>>>  own address: 0x01 (Random) policy: All
>>>>>> 
>>>>>> And the advertise address from the mouse is the same.
>>>>>> 
>>>>>> hcitool:
>>>>>>  bdaddr C5:8C:97:E9:9C:81 (Random)
>>>>>> bluetoothctl:
>>>>>> [NEW] Device C5:8C:97:E9:9C:81 Arc Touch Mouse SE
>>>>>> 
>>>>>> 
>>>>>> Thanks.
>>>>>> Ryan
>>>>> 
>>>>> Hi Luiz,
>>>>> 
>>>>> I realized that 3.15+ kernel had the LE Privacy support, so I tried
>>>>> 3.14 and my mouse reconnects just fine.  So somehow my mouse does not
>>>>> work with the new LE Privacy in the kernel.
>>>>> 
>>>>> I couldn't find any way to disable this.  It seems that bluetoothd
>>>>> just uses the default setting which is LE Privacy enabled.  And I
>>>>> couldn't find any way in the kernel to disable it via a module option
>>>>> or sysfs.  Is there some other way I can disable this?
>>>> 
>>>> What the kernel does is it actually uses a non-resolvable private
>>>> address when doing active scanning. You should still be able to get
>>>> advertising indications even though you don't get scan responses (as the
>>>> remote can only choose to not send you the latter based on your
>>>> address). So it's a bit strange you just get complete silence when doing
>>>> active scanning with a non-resolvable private address.
>>>> 
>>>> It'd be interesting to know whether passive scanning discovers the
>>>> device (it should). This is what we should be using, but as the kernel
>>>> interface for it is not yet ready we're reusing the Start Discovery mgmt
>>>> command which uses active instead of passive scanning.
>>>> 
>>>> Btw, it would be *much* better if you used btmon instead of hcidump for
>>>> your investigation. It has much more complete decoding of all the
>>>> various commands and events. Now we have to guess part of the parameters
>>>> that you posted since hcidump doesn't show them.
>>> 
>>> One part I missed: it seems the mouse is using directed advertising:
>>> 
>>> 2014-06-28 12:54:01.425141 > HCI Event: LE Meta Event (0x3e) plen 12
>>>  LE Advertising Report
>>>    ADV_DIRECT_IND - Connectable directed advertising (1)
>>>    bdaddr C5:8C:97:E9:9C:81 (Random)
>>>    RSSI: -35
>>> 
>>> It's possible that this makes your local controller filter out even the
>>> indications as they don't match the local address.
>> 
>> that is pretty much the issue here. The controller will filter out any ADV_DIRECT_IND that are not directed to the own address that it is currently using. That is mainly the reason why nobody today is using direct advertising since it broken for non-resolvable and resolvable private addresses. This is the first LE device using advertising that I have seen so far.
>> In conclusion, we have one clear bug with our experimental passive scanning support. Since passive scanning is not sending SCAN_REQ, we should just scan with our current identity address (public or static random). We tried to be extra safe when doing background scanning, but we forgot to take direct advertising into account.
> 
>> 
>> The takeaway here is that active scanning (discovery) should be done using non-resolvable or resolvable private addresses, while passive scanning (background) should be done using identity address or resolvable private address.
>> 
>> Now the biggest problem is that with 3.15 and 3.16-rcX kernels we would need to go back to using our identity address for discovery. This means active scanning and it means we are broadcasting our identity address to everybody when trying to find this mouse. I rather not do that.
>> 
>> Regards
>> 
>> Marcel
>> 
> 
> Thanks guys, especially Marcel!  I have applied your patch and now the
> mouse reconnects correctly.
> 
> I have one other question with it.  When it first reconnects the mouse
> pointer is really jerky, like it's updating really slow.  Then after a
> few seconds it is normal; in fact it is very responsive compared to my
> old Bluetooth mouse.  With Windows 8.1 it reconnects lightning fast
> when I turn it on, and it is not jerky at first.
> 
> Bluetooth monitor ver 5.20
> = New Index: 5C:51:4F:0F:45:9B (BR/EDR,USB,hci0)                [hci0] 0.378098
> < HCI Command: LE Set Scan Parameters (0x08|0x000b) plen 7      [hci0] 2.291608
>        Type: Active (0x01)
>        Interval: 11.250 msec (0x0012)
>        Window: 11.250 msec (0x0012)
>        Own address type: Public (0x00)
>        Filter policy: Accept all advertisement (0x00)
>> HCI Event: Command Complete (0x0e) plen 4                     [hci0] 2.292495
>      LE Set Scan Parameters (0x08|0x000b) ncmd 1
>        Status: Success (0x00)
> < HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2          [hci0] 2.292569
>        Scanning: Enabled (0x01)
>        Filter duplicates: Enabled (0x01)
>> HCI Event: Command Complete (0x0e) plen 4                     [hci0] 2.293492
>      LE Set Scan Enable (0x08|0x000c) ncmd 2
>        Status: Success (0x00)
> @ Discovering: 0x01 (6)
>> HCI Event: LE Meta Event (0x3e) plen 12                       [hci0] 2.297493
>      LE Advertising Report (0x02)
>        Num reports: 1
>        Event type: Connectable directed - ADV_DIRECT_IND (0x01)
>        Address type: Random (0x01)
>        Address: C5:8C:97:E9:9C:81 (Static)
>        Data length: 0
>        RSSI: -48 dBm (0xd0)
> @ Device Found: C5:8C:97:E9:9C:81 (2) rssi -48 flags 0x0000
> < HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2          [hci0] 2.297704
>        Scanning: Disabled (0x00)
>        Filter duplicates: Disabled (0x00)
>> HCI Event: Command Complete (0x0e) plen 4                     [hci0] 2.301506
>      LE Set Scan Enable (0x08|0x000c) ncmd 2
>        Status: Success (0x00)
> @ Discovering: 0x00 (6)
> < HCI Command: LE Create Connection (0x08|0x000d) plen 25       [hci0] 2.302027
>        Scan interval: 60.000 msec (0x0060)
>        Scan window: 30.000 msec (0x0030)
>        Filter policy: White list is not used (0x00)
>        Peer address type: Random (0x01)
>        Peer address: C5:8C:97:E9:9C:81 (Static)
>        Own address type: Public (0x00)
>        Min connection interval: 50.00 msec (0x0028)
>        Max connection interval: 70.00 msec (0x0038)
>        Connection latency: 0x0000
>        Supervision timeout: 420 msec (0x002a)
>        Min connection length: 0.000 msec (0x0000)
>        Max connection length: 0.000 msec (0x0000)
>> HCI Event: Command Status (0x0f) plen 4                       [hci0] 2.303493
>      LE Create Connection (0x08|0x000d) ncmd 2
>        Status: Success (0x00)
>> HCI Event: LE Meta Event (0x3e) plen 19                       [hci0] 2.308593
>      LE Connection Complete (0x01)
>        Status: Success (0x00)
>        Handle: 3585
>        Role: Master (0x00)
>        Peer address type: Random (0x01)
>        Peer address: C5:8C:97:E9:9C:81 (Static)
>        Connection interval: 70.00 msec (0x0038)
>        Connection latency: 0.00 msec (0x0000)
>        Supervision timeout: 420 msec (0x002a)
>        Master clock accuracy: 0x00
> @ Device Connected: C5:8C:97:E9:9C:81 (2) flags 0x0000
> < HCI Command: LE Start Encryption (0x08|0x0019) plen 28        [hci0] 2.308922
>        Handle: 3585
>        Random number: 0x42a37f88d3b5619c
>        Encrypted diversifier: 0x21e0
>        Long term key: 283980ebe520609d7af359b28e996572
>> HCI Event: Command Status (0x0f) plen 4                       [hci0] 2.310487
>      LE Start Encryption (0x08|0x0019) ncmd 1
>        Status: Success (0x00)
>> HCI Event: Encryption Change (0x08) plen 4                    [hci0] 2.715586
>        Status: Success (0x00)
>        Handle: 3585
>        Encryption: Enabled with AES-CCM (0x01)
> < ACL Data TX: Handle 3585 flags 0x00 dlen 11                   [hci0] 2.715867
>      ATT: Read By Type Request (0x08) len 6
>        Handle range: 0x000c-0x0010
>        Attribute type: Characteristic (0x2803)
>> ACL Data RX: Handle 3585 flags 0x02 dlen 16                   [hci0] 2.785254
>      ATT: Handle Value Notification (0x1b) len 11
>        Handle: 0x0021
>          Data: 001500b7ff00000000
>> HCI Event: Number of Completed Packets (0x13) plen 5          [hci0] 2.785496
>        Num handles: 1
>        Handle: 3585
>        Count: 1
>> ACL Data RX: Handle 3585 flags 0x02 dlen 20                   [hci0] 2.855169
>      ATT: Read By Type Response (0x09) len 15
>        Attribute data length: 7
>        Attribute data list: 2 entries
>        Handle: 0x000d
>        Value: 020e00292a
>        Handle: 0x000f
>        Value: 021000502a
> < ACL Data TX: Handle 3585 flags 0x00 dlen 7                    [hci0] 2.855447
>      ATT: Exchange MTU Request (0x02) len 2
>        Client RX MTU: 672
>> HCI Event: Number of Completed Packets (0x13) plen 5          [hci0] 2.925588
>        Num handles: 1
>        Handle: 3585
>        Count: 1
>> ACL Data RX: Handle 3585 flags 0x02 dlen 7                    [hci0] 2.995043
>      ATT: Exchange MTU Response (0x03) len 2
>        Server RX MTU: 23
> < ACL Data TX: Handle 3585 flags 0x00 dlen 7                    [hci0] 2.995278
>      ATT: Read Request (0x0a) len 2
>        Handle: 0x0010
>> HCI Event: Number of Completed Packets (0x13) plen 5          [hci0] 3.065590
>        Num handles: 1
>        Handle: 3585
>        Count: 1
>> ACL Data RX: Handle 3585 flags 0x02 dlen 12                   [hci0] 3.135107
>      ATT: Read Response (0x0b) len 7
>        Value: 025e04f3070100
>> ACL Data RX: Handle 3585 flags 0x02 dlen 16                   [hci0] 7.405125
>      LE L2CAP: Connection Parameter Update Request (0x12) ident 2 len 8
>        Min interval: 6
>        Max interval: 6
>        Slave latency: 40
>        Timeout multiplier: 300
> < ACL Data TX: Handle 3585 flags 0x00 dlen 10                   [hci0] 7.405247
>      LE L2CAP: Connection Parameter Update Response (0x13) ident 2 len 2
>        Result: Connection Parameters accepted (0x0000)
> < HCI Command: LE Connection Update (0x08|0x0013) plen 14       [hci0] 7.405276
>        Handle: 3585
>        Min connection interval: 7.50 msec (0x0006)
>        Max connection interval: 7.50 msec (0x0006)
>        Connection latency: 0x0028
>        Supervision timeout: 3000 msec (0x012c)
>        Min connection length: 0.000 msec (0x0000)
>        Max connection length: 0.000 msec (0x0000)
>> HCI Event: Command Status (0x0f) plen 4                       [hci0] 7.407611
>      LE Connection Update (0x08|0x0013) ncmd 2
>        Status: Success (0x00)
>> HCI Event: Number of Completed Packets (0x13) plen 5          [hci0] 7.475614
>        Num handles: 1
>        Handle: 3585
>        Count: 1
>> HCI Event: LE Meta Event (0x3e) plen 10                       [hci0] 8.035642
>      LE Connection Update Complete (0x03)
>        Status: Success (0x00)
>        Handle: 3585
>        Connection interval: 7.50 msec (0x0006)
>        Connection latency: 50.00 msec (0x0028)
>        Supervision timeout: 3000 msec (0x012c)
>> ACL Data RX: Handle 3585 flags 0x02 dlen 16                  [hci0] 11.695162
>      ATT: Handle Value Notification (0x1b) len 11
>        Handle: 0x0021
>          Data: 000000000000000000
>> ACL Data RX: Handle 3585 flags 0x02 dlen 16                  [hci0] 11.920069
>      ATT: Handle Value Notification (0x1b) len 11
>        Handle: 0x0021
>          Data: 000000000000000000
>> ACL Data RX: Handle 3585 flags 0x02 dlen 16                  [hci0] 11.927662
>      ATT: Handle Value Notification (0x1b) len 11
>        Handle: 0x0021
>          Data: 000000010000000000
> 
> 
> I see at first this setting:
>        Min connection interval: 50.00 msec (0x0028)
>        Max connection interval: 70.00 msec (0x0038)
> And later this setting:
>        Min connection interval: 7.50 msec (0x0006)
>        Max connection interval: 7.50 msec (0x0006)
> 
> I guess this is why it's slow at first.  I wonder why it just doesn't
> start out at 7.5 ms?  And with the somewhat slower reconnection issue
> I believe it's due to bluetoothd not polling as quickly.

this is a kernel issue with not remembering the previous connection parameters. What you see is that we start connecting with the default values and then the slave (the mouse) will correct us and tell us what connection parameters it needs. We accept them and actually change the LE link to use these parameters. However we end up forgetting them. So every time you connect this procedure keeps repeating itself.

I fixed this as well, but for that you will need a bluetooth-next kernel where I enabled the management API for passive scanning and a modified bluetoothd that will then allow you a smooth experience. If the slave updates the connection parameters we remember them for devices using auto-connection. So once the connection is triggered via passive scanning the values will be remembered.

At the moment, I have one minor issue with the re-connection within bluetoothd and once that is fixed this should be pretty instant.

Regards

Marcel

Re: LE mouse reconnect problem

[Ryan Press]

Hi Marcel,

On Sun, Jun 29, 2014 at 10:52 AM, Marcel Holtmann <marcel@holtmann.org> wro=
te:
> Hi Ryan,
>
>> I have one other question with it.  When it first reconnects the mouse
>> pointer is really jerky, like it's updating really slow.  Then after a
>> few seconds it is normal; in fact it is very responsive compared to my
>> old Bluetooth mouse.  With Windows 8.1 it reconnects lightning fast
>> when I turn it on, and it is not jerky at first.
>>
> this is a kernel issue with not remembering the previous connection param=
eters. What you see is that we start connecting with the default values and=
 then the slave (the mouse) will correct us and tell us what connection par=
ameters it needs. We accept them and actually change the LE link to use the=
se parameters. However we end up forgetting them. So every time you connect=
 this procedure keeps repeating itself.
>
> I fixed this as well, but for that you will need a bluetooth-next kernel =
where I enabled the management API for passive scanning and a modified blue=
toothd that will then allow you a smooth experience. If the slave updates t=
he connection parameters we remember them for devices using auto-connection=
. So once the connection is triggered via passive scanning the values will =
be remembered.
>
> At the moment, I have one minor issue with the re-connection within bluet=
oothd and once that is fixed this should be pretty instant.


Okay, great, glad to hear that you're already on it.  I'm really
looking forward to the seamless Bluetooth experience on Linux!  When
everything is ready and in the master branch let me know and I will
try them out.

Thanks,
Ryan

Re: LE mouse reconnect problem

[Scott James Remnant]

On Sun, Jun 29, 2014 at 2:43 AM, Marcel Holtmann <marcel@holtmann.org> wrot=
e:

> The biggest problem here is that even if you are trying to be private and=
 doing everything right, the mouse will broadcast your public address every=
 time it tries to reconnect. So thank you Microsoft for forcing us to be tr=
ackable.
>

\o/

(I'd had an open bug to investigate why this mouse wasn't
reconnecting, y'all beat me to it)

> Now the biggest problem is that with 3.15 and 3.16-rcX kernels we would n=
eed to go back to using our identity address for discovery. This means acti=
ve scanning and it means we are broadcasting our identity address to everyb=
ody when trying to find this mouse. I rather not do that.
>

I think we would rather just document that this mouse isn't going to
reconnect, since you can at least use the UI to reconnect by hand.
Switching back to active scanning on the identity address would make
our devices trackable, which is very definitely not on our wish list.

Scott
--=20
Scott James Remnant | Chrome OS Systems | keybuk@google.com | Google

Re: LE mouse reconnect problem

[Marcel Holtmann]

Hi Scott,

>> The biggest problem here is that even if you are trying to be private and doing everything right, the mouse will broadcast your public address every time it tries to reconnect. So thank you Microsoft for forcing us to be trackable.
>> 
> 
> \o/
> 
> (I'd had an open bug to investigate why this mouse wasn't
> reconnecting, y'all beat me to it)

the same applies to the HP mouse btw.

I have seen the same problem using the Microsoft and HP mice on OS X about a month ago, but I couldn't be bothered to investigate it. OS X also uses non-resolvable private addresses for scanning.

>> Now the biggest problem is that with 3.15 and 3.16-rcX kernels we would need to go back to using our identity address for discovery. This means active scanning and it means we are broadcasting our identity address to everybody when trying to find this mouse. I rather not do that.
>> 
> 
> I think we would rather just document that this mouse isn't going to
> reconnect, since you can at least use the UI to reconnect by hand.
> Switching back to active scanning on the identity address would make
> our devices trackable, which is very definitely not on our wish list.

Besides a minor issue with the GATT channel in bluetoothd on auto-reconnection, I have this nicely working now using the kernel passive background scanning. Which means we can use non-resolvable private addresses for the discovery. However the earliest kernel this goes in will be 3.17 and I still need some minor cleanups here and there to make this smooth.

What we most likely are going to do is allow discovery using identity address for 3.15 and 3.16 and then with 3.17 we are switching back to privacy for discovery.

Regards

Marcel

Re: LE mouse reconnect problem

[Scott James Remnant]

On Sun, Jun 29, 2014 at 12:19 PM, Marcel Holtmann <marcel@holtmann.org> wrote:

> the same applies to the HP mouse btw.
>

Which HP Mouse are you referring to?

An HP Mouse I have uses general connectable advertising when it wants
to reconnect.

Scott
-- 
Scott James Remnant | Chrome OS Systems | keybuk@google.com | Google

Re: LE mouse reconnect problem

[Marcel Holtmann]

Hi Scott,

>> the same applies to the HP mouse btw.
>> 
> 
> Which HP Mouse are you referring to?
> 
> An HP Mouse I have uses general connectable advertising when it wants
> to reconnect.

it says HP Mouse Z8000. And at least the one that I have is using directed advertising for re-connection.

Regards

Marcel

Re: LE mouse reconnect problem

[Scott James Remnant]

On Sun, Jun 29, 2014 at 12:56 PM, Marcel Holtmann <marcel@holtmann.org> wrote:

>>> the same applies to the HP mouse btw.
>>>
>>
>> Which HP Mouse are you referring to?
>>
>> An HP Mouse I have uses general connectable advertising when it wants
>> to reconnect.
>
> it says HP Mouse Z8000. And at least the one that I have is using directed advertising for re-connection.
>

Don't have one of those, I'll grab for testing.

The one I have just describes itself as "HP BLE Mouse"

Scott
-- 
Scott James Remnant | Chrome OS Systems | keybuk@google.com | Google

Re: LE mouse reconnect problem

[Marcel Holtmann]

Hi Ryan,

>>> I have one other question with it.  When it first reconnects the mouse
>>> pointer is really jerky, like it's updating really slow.  Then after a
>>> few seconds it is normal; in fact it is very responsive compared to my
>>> old Bluetooth mouse.  With Windows 8.1 it reconnects lightning fast
>>> when I turn it on, and it is not jerky at first.
>>> 
>> this is a kernel issue with not remembering the previous connection parameters. What you see is that we start connecting with the default values and then the slave (the mouse) will correct us and tell us what connection parameters it needs. We accept them and actually change the LE link to use these parameters. However we end up forgetting them. So every time you connect this procedure keeps repeating itself.
>> 
>> I fixed this as well, but for that you will need a bluetooth-next kernel where I enabled the management API for passive scanning and a modified bluetoothd that will then allow you a smooth experience. If the slave updates the connection parameters we remember them for devices using auto-connection. So once the connection is triggered via passive scanning the values will be remembered.
>> 
>> At the moment, I have one minor issue with the re-connection within bluetoothd and once that is fixed this should be pretty instant.
> 
> 
> Okay, great, glad to hear that you're already on it.  I'm really
> looking forward to the seamless Bluetooth experience on Linux!  When
> everything is ready and in the master branch let me know and I will
> try them out.

the current bluetooth-next tree and bluez.git should now make this work smoothly. The first connection after starting bluetoothd will still use the wrong connection parameters, but all future ones will be snappy.

Regards

Marcel

Re: LE mouse reconnect problem

[Marcel Holtmann]

Hi Scott,

>> the same applies to the HP mouse btw.
>> 
> 
> Which HP Mouse are you referring to?
> 
> An HP Mouse I have uses general connectable advertising when it wants
> to reconnect.

might want to check HCI Remote Version Information (via hcitool cmd) for that device. So what we found out today is that the Nordic based HID devices only do direct advertising. However my CSR based one does direct advertising first and if it times out, it falls back to undirected advertising.

Regards

Marcel

Re: LE mouse reconnect problem

[Ryan Press]

Hi Marcel,

On Tue, Jul 1, 2014 at 2:49 AM, Marcel Holtmann <marcel@holtmann.org> wrote=
:
> Hi Ryan,
>
>>>> I have one other question with it.  When it first reconnects the mouse
>>>> pointer is really jerky, like it's updating really slow.  Then after a
>>>> few seconds it is normal; in fact it is very responsive compared to my
>>>> old Bluetooth mouse.  With Windows 8.1 it reconnects lightning fast
>>>> when I turn it on, and it is not jerky at first.
>>>>
>>> this is a kernel issue with not remembering the previous connection par=
ameters. What you see is that we start connecting with the default values a=
nd then the slave (the mouse) will correct us and tell us what connection p=
arameters it needs. We accept them and actually change the LE link to use t=
hese parameters. However we end up forgetting them. So every time you conne=
ct this procedure keeps repeating itself.
>>>
>>> I fixed this as well, but for that you will need a bluetooth-next kerne=
l where I enabled the management API for passive scanning and a modified bl=
uetoothd that will then allow you a smooth experience. If the slave updates=
 the connection parameters we remember them for devices using auto-connecti=
on. So once the connection is triggered via passive scanning the values wil=
l be remembered.
>>>
>>> At the moment, I have one minor issue with the re-connection within blu=
etoothd and once that is fixed this should be pretty instant.
>>
>>
>> Okay, great, glad to hear that you're already on it.  I'm really
>> looking forward to the seamless Bluetooth experience on Linux!  When
>> everything is ready and in the master branch let me know and I will
>> try them out.
>
> the current bluetooth-next tree and bluez.git should now make this work s=
moothly. The first connection after starting bluetoothd will still use the =
wrong connection parameters, but all future ones will be snappy.
>
> Regards
>
> Marcel

I have installed bluetooth-next and bluez git.  I had to merge with
rc3 because rc1 wouldn't boot on my machine for some other reason.  At
first I had rfkill soft blocked when resuming from standby but then I
pulled again and it fixed it.  I saw Johan made a commit about blocked
devices maybe that was it.

So it works really well!  Connections are instant and the mouse
reconnects every time.  The only time that connection is slow is the
first time after a reboot, like you mention above; that's not really a
problem.

Thanks,
Ryan

Re: LE mouse reconnect problem

[Marcel Holtmann]

Hi Ryan,

>>>>> I have one other question with it.  When it first reconnects the mouse
>>>>> pointer is really jerky, like it's updating really slow.  Then after a
>>>>> few seconds it is normal; in fact it is very responsive compared to my
>>>>> old Bluetooth mouse.  With Windows 8.1 it reconnects lightning fast
>>>>> when I turn it on, and it is not jerky at first.
>>>>> 
>>>> this is a kernel issue with not remembering the previous connection parameters. What you see is that we start connecting with the default values and then the slave (the mouse) will correct us and tell us what connection parameters it needs. We accept them and actually change the LE link to use these parameters. However we end up forgetting them. So every time you connect this procedure keeps repeating itself.
>>>> 
>>>> I fixed this as well, but for that you will need a bluetooth-next kernel where I enabled the management API for passive scanning and a modified bluetoothd that will then allow you a smooth experience. If the slave updates the connection parameters we remember them for devices using auto-connection. So once the connection is triggered via passive scanning the values will be remembered.
>>>> 
>>>> At the moment, I have one minor issue with the re-connection within bluetoothd and once that is fixed this should be pretty instant.
>>> 
>>> 
>>> Okay, great, glad to hear that you're already on it.  I'm really
>>> looking forward to the seamless Bluetooth experience on Linux!  When
>>> everything is ready and in the master branch let me know and I will
>>> try them out.
>> 
>> the current bluetooth-next tree and bluez.git should now make this work smoothly. The first connection after starting bluetoothd will still use the wrong connection parameters, but all future ones will be snappy.
> 
> I have installed bluetooth-next and bluez git.  I had to merge with
> rc3 because rc1 wouldn't boot on my machine for some other reason.  At
> first I had rfkill soft blocked when resuming from standby but then I
> pulled again and it fixed it.  I saw Johan made a commit about blocked
> devices maybe that was it.
> 
> So it works really well!  Connections are instant and the mouse
> reconnects every time.  The only time that connection is slow is the
> first time after a reboot, like you mention above; that's not really a
> problem.

even the first time after boot should be fast now. Fast in a sense that we use the correct Connection Parameters since we remember them. The one thing it still has to do is service discovery which does take a bit indeed.

On a side note, it seems that Microsoft released a -002 version of the mouse (check the product key under your battery) that will actually fall back to using ADV_IND instead of only doing ADV_DIRECT_IND.

Regards

Marcel

Re: LE mouse reconnect problem

[d.eriksson]

Hi Marcel,

Somewhat hijacking this thread as we've been working on similar issues. 
In the Nordic Semi HID code they by default set 5sec for the "FIRST_CONN_PARAMS_UPDATE_DELAY". As a temporary fix we just se this to 50msec to force a quicker re-connect.

We're doing our pairing using mgmt, could there be something we do wrong on our end causing the CCCDs not being stored in our nrf51822, and/or on the linux side?

best
David

< HCI Command: LE Set Scan Parameters (0x08|0x000b) plen 7                                                                      [hci0] 134.414928
        Type: Active (0x01)
        Interval: 11.250 msec (0x0012)
        Window: 11.250 msec (0x0012)
        Own address type: Public (0x00)
        Filter policy: Accept all advertisement (0x00)
> HCI Event: Command Complete (0x0e) plen 4                                                                                     [hci0] 134.421589
      LE Set Scan Parameters (0x08|0x000b) ncmd 1
        Status: Success (0x00)
< HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2                                                                          [hci0] 134.421659
        Scanning: Enabled (0x01)
        Filter duplicates: Enabled (0x01)
> HCI Event: Command Complete (0x0e) plen 4                                                                                     [hci0] 134.422590
      LE Set Scan Enable (0x08|0x000c) ncmd 1
        Status: Success (0x00)
> HCI Event: LE Meta Event (0x3e) plen 12                                                                                       [hci0] 134.424481
      LE Advertising Report (0x02)
        Num reports: 1
        Event type: Connectable directed - ADV_DIRECT_IND (0x01)
        Address type: Random (0x01)
        Address: F1:4A:67:6A:B7:FF (Static)
        Data length: 0
        RSSI: -73 dBm (0xb7)
< HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2                                                                          [hci0] 134.425082
        Scanning: Disabled (0x00)
        Filter duplicates: Disabled (0x00)
> HCI Event: Command Complete (0x0e) plen 4                                                                                     [hci0] 134.425657
      LE Set Scan Enable (0x08|0x000c) ncmd 1
        Status: Success (0x00)
< HCI Command: LE Create Connection (0x08|0x000d) plen 25                                                                       [hci0] 134.426180
        Scan interval: 2.500 msec (0x0004)
        Scan window: 2.500 msec (0x0004)
        Filter policy: White list is not used (0x00)
        Peer address type: Random (0x01)
        Peer address: F1:4A:67:6A:B7:FF (Static)
        Own address type: Public (0x00)
        Min connection interval: 50.00 msec (0x0028)
        Max connection interval: 70.00 msec (0x0038)
        Connection latency: 0x0000
        Supervision timeout: 420 msec (0x002a)
        Min connection length: 0.000 msec (0x0000)
        Max connection length: 0.000 msec (0x0000)
> HCI Event: Command Status (0x0f) plen 4                                                                                       [hci0] 134.426831
      LE Create Connection (0x08|0x000d) ncmd 1
        Status: Success (0x00)
> HCI Event: LE Meta Event (0x3e) plen 19                                                                                       [hci0] 134.432082
      LE Connection Complete (0x01)
        Status: Success (0x00)
        Handle: 1025
        Role: Master (0x00)
        Peer address type: Random (0x01)
        Peer address: F1:4A:67:6A:B7:FF (Static)
        Connection interval: 70.00 msec (0x0038)
        Connection latency: 0.00 msec (0x0000)
        Supervision timeout: 420 msec (0x002a)
        Master clock accuracy: 0x01
< HCI Command: LE Start Encryption (0x08|0x0019) plen 28                                                                        [hci0] 134.441984
        Handle: 1025
        Random number: 0x3e0636865278ea8f
        Encrypted diversifier: 0x9bf8
        Long term key: fd90856caeb6478e9ff9cbeea73bdd4a
> HCI Event: Command Status (0x0f) plen 4                                                                                       [hci0] 134.442966
      LE Start Encryption (0x08|0x0019) ncmd 1
        Status: Success (0x00)
@ Discovering: 0x01 (6)
@ Device Found: F1:4A:67:6A:B7:FF (2) rssi -73 flags 0x0000
@ Discovering: 0x00 (6)
@ Device Connected: F1:4A:67:6A:B7:FF (2) flags 0x0000
> HCI Event: Encryption Change (0x08) plen 4                                                                                    [hci0] 135.019652
        Status: Success (0x00)
        Handle: 1025
        Encryption: Enabled with AES-CCM (0x01)
< ACL Data TX: Handle 1025 flags 0x00 dlen 11                                                                                   [hci0] 135.021069
      ATT: Read By Type Request (0x08) len 6
        Handle range: 0x000c-0x0010
        Attribute type: Characteristic (0x2803)
> ACL Data RX: Handle 1025 flags 0x02 dlen 20                                                                                   [hci0] 135.298900
      ATT: Read By Type Response (0x09) len 15
        Attribute data length: 7
        Attribute data list: 2 entries
        Handle: 0x000d
        Value: 020e00292a
        Handle: 0x000f
        Value: 021000502a
< ACL Data TX: Handle 1025 flags 0x00 dlen 7                                                                                    [hci0] 135.299576
      ATT: Exchange MTU Request (0x02) len 2
        Client RX MTU: 672
> HCI Event: Number of Completed Packets (0x13) plen 5                                                                          [hci0] 135.327848
        Num handles: 1
        Handle: 1025
        Count: 1
> ACL Data RX: Handle 1025 flags 0x02 dlen 7                                                                                    [hci0] 135.438638
      ATT: Exchange MTU Response (0x03) len 2
        Server RX MTU: 23
< ACL Data TX: Handle 1025 flags 0x00 dlen 7                                                                                    [hci0] 135.439219
      ATT: Read Request (0x0a) len 2
        Handle: 0x0010
> HCI Event: Number of Completed Packets (0x13) plen 5                                                                          [hci0] 135.467853
        Num handles: 1
        Handle: 1025
        Count: 1
> ACL Data RX: Handle 1025 flags 0x02 dlen 12                                                                                   [hci0] 135.578881
      ATT: Read Response (0x0b) len 7
        Value: 02672302000100
> HCI Event: Number of Completed Packets (0x13) plen 5                                                                          [hci0] 135.607860
        Num handles: 1
        Handle: 1025
        Count: 1
> ACL Data RX: Handle 1025 flags 0x02 dlen 16                                                                                   [hci0] 139.499097
      LE L2CAP: Connection Parameter Update Request (0x12) ident 2 len 8
        Min interval: 6
        Max interval: 24
        Slave latency: 6
        Timeout multiplier: 30
< ACL Data TX: Handle 1025 flags 0x00 dlen 10                                                                                   [hci0] 139.499205
      LE L2CAP: Connection Parameter Update Response (0x13) ident 2 len 2
        Result: Connection Parameters accepted (0x0000)
< HCI Command: LE Connection Update (0x08|0x0013) plen 14                                                                       [hci0] 139.499244
        Handle: 1025
        Min connection interval: 7.50 msec (0x0006)
        Max connection interval: 30.00 msec (0x0018)
        Connection latency: 0x0006
        Supervision timeout: 300 msec (0x001e)
        Min connection length: 0.625 msec (0x0001)
        Max connection length: 0.625 msec (0x0001)
> HCI Event: Command Status (0x0f) plen 4                                                                                       [hci0] 139.499818
      LE Connection Update (0x08|0x0013) ncmd 1
        Status: Success (0x00)
> HCI Event: Number of Completed Packets (0x13) plen 5                                                                          [hci0] 139.738212
        Num handles: 1
        Handle: 1025
        Count: 1
> ACL Data RX: Handle 1025 flags 0x02 dlen 10                                                                                   [hci0] 139.997853
      ATT: Handle Value Notification (0x1b) len 5
        Handle: 0x0019
          Data: 012401
> HCI Event: LE Meta Event (0x3e) plen 10                                                                                       [hci0] 139.999622
      LE Connection Update Complete (0x03)
        Status: Success (0x00)
        Handle: 1025
        Connection interval: 28.75 msec (0x0017)
        Connection latency: 7.50 msec (0x0006)
        Supervision timeout: 300 msec (0x001e)




On 29 Jun 2014, at 19:52, Marcel Holtmann <marcel@holtmann.org> wrote:

> this is a kernel issue with not remembering the previous connection parameters. What you see is that we start connecting with the default values and then the slave (the mouse) will correct us and tell us what connection parameters it needs. We accept them and actually change the LE link to use these parameters. However we end up forgetting them. So every time you connect this procedure keeps repeating itself.
> 
> I fixed this as well, but for that you will need a bluetooth-next kernel where I enabled the management API for passive scanning and a modified bluetoothd that will then allow you a smooth experience. If the slave updates the connection parameters we remember them for devices using auto-connection. So once the connection is triggered via passive scanning the values will be remembered.
> 
> At the moment, I have one minor issue with the re-connection within bluetoothd and once that is fixed this should be pretty instant.
> 
> Regards
> 
> Marcel

Re: LE mouse reconnect problem

[Marcel Holtmann]

Hi David,

> Somewhat hijacking this thread as we've been working on similar issues. 
> In the Nordic Semi HID code they by default set 5sec for the "FIRST_CONN_PARAMS_UPDATE_DELAY". As a temporary fix we just se this to 50msec to force a quicker re-connect.
> 
> We're doing our pairing using mgmt, could there be something we do wrong on our end causing the CCCDs not being stored in our nrf51822, and/or on the linux side?

try the latest bluetooth-next and bluetoothd. With the passive scanning and remembering of the connection parameters this should also be instant now. The advantage is that we start out with the correct parameters in the first place and thus the HID devices does not have to change them.

Regards

Marcel

Re: LE mouse reconnect problem

[d.eriksson]

Hi Marcel,

Sounds great. I really wanted the passive scan option as well. 
Would bluetooth-next work under 3.13?

Ehrm, where can I read up a bit on the plans/news for bluetooth-next and more info on the ideas of user vs kernel space?


best David

On 03 Jul 2014, at 17:41, Marcel Holtmann <marcel@holtmann.org> wrote:

> Hi David,
> 
>> Somewhat hijacking this thread as we've been working on similar issues. 
>> In the Nordic Semi HID code they by default set 5sec for the "FIRST_CONN_PARAMS_UPDATE_DELAY". As a temporary fix we just se this to 50msec to force a quicker re-connect.
>> 
>> We're doing our pairing using mgmt, could there be something we do wrong on our end causing the CCCDs not being stored in our nrf51822, and/or on the linux side?
> 
> try the latest bluetooth-next and bluetoothd. With the passive scanning and remembering of the connection parameters this should also be instant now. The advantage is that we start out with the correct parameters in the first place and thus the HID devices does not have to change them.
> 
> Regards
> 
> Marcel
> 
> --
> 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

Re: LE mouse reconnect problem

[Marcel Holtmann]

Hi David,

please don't top post on this mailing list.

> Sounds great. I really wanted the passive scan option as well. 
> Would bluetooth-next work under 3.13?

you can try the backports tree. It should be possible to run it with 3.13 kernel.

> Ehrm, where can I read up a bit on the plans/news for bluetooth-next and more info on the ideas of user vs kernel space?

I think doc/mgmt-api.txt is pretty much updated on what new stuff is coming.

Regards

Marcel

Re: LE mouse reconnect problem

[Scott James Remnant]

On Thu, Jul 3, 2014 at 9:40 AM,  <d.eriksson@me.com> wrote:

> Sounds great. I really wanted the passive scan option as well.
> Would bluetooth-next work under 3.13?
>

Chrome OS is running bluetooth-next on as old a kernel as 3.8 -- we
have an unshipped backport all the way to 3.4 -- so yes, it's
definitely possible.

Scott
-- 
Scott James Remnant | Chrome OS Systems | keybuk@google.com | Google

Re: LE mouse reconnect problem

[Scott James Remnant]

Hey Marcel,

On Tue, Jul 1, 2014 at 9:01 AM, Marcel Holtmann <marcel@holtmann.org> wrote:

>>> the same applies to the HP mouse btw.
>>>
>>
>> Which HP Mouse are you referring to?
>>
>> An HP Mouse I have uses general connectable advertising when it wants
>> to reconnect.
>
> might want to check HCI Remote Version Information (via hcitool cmd) for that device. So what we found out today is that the Nordic based HID devices only do direct advertising. However my CSR based one does direct advertising first and if it times out, it falls back to undirected advertising.
>

I confirm this at my end.

Our CSR-based devices are the ones falling back to undirected, while
the Nordic ones are not.

In the Z8000 case at least there's a cute blue Connect button that
resets it back to undirected advertising.

Scott
-- 
Scott James Remnant | Chrome OS Systems | keybuk@google.com | Google