Hi Marcel,
On Fri, May 08, 2009, Marcel Holtmann wrote:
> what is the time between the PIN code request and the cancel command?
It is almost immediate. Here's the timings before your patch:
1241826073.405723 > HCI Event: Connect Request (0x04) plen 10
1241826073.405782 < HCI Command: Accept Connection Request (0x01|0x0009) plen 7
1241826073.407540 > HCI Event: Command Status (0x0f) plen 4
1241826073.569728 > HCI Event: Role Change (0x12) plen 8
1241826073.717728 > HCI Event: Link Key Request (0x17) plen 6
1241826073.718103 < HCI Command: Link Key Request Negative Reply (0x01|0x000c) plen 6
1241826073.719726 > HCI Event: Command Complete (0x0e) plen 10
1241826073.720548 > HCI Event: PIN Code Request (0x16) plen 6
1241826073.732176 < HCI Command: Create Connection Cancel (0x01|0x0008) plen 6
> --- a/net/bluetooth/hci_conn.c
> +++ b/net/bluetooth/hci_conn.c
> @@ -171,7 +171,7 @@ static void hci_conn_timeout(unsigned long arg)
> switch (conn->state) {
> case BT_CONNECT:
> case BT_CONNECT2:
> - if (conn->type == ACL_LINK)
> + if (conn->type == ACL_LINK && conn->out)
> hci_acl_connect_cancel(conn);
> else
> hci_acl_disconn(conn, 0x13);
>
> The above patch might fixes it. However without the timing between the
> commands, I don't know what triggers it.
Thanks for the patch. Unfortunately it doesn't fix the issue, though it does
show that it is this hci_conn_timeout function that's to blame of the
situation. Here's what happens with your patch:
1241859026.835365 < HCI Command: Accept Connection Request (0x01|0x0009) plen 7
1241859026.837313 > HCI Event: Command Status (0x0f) plen 4
1241859026.999322 > HCI Event: Role Change (0x12) plen 8
1241859027.147328 > HCI Event: Link Key Request (0x17) plen 6
1241859027.147583 < HCI Command: Link Key Request Negative Reply (0x01|0x000c) plen 6
1241859027.149329 > HCI Event: Command Complete (0x0e) plen 10
1241859027.150324 > HCI Event: PIN Code Request (0x16) plen 6
1241859027.164053 < HCI Command: Disconnect (0x01|0x0006) plen 3
One problem here is that from the host perspective there's no ACL yet
since there hasn't been any "connect complete" event. So HCI_Disconnect is
incorrect in this case and doesn't even have a real handle to give so it
looks like (hcidump -V):
< HCI Command: Disconnect (0x01|0x0006) plen 3
handle 0 reason 0x13
Reason: Remote User Terminated Connection
I'll do some investigation later today to try to figure out why this
timeout function gets immediately triggered.
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
