Hi Johan, >>> When we're doing background scanning and connection attempts it's >>> possible we timeout trying to connect and go back to scanning again. >>> The timeout triggers a HCI_LE_Create_Connection_Cancel which will >>> trigger a Connection Complete with "Unknown Connection Identifier" >>> error status. Since we go back to scanning this isn't really a failure >>> and shouldn't be presented as such to user space through mgmt. >>> >>> The exception to this is if the connection attempt was due to an >>> explicit request on an L2CAP socket (indicated by >>> params->explicit_connect being true). Since the socket will get an >>> error it's consistent to also notify the failure on mgmt in this case. >>> >>> Signed-off-by: Johan Hedberg <johan.hedberg@xxxxxxxxx> >>> --- >>> net/bluetooth/hci_conn.c | 12 ++++++++++-- >>> 1 file changed, 10 insertions(+), 2 deletions(-) >>> >>> diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c >>> index f28741d78e0b..de7fa9f78cbe 100644 >>> --- a/net/bluetooth/hci_conn.c >>> +++ b/net/bluetooth/hci_conn.c >>> @@ -668,8 +668,16 @@ void hci_le_conn_failed(struct hci_conn *conn, u8 status) >>> >>> conn->state = BT_CLOSED; >>> >>> - mgmt_connect_failed(hdev, &conn->dst, conn->type, conn->dst_type, >>> - status); >>> + /* If the failure was due to a timeout and cancelation of the >>> + * attempt there's no point of notifying failure since we'll go >>> + * back to keep trying to connect. The only exception is >>> + * explicit connect requests where a timeout + cancel does >>> + * indicate an actual failure. >>> + */ >>> + if (status != HCI_ERROR_UNKNOWN_CONN_ID || >>> + (params && params->explicit_connect)) >>> + mgmt_connect_failed(hdev, &conn->dst, conn->type, >>> + conn->dst_type, status); >> >> are we okay with the oversimplified error handling. I think the HCI is >> pretty clear that an Unknown Connection Identifier error can only be >> traced back to the fact that LE Create Connection Cancel was issued, >> but the connection had already been established. > > Where in the spec do you conclude this from? The section for > HCI_LE_Create_Connection_Cancel states: > > " > If the cancellation was successful then, after the Command Complete > event for the LE_Create_Connection_Cancel command: > > - if the LE Enhanced Connection Complete event is unmasked, then that > event shall be sent. > - otherwise the LE Connection Complete event shall be sent. > > In either case, the event shall be sent with the error code Unknown > Connection Identifier (0x02). > " > > That doesn't talk anything about a connection already having been > established but rather a successful cancellation. The > hci_le_conn_failed() gets called from the event handler for LE > Connection Complete, so this error code here means that the cancellation > was successful. > >> Can you cause that error also with LE Create Connection itself? I >> doubt it, but we want to be 100% clear here and maybe also be event >> clear in the the comment on what kind of errors we are catching and >> why. I think citing the spec might be a good idea here as well. > > I can clarify in the comment that specifically Unknown Conn ID means > that the cancellation was successful. I think that would be a good idea. 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
