Hi Marcel, On Tue, Nov 24, 2015, Marcel Holtmann wrote: > >> HCI Event: Command Complete (0x0e) plen 4 [hci0] 17.672048 > > LE Create Connection Cancel (0x08|0x000e) ncmd 1 > > Status: Success (0x00) > >> HCI Event: LE Meta Event (0x3e) plen 19 [hci0] 17.674036 > > LE Connection Complete (0x01) > > Status: Unknown Connection Identifier (0x02) > > Handle: 32 > > Role: Master (0x00) > > Peer address type: Public (0x00) > > Peer address: 88:0F:10:9D:EB:42 (OUI 88-0F-10) > > Connection interval: 67.50 msec (0x0036) > > Connection latency: 0.00 msec (0x0000) > > Supervision timeout: 420 msec (0x002a) > > Master clock accuracy: 0x00 > > @ Connect Failed: 88:0F:10:9D:EB:42 (1) status 0x02 > > This one still needs to be fixed. It is a bug. The implementation is > too naive. The unknown connection identifier is actually the success > case for LE Create Connection Cancel command. And since we keep trying > until the connection timeout hits, this is not an error at this point. I think we need to differentiate between explicit connection requests (L2CAP socket connect()) and Add Device based connections. For the former we probably do want the Connect Failed since that's consistent with the behavior you see when operating the L2CAP socket. For the latter where we just go back to trying again, so the event doesn't really describe what's going on. Johan -- 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
