Hi, I think I found a bug:
1. Have iPhone and Linux machine running latest BlueZ on latest
kernel. iPhone have random mac "ABC".
2. Connect from BlueZ to iPhone, pair with PIN. iPhone real mac
address "XXX" is being shown right now. I can connect to it form
bluetoothctl using "XXX" address, btmon shows it's random mac address
"ABC" in connect request.
3. Restart bluetooth on iPhone. It's random mac is rotated to "BCD".
Try to connect from bluetoothctl using "XXX", btomon still shows old
mac address "ABC" in connect request, therefore it'll fail and will be
unable to connect.
That's a bug is, right ? BlueZ should be smart, and for paired device
it should start a "Selective Connection Establishment Procedure"
instead of "Auto Connection Establishment Procedure", as described in
BT spec 4.2 [Vol 3, Part C] 9.3.7 .
If I now manually start discovery before calling connect BlueZ would
pick new iPhone address, "BCD" and use it for connection if I try to
connect to "XXX".
Is that something that should be fixed ? If yes I'll spend some time on it.
Hi Jakub,
>>>>> 1. Have iPhone and Linux machine running latest BlueZ on latest
>>>>> kernel. iPhone have random mac "ABC".
>>>>> 2. Connect from BlueZ to iPhone, pair with PIN. iPhone real mac
>>>>> address "XXX" is being shown right now. I can connect to it form
>>>>> bluetoothctl using "XXX" address, btmon shows it's random mac address
>>>>> "ABC" in connect request.
>>>>>
>>>>> 3. Restart bluetooth on iPhone. It's random mac is rotated to "BCD".
>>>>> Try to connect from bluetoothctl using "XXX", btomon still shows old
>>>>> mac address "ABC" in connect request, therefore it'll fail and will be
>>>>> unable to connect.
>>>>>
>>>>> That's a bug is, right ? BlueZ should be smart, and for paired device
>>>>> it should start a "Selective Connection Establishment Procedure"
>>>>> instead of "Auto Connection Establishment Procedure", as described in
>>>>> BT spec 4.2 [Vol 3, Part C] 9.3.7 .
>>>>>
>>>>>
>>>>> If I now manually start discovery before calling connect BlueZ would
>>>>> pick new iPhone address, "BCD" and use it for connection if I try to
>>>>> connect to "XXX".
>>>>>
>>>>> Is that something that should be fixed ? If yes I'll spend some time on it.
>>>>
>>>> I think the problem you see is that we call HCI LE Create Connection directly without doing a scan first. This has been long on the list that we should actually scan to find the device first and only then call HCI LE Create Connection.
>>>
>>> Should scan happen before connecting only for paired devices using RPA
>>> ? Scanning for non-paired devices won't really do nothing good, right
>>> ?
>>
>> it is required for devices using RPA. We can do a passive scan without the whitelist in that case. For all other cases it makes no difference, but it also doesn’t do any harm. Actually HCI LE Create Connection will scan as well. Most likely doing a passive scan and only trying to call HCI LE Create Connection when we actually saw the device gives us better latency when multiple LE connection attempt are requested at the same time. Right now calling HCI LE Create Connection is a big hammer that will make any other connection attempt wait. Normally that is not problematic if the device is in range and advertising. If it is not, then this might stall everybody else.
>
> So I played with that, and it looks like adding non paired device to
> kernel whitelist through "MGMT_ADD_DEVICE" doesn't work, so I fixed
> that only for paired devices, would probably require kernel changes to
> make it also work for non-paired devices.
the kernel needs to know the IRK as well. It either gets that via Load Identity Resolving Keys or remembers it by itself after you paired. You could try to manually load the IRK and then will see that it starts working.
Regards
Marcel
On Mon, Jun 1, 2015 at 8:58 PM, Marcel Holtmann <[email protected]> wrote=
:
> Hi Jakub,
>
>>>> 1. Have iPhone and Linux machine running latest BlueZ on latest
>>>> kernel. iPhone have random mac "ABC".
>>>> 2. Connect from BlueZ to iPhone, pair with PIN. iPhone real mac
>>>> address "XXX" is being shown right now. I can connect to it form
>>>> bluetoothctl using "XXX" address, btmon shows it's random mac address
>>>> "ABC" in connect request.
>>>>
>>>> 3. Restart bluetooth on iPhone. It's random mac is rotated to "BCD".
>>>> Try to connect from bluetoothctl using "XXX", btomon still shows old
>>>> mac address "ABC" in connect request, therefore it'll fail and will be
>>>> unable to connect.
>>>>
>>>> That's a bug is, right ? BlueZ should be smart, and for paired device
>>>> it should start a "Selective Connection Establishment Procedure"
>>>> instead of "Auto Connection Establishment Procedure", as described in
>>>> BT spec 4.2 [Vol 3, Part C] 9.3.7 .
>>>>
>>>>
>>>> If I now manually start discovery before calling connect BlueZ would
>>>> pick new iPhone address, "BCD" and use it for connection if I try to
>>>> connect to "XXX".
>>>>
>>>> Is that something that should be fixed ? If yes I'll spend some time o=
n it.
>>>
>>> I think the problem you see is that we call HCI LE Create Connection di=
rectly without doing a scan first. This has been long on the list that we s=
hould actually scan to find the device first and only then call HCI LE Crea=
te Connection.
>>
>> Should scan happen before connecting only for paired devices using RPA
>> ? Scanning for non-paired devices won't really do nothing good, right
>> ?
>
> it is required for devices using RPA. We can do a passive scan without th=
e whitelist in that case. For all other cases it makes no difference, but i=
t also doesn=E2=80=99t do any harm. Actually HCI LE Create Connection will =
scan as well. Most likely doing a passive scan and only trying to call HCI =
LE Create Connection when we actually saw the device gives us better latenc=
y when multiple LE connection attempt are requested at the same time. Right=
now calling HCI LE Create Connection is a big hammer that will make any ot=
her connection attempt wait. Normally that is not problematic if the device=
is in range and advertising. If it is not, then this might stall everybody=
else.
So I played with that, and it looks like adding non paired device to
kernel whitelist through "MGMT_ADD_DEVICE" doesn't work, so I fixed
that only for paired devices, would probably require kernel changes to
make it also work for non-paired devices.
>
> Actually we already have the background scanning and connection logic. In=
the end any connection attempt should just be temporarily added to that co=
nnection list. The existing code would do the right trick of utilising the =
whitelist when possible. So it might be as simple as converting the code pa=
th coming via L2CAP connect() into just using the same code path as the aut=
omatic connection handling.
>
>>> Check debugfs entries in /sys/kernel/debug/bluetooth/hci0 that the IRK =
list really lists the IRK and last known RPA of the iPhone. That makes sure=
that we could resolve the address. And then try to scan first before tryin=
g to connect again. If that then does the trick and updates the known RPA o=
f the iPhone to the new one, then it is problem that we do not scan before =
calling connect.
>>
>> Scanning first before trying to connect fixes the problem. I'll try to f=
ix that.
>
> We should have fixed that a long time ago. Seems it just has been forgott=
en. Thanks for looking into that.
>
> Regards
>
> Marcel
>
Hi Jakub,
>>> 1. Have iPhone and Linux machine running latest BlueZ on latest
>>> kernel. iPhone have random mac "ABC".
>>> 2. Connect from BlueZ to iPhone, pair with PIN. iPhone real mac
>>> address "XXX" is being shown right now. I can connect to it form
>>> bluetoothctl using "XXX" address, btmon shows it's random mac address
>>> "ABC" in connect request.
>>>
>>> 3. Restart bluetooth on iPhone. It's random mac is rotated to "BCD".
>>> Try to connect from bluetoothctl using "XXX", btomon still shows old
>>> mac address "ABC" in connect request, therefore it'll fail and will be
>>> unable to connect.
>>>
>>> That's a bug is, right ? BlueZ should be smart, and for paired device
>>> it should start a "Selective Connection Establishment Procedure"
>>> instead of "Auto Connection Establishment Procedure", as described in
>>> BT spec 4.2 [Vol 3, Part C] 9.3.7 .
>>>
>>>
>>> If I now manually start discovery before calling connect BlueZ would
>>> pick new iPhone address, "BCD" and use it for connection if I try to
>>> connect to "XXX".
>>>
>>> Is that something that should be fixed ? If yes I'll spend some time on it.
>>
>> I think the problem you see is that we call HCI LE Create Connection directly without doing a scan first. This has been long on the list that we should actually scan to find the device first and only then call HCI LE Create Connection.
>
> Should scan happen before connecting only for paired devices using RPA
> ? Scanning for non-paired devices won't really do nothing good, right
> ?
it is required for devices using RPA. We can do a passive scan without the whitelist in that case. For all other cases it makes no difference, but it also doesn’t do any harm. Actually HCI LE Create Connection will scan as well. Most likely doing a passive scan and only trying to call HCI LE Create Connection when we actually saw the device gives us better latency when multiple LE connection attempt are requested at the same time. Right now calling HCI LE Create Connection is a big hammer that will make any other connection attempt wait. Normally that is not problematic if the device is in range and advertising. If it is not, then this might stall everybody else.
Actually we already have the background scanning and connection logic. In the end any connection attempt should just be temporarily added to that connection list. The existing code would do the right trick of utilising the whitelist when possible. So it might be as simple as converting the code path coming via L2CAP connect() into just using the same code path as the automatic connection handling.
>> Check debugfs entries in /sys/kernel/debug/bluetooth/hci0 that the IRK list really lists the IRK and last known RPA of the iPhone. That makes sure that we could resolve the address. And then try to scan first before trying to connect again. If that then does the trick and updates the known RPA of the iPhone to the new one, then it is problem that we do not scan before calling connect.
>
> Scanning first before trying to connect fixes the problem. I'll try to fix that.
We should have fixed that a long time ago. Seems it just has been forgotten. Thanks for looking into that.
Regards
Marcel
Hi Marcel,
On Mon, Jun 1, 2015 at 7:56 PM, Marcel Holtmann <[email protected]> wrote=
:
> Hi Jakub,
>
>> 1. Have iPhone and Linux machine running latest BlueZ on latest
>> kernel. iPhone have random mac "ABC".
>> 2. Connect from BlueZ to iPhone, pair with PIN. iPhone real mac
>> address "XXX" is being shown right now. I can connect to it form
>> bluetoothctl using "XXX" address, btmon shows it's random mac address
>> "ABC" in connect request.
>>
>> 3. Restart bluetooth on iPhone. It's random mac is rotated to "BCD".
>> Try to connect from bluetoothctl using "XXX", btomon still shows old
>> mac address "ABC" in connect request, therefore it'll fail and will be
>> unable to connect.
>>
>> That's a bug is, right ? BlueZ should be smart, and for paired device
>> it should start a "Selective Connection Establishment Procedure"
>> instead of "Auto Connection Establishment Procedure", as described in
>> BT spec 4.2 [Vol 3, Part C] 9.3.7 .
>>
>>
>> If I now manually start discovery before calling connect BlueZ would
>> pick new iPhone address, "BCD" and use it for connection if I try to
>> connect to "XXX".
>>
>> Is that something that should be fixed ? If yes I'll spend some time on =
it.
>
> I think the problem you see is that we call HCI LE Create Connection dire=
ctly without doing a scan first. This has been long on the list that we sho=
uld actually scan to find the device first and only then call HCI LE Create=
Connection.
Should scan happen before connecting only for paired devices using RPA
? Scanning for non-paired devices won't really do nothing good, right
?
>
> Check debugfs entries in /sys/kernel/debug/bluetooth/hci0 that the IRK li=
st really lists the IRK and last known RPA of the iPhone. That makes sure t=
hat we could resolve the address. And then try to scan first before trying =
to connect again. If that then does the trick and updates the known RPA of =
the iPhone to the new one, then it is problem that we do not scan before ca=
lling connect.
Scanning first before trying to connect fixes the problem. I'll try to fix =
that.
>
> Regards
>
> Marcel
>
Hi Jakub,
> 1. Have iPhone and Linux machine running latest BlueZ on latest
> kernel. iPhone have random mac "ABC".
> 2. Connect from BlueZ to iPhone, pair with PIN. iPhone real mac
> address "XXX" is being shown right now. I can connect to it form
> bluetoothctl using "XXX" address, btmon shows it's random mac address
> "ABC" in connect request.
>
> 3. Restart bluetooth on iPhone. It's random mac is rotated to "BCD".
> Try to connect from bluetoothctl using "XXX", btomon still shows old
> mac address "ABC" in connect request, therefore it'll fail and will be
> unable to connect.
>
> That's a bug is, right ? BlueZ should be smart, and for paired device
> it should start a "Selective Connection Establishment Procedure"
> instead of "Auto Connection Establishment Procedure", as described in
> BT spec 4.2 [Vol 3, Part C] 9.3.7 .
>
>
> If I now manually start discovery before calling connect BlueZ would
> pick new iPhone address, "BCD" and use it for connection if I try to
> connect to "XXX".
>
> Is that something that should be fixed ? If yes I'll spend some time on it.
I think the problem you see is that we call HCI LE Create Connection directly without doing a scan first. This has been long on the list that we should actually scan to find the device first and only then call HCI LE Create Connection.
Check debugfs entries in /sys/kernel/debug/bluetooth/hci0 that the IRK list really lists the IRK and last known RPA of the iPhone. That makes sure that we could resolve the address. And then try to scan first before trying to connect again. If that then does the trick and updates the known RPA of the iPhone to the new one, then it is problem that we do not scan before calling connect.
Regards
Marcel