[PATCH BlueZ] core/adapter: Fix using wrong address type to listen ATT

[PATCH BlueZ] core/adapter: Fix using wrong address type to listen ATT

[Luiz Augusto von Dentz]

From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>

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

Re: [PATCH BlueZ] core/adapter: Fix using wrong address type to listen ATT

[Johan Hedberg]

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

Re: [PATCH BlueZ] core/adapter: Fix using wrong address type to listen ATT

[Trump DD]

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 <johan.hedberg@gmail.com> 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Thanks

Re: [PATCH BlueZ] core/adapter: Fix using wrong address type to listen ATT

[Luiz Augusto von Dentz]

Hi,

On Mon, Nov 14, 2016 at 3:53 PM, Trump DD <wrxzzj@gmail.com> 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.

Re: [PATCH BlueZ] core/adapter: Fix using wrong address type to listen ATT

[Trump DD]

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
<luiz.dentz@gmail.com> wrote:
> Hi,
>
> On Mon, Nov 14, 2016 at 3:53 PM, Trump DD <wrxzzj@gmail.com> 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

Re: [PATCH BlueZ] core/adapter: Fix using wrong address type to listen ATT

[Luiz Augusto von Dentz]

Hi,

On Tue, Nov 15, 2016 at 2:45 AM, Trump DD <wrxzzj@gmail.com> 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.

Re: [PATCH BlueZ] core/adapter: Fix using wrong address type to listen ATT

[Trump DD]

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
<luiz.dentz@gmail.com> wrote:
> Hi,
>
> On Tue, Nov 15, 2016 at 2:45 AM, Trump DD <wrxzzj@gmail.com> 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