From: Bao Liang <[email protected]>
This patch fixes a minor issue that two connection responses will be sent
for one L2CAP connection request. If the L2CAP connection request is first
blocked due to security reason and responded with reason "security block",
the state of the connection remains BT_CONNECT2. If a pairing procedure
completes successfully before the ACL connection is down, local host will
send another connection complete response. See the following packets
captured by hcidump.
2010-12-07 22:21:24.928096 < ACL data: handle 12 flags 0x00 dlen 16
0000: 0c 00 01 00 03 19 08 00 41 00 53 00 03 00 00 00 ........A.S.....
... ...
2010-12-07 22:21:35.791747 > HCI Event: Auth Complete (0x06) plen 3
status 0x00 handle 12
... ...
2010-12-07 22:21:35.872372 > ACL data: handle 12 flags 0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x0054 scid 0x0040 result 0 status 0
Connection successful
Signed-off-by: Bao Liang <[email protected]>
---
net/bluetooth/l2cap.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
index fadf26b..40d70db 100644
--- a/net/bluetooth/l2cap.c
+++ b/net/bluetooth/l2cap.c
@@ -844,9 +844,10 @@ static void __l2cap_sock_close(struct sock *sk, int reason)
struct l2cap_conn_rsp rsp;
__u16 result;
- if (bt_sk(sk)->defer_setup)
+ if (bt_sk(sk)->defer_setup) {
+ sk->sk_state = BT_DISCONN;
result = L2CAP_CR_SEC_BLOCK;
- else
+ } else
result = L2CAP_CR_BAD_PSM;
rsp.scid = cpu_to_le16(l2cap_pi(sk)->dcid);
--
1.7.1