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