Re: Unable to re-connect paired LE device after MAC rotation

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Marcel,

On Mon, Jun 1, 2015 at 7:56 PM, Marcel Holtmann <marcel@xxxxxxxxxxxx> 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 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
?

>
> 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.

>
> Regards
>
> Marcel
>
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Bluez Devel]     [Linux Wireless Networking]     [Linux Wireless Personal Area Networking]     [Linux ATH6KL]     [Linux USB Devel]     [Linux Media Drivers]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Big List of Linux Books]

  Powered by Linux