On Mon, Jun 1, 2015 at 8:58 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 >> ? > > 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. > > 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 > -- 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
