Hi Johan, >>>> 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. are you sure about that. I think we need to define when we want the mgmt connect failed event to show up. Does it make sense that it shows up for connection attempts that are not initiated by mgmt? I mean, what is the benefit of a connection failed event if you can not tell that something actually tried to connect in the first. So if you try to connect via L2CAP, we are just getting a failure and do not know what triggered it. How is that helpful? 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
