From: Luiz Augusto von Dentz <[email protected]>
bdaddr_type shall only matter for controllers supporting LE otherwise
it may cause BDADDR_BREDR to be used for things like LE ATT socket
listen breaking reconnections.
---
src/adapter.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/adapter.c b/src/adapter.c
index b81b4e8..b134709 100644
--- a/src/adapter.c
+++ b/src/adapter.c
@@ -8085,7 +8085,7 @@ static void read_info_complete(uint8_t status, uint16_t length,
}
} else {
bacpy(&adapter->bdaddr, &rp->bdaddr);
- if (adapter->supported_settings & MGMT_SETTING_BREDR)
+ if (!(adapter->supported_settings & MGMT_SETTING_LE))
adapter->bdaddr_type = BDADDR_BREDR;
else
adapter->bdaddr_type = BDADDR_LE_PUBLIC;
--
2.7.4
Thanks for you reply.
now,I make the mouse work again, it's very strang issue.
Yes, as you said, set privacy command must be available before hci0
powered, so I have remove udev rules that run 'hciconfig hci0 up'
I think that may be the root cause of this issue.
On Wed, Nov 16, 2016 at 8:06 PM, Luiz Augusto von Dentz
<[email protected]> wrote:
> Hi,
>
> On Tue, Nov 15, 2016 at 2:45 AM, Trump DD <[email protected]> wrote:
>> Hi
>> compare the ok.log and failed.log generate by bluetoothd, I found
>> that the first time startup bluetoothd, a error message was presented
>> " Failed to set privacy: Rejected "
>>
>> bluetoothd[9988]: Failed to set privacy: Rejected (0x0b)
>> bluetoothd[9988]: src/adapter.c:new_settings_callback() Settings: 0x00000ac5
>> bluetoothd[9988]: src/adapter.c:settings_changed() Changed settings: 0x00000004
>> bluetoothd[9988]: src/adapter.c:load_link_keys_complete() link keys
>> loaded for hci0
>> bluetoothd[9988]: src/adapter.c:load_ltks_complete() LTKs loaded for hci0
>> bluetoothd[9988]: src/adapter.c:load_irks_complete() IRKs loaded for hci0
>> bluetoothd[9988]: src/adapter.c:load_conn_params_complete() Connection
>> Parameters loaded for hci0
>> bluetoothd[9988]: src/adapter.c:add_device_complete()
>> C0:11:5B:C6:55:DF (2) added to kernel connect list
>> bluetoothd[9988]: src/adapter.c:get_connections_complete() Connection count: 0
>>
>> In /etc/bluetooth/main.conf I have set
>> "
>> Privacy=device
>> "
>>
>> Why the first time bluetoothd startup failed to set privacy, the
>> second time bluetoothd startup all works right ?
>
> Rejected is probably due to adapter being powered, perhaps hciconfig
> or something is messing up the state during reboot, but this shouldn't
> affect the address type thus Im not sure why it will cause the failure
> loop. Also note that if privacy is used you may not be able to
> reconnect using passive scanning, at least the 2 mouses I have here
> seems to be using direct advertising to public address but with
> privacy we are scanning using the random address the controller just
> filter any advertisement to the public address.
--
Thanks
Hi,
On Tue, Nov 15, 2016 at 2:45 AM, Trump DD <[email protected]> wrote:
> Hi
> compare the ok.log and failed.log generate by bluetoothd, I found
> that the first time startup bluetoothd, a error message was presented
> " Failed to set privacy: Rejected "
>
> bluetoothd[9988]: Failed to set privacy: Rejected (0x0b)
> bluetoothd[9988]: src/adapter.c:new_settings_callback() Settings: 0x00000ac5
> bluetoothd[9988]: src/adapter.c:settings_changed() Changed settings: 0x00000004
> bluetoothd[9988]: src/adapter.c:load_link_keys_complete() link keys
> loaded for hci0
> bluetoothd[9988]: src/adapter.c:load_ltks_complete() LTKs loaded for hci0
> bluetoothd[9988]: src/adapter.c:load_irks_complete() IRKs loaded for hci0
> bluetoothd[9988]: src/adapter.c:load_conn_params_complete() Connection
> Parameters loaded for hci0
> bluetoothd[9988]: src/adapter.c:add_device_complete()
> C0:11:5B:C6:55:DF (2) added to kernel connect list
> bluetoothd[9988]: src/adapter.c:get_connections_complete() Connection count: 0
>
> In /etc/bluetooth/main.conf I have set
> "
> Privacy=device
> "
>
> Why the first time bluetoothd startup failed to set privacy, the
> second time bluetoothd startup all works right ?
Rejected is probably due to adapter being powered, perhaps hciconfig
or something is messing up the state during reboot, but this shouldn't
affect the address type thus Im not sure why it will cause the failure
loop. Also note that if privacy is used you may not be able to
reconnect using passive scanning, at least the 2 mouses I have here
seems to be using direct advertising to public address but with
privacy we are scanning using the random address the controller just
filter any advertisement to the public address.
Hi
compare the ok.log and failed.log generate by bluetoothd, I found
that the first time startup bluetoothd, a error message was presented
" Failed to set privacy: Rejected "
bluetoothd[9988]: Failed to set privacy: Rejected (0x0b)
bluetoothd[9988]: src/adapter.c:new_settings_callback() Settings: 0x00000ac5
bluetoothd[9988]: src/adapter.c:settings_changed() Changed settings: 0x00000004
bluetoothd[9988]: src/adapter.c:load_link_keys_complete() link keys
loaded for hci0
bluetoothd[9988]: src/adapter.c:load_ltks_complete() LTKs loaded for hci0
bluetoothd[9988]: src/adapter.c:load_irks_complete() IRKs loaded for hci0
bluetoothd[9988]: src/adapter.c:load_conn_params_complete() Connection
Parameters loaded for hci0
bluetoothd[9988]: src/adapter.c:add_device_complete()
C0:11:5B:C6:55:DF (2) added to kernel connect list
bluetoothd[9988]: src/adapter.c:get_connections_complete() Connection count: 0
In /etc/bluetooth/main.conf I have set
"
Privacy=device
"
Why the first time bluetoothd startup failed to set privacy, the
second time bluetoothd startup all works right ?
On Mon, Nov 14, 2016 at 10:12 PM, Luiz Augusto von Dentz
<[email protected]> wrote:
> Hi,
>
> On Mon, Nov 14, 2016 at 3:53 PM, Trump DD <[email protected]> wrote:
>> this patch look like fix part bug of BLE devices reconnect
>>
>> when I restart bluetoothd , all works fine.
>> such as:
>> systemctl stop bluetooth
>> systemctl start bluetooth
>> click BLE mouse button, reconnect success.
>>
>> but this issue existed after apply this patch
>> 1. reboot computer, bluetoothd the first time startup, BLE mouse
>> reconnect failed with loop
>> Connected: yes
>> Connected: no
>> ...
>> ...
>
> Are you sure this is exact the same version after you reboot? Because
> from the logs it looks like the exact same problem so perhaps you have
> the older version being restored or something else is loading the old
> binary, for me this works all the time even after rebooting, or
> actually running a vm, but Im running it from source directly.
--
Thanks
Hi,
On Mon, Nov 14, 2016 at 3:53 PM, Trump DD <[email protected]> wrote:
> this patch look like fix part bug of BLE devices reconnect
>
> when I restart bluetoothd , all works fine.
> such as:
> systemctl stop bluetooth
> systemctl start bluetooth
> click BLE mouse button, reconnect success.
>
> but this issue existed after apply this patch
> 1. reboot computer, bluetoothd the first time startup, BLE mouse
> reconnect failed with loop
> Connected: yes
> Connected: no
> ...
> ...
Are you sure this is exact the same version after you reboot? Because
from the logs it looks like the exact same problem so perhaps you have
the older version being restored or something else is loading the old
binary, for me this works all the time even after rebooting, or
actually running a vm, but Im running it from source directly.
this patch look like fix part bug of BLE devices reconnect
when I restart bluetoothd , all works fine.
such as:
systemctl stop bluetooth
systemctl start bluetooth
click BLE mouse button, reconnect success.
but this issue existed after apply this patch
1. reboot computer, bluetoothd the first time startup, BLE mouse
reconnect failed with loop
Connected: yes
Connected: no
...
...
with log
bluetoothd[471]: src/adapter.c:connected_callback() hci0 device
C0:11:5B:C6:55:DF connected eir_len 27
bluetoothd[471]: src/adapter.c:dev_disconnected() Device
C0:11:5B:C6:55:DF disconnected, reason 0
bluetoothd[471]: src/adapter.c:adapter_remove_connection()
bluetoothd[471]: plugins/policy.c:disconnect_cb() reason 0
bluetoothd[471]: src/adapter.c:bonding_attempt_complete() hci0 bdaddr
C0:11:5B:C6:55:DF type 2 status 0xe
bluetoothd[471]: src/device.c:device_bonding_complete() bonding (nil)
status 0x0e
bluetoothd[471]: src/device.c:device_bonding_failed() status 14
bluetoothd[471]: src/adapter.c:resume_discovery()
bluetoothd[471]: src/adapter.c:connected_callback() hci0 device
C0:11:5B:C6:55:DF connected eir_len 27
bluetoothd[471]: src/adapter.c:dev_disconnected() Device
C0:11:5B:C6:55:DF disconnected, reason 0
bluetoothd[471]: src/adapter.c:adapter_remove_connection()
bluetoothd[471]: plugins/policy.c:disconnect_cb() reason 0
bluetoothd[471]: src/adapter.c:bonding_attempt_complete() hci0 bdaddr
C0:11:5B:C6:55:DF type 2 status 0xe
bluetoothd[471]: src/device.c:device_bonding_complete() bonding (nil)
status 0x0e
bluetoothd[471]: src/device.c:device_bonding_failed() status 14
bluetoothd[471]: src/adapter.c:resume_discovery()
bluetoothd[471]: src/adapter.c:connected_callback() hci0 device
C0:11:5B:C6:55:DF connected eir_len 27
bluetoothd[471]: src/adapter.c:dev_disconnected() Device
C0:11:5B:C6:55:DF disconnected, reason 0
bluetoothd[471]: src/adapter.c:adapter_remove_connection()
bluetoothd[471]: plugins/policy.c:disconnect_cb() reason 0
bluetoothd[471]: src/adapter.c:bonding_attempt_complete() hci0 bdaddr
C0:11:5B:C6:55:DF type 2 status 0xe
bluetoothd[471]: src/device.c:device_bonding_complete() bonding (nil)
status 0x0e
bluetoothd[471]: src/device.c:device_bonding_failed() status 14
bluetoothd[471]: src/adapter.c:resume_discovery()
bluetoothd[471]: src/adapter.c:connected_callback() hci0 device
C0:11:5B:C6:55:DF connected eir_len 27
bluetoothd[471]: src/adapter.c:dev_disconnected() Device
C0:11:5B:C6:55:DF disconnected, reason 0
bluetoothd[471]: src/adapter.c:adapter_remove_connection()
bluetoothd[471]: plugins/policy.c:disconnect_cb() reason 0
bluetoothd[471]: src/adapter.c:bonding_attempt_complete() hci0 bdaddr
C0:11:5B:C6:55:DF type 2 status 0xe
bluetoothd[471]: src/device.c:device_bonding_complete() bonding (nil)
status 0x0e
bluetoothd[471]: src/device.c:device_bonding_failed() status 14
bluetoothd[471]: src/adapter.c:resume_discovery()
On Mon, Nov 14, 2016 at 7:51 PM, Johan Hedberg <[email protected]> wrote:
> Hi Luiz,
>
> On Mon, Nov 14, 2016, Luiz Augusto von Dentz wrote:
>> bdaddr_type shall only matter for controllers supporting LE otherwise
>> it may cause BDADDR_BREDR to be used for things like LE ATT socket
>> listen breaking reconnections.
>> ---
>> src/adapter.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Applied. Thanks.
>
> Johan
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Thanks
Hi Luiz,
On Mon, Nov 14, 2016, Luiz Augusto von Dentz wrote:
> bdaddr_type shall only matter for controllers supporting LE otherwise
> it may cause BDADDR_BREDR to be used for things like LE ATT socket
> listen breaking reconnections.
> ---
> src/adapter.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Applied. Thanks.
Johan