2011-04-21 07:54:16

by Rymarkiewicz Waldemar

[permalink] [raw]
Subject: [PATCH v2 1/6] Bluetooth: Add definitions for link key types

Introduce the link key types defs and use them instead of magic numbers.

Signed-off-by: Waldemar Rymarkiewicz <[email protected]>
---
include/net/bluetooth/hci.h | 9 +++++++++
net/bluetooth/hci_core.c | 2 +-
net/bluetooth/hci_event.c | 7 ++++---
3 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
index 6138e31..e0a3cf1 100644
--- a/include/net/bluetooth/hci.h
+++ b/include/net/bluetooth/hci.h
@@ -246,6 +246,15 @@ enum {
#define HCI_AT_GENERAL_BONDING 0x04
#define HCI_AT_GENERAL_BONDING_MITM 0x05

+/* Link Key types */
+#define HCI_LK_COMBINATION 0x00
+#define HCI_LK_LOCAL_UNIT 0x01
+#define HCI_LK_REMOTE_UNIT 0x02
+#define HCI_LK_DEBUG_COMBINATION 0x03
+#define HCI_LK_UNAUTH_COMBINATION 0x04
+#define HCI_LK_AUTH_COMBINATION 0x05
+#define HCI_LK_CHANGED_COMBINATION 0x06
+
/* ----- HCI Commands ---- */
#define HCI_OP_NOP 0x0000

diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index a80bc1c..cfa5621 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -1049,7 +1049,7 @@ int hci_add_link_key(struct hci_dev *hdev, int new_key, bdaddr_t *bdaddr,
if (new_key)
mgmt_new_key(hdev->id, key, old_key_type);

- if (type == 0x06)
+ if (type == HCI_LK_CHANGED_COMBINATION)
key->type = old_key_type;

return 0;
diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index c7eb073..36eb062 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -2037,15 +2037,16 @@ static inline void hci_link_key_request_evt(struct hci_dev *hdev, struct sk_buff
BT_DBG("%s found key type %u for %s", hdev->name, key->type,
batostr(&ev->bdaddr));

- if (!test_bit(HCI_DEBUG_KEYS, &hdev->flags) && key->type == 0x03) {
+ if (!test_bit(HCI_DEBUG_KEYS, &hdev->flags) &&
+ key->type == HCI_LK_DEBUG_COMBINATION) {
BT_DBG("%s ignoring debug key", hdev->name);
goto not_found;
}

conn = hci_conn_hash_lookup_ba(hdev, ACL_LINK, &ev->bdaddr);

- if (key->type == 0x04 && conn && conn->auth_type != 0xff &&
- (conn->auth_type & 0x01)) {
+ if (key->type == HCI_LK_UNAUTH_COMBINATION && conn &&
+ conn->auth_type != 0xff && (conn->auth_type & 0x01)) {
BT_DBG("%s ignoring unauthenticated key", hdev->name);
goto not_found;
}
--
1.7.1



2011-04-27 23:09:47

by Johan Hedberg

[permalink] [raw]
Subject: [PATCH] Bluetooth: Respect local MITM req in io_cap reply

From: Waldemar Rymarkiewicz <[email protected]>

If host requires MITM protection notify that to controller in
io capabilities reply even if the remote device requires no bonding.

If it is not respected, host can get an unauthenticated link key while
it expects authenticated one.

Signed-off-by: Waldemar Rymarkiewicz <[email protected]>
Signed-off-by: Johan Hedberg <[email protected]>
---
net/bluetooth/hci_event.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index cba0bdb..3c90736 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -2369,7 +2369,7 @@ static inline u8 hci_get_auth_req(struct hci_conn *conn)

/* If remote requests no-bonding follow that lead */
if (conn->remote_auth == 0x00 || conn->remote_auth == 0x01)
- return 0x00;
+ return conn->remote_auth | (conn->auth_type & 0x01);

return conn->auth_type;
}
--
1.7.4.4


2011-04-26 23:59:23

by Johan Hedberg

[permalink] [raw]
Subject: Re: [PATCH v2 6/6] Bluetooth: Respect local MITM req in io_cap reply

Hi Waldek,

On Thu, Apr 21, 2011, Waldemar Rymarkiewicz wrote:
> If host requires MITM protection notify that to controller in
> io capabilities reply even if the remote device requires no bonding.
>
> If it is not respected, host can get an unauthenticated link key while
> it expects authenticated one.
>
> Signed-off-by: Waldemar Rymarkiewicz <[email protected]>
> ---
> net/bluetooth/hci_event.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
> index 087953e..3ee0060 100644
> --- a/net/bluetooth/hci_event.c
> +++ b/net/bluetooth/hci_event.c
> @@ -2369,7 +2369,7 @@ static inline u8 hci_get_auth_req(struct hci_conn *conn)
>
> /* If remote requests no-bonding follow that lead */
> if (conn->remote_auth == 0x00 || conn->remote_auth == 0x01)
> - return 0x00;
> + return conn->auth_type & 0x01;

I had to change this to:

return conn->remote_auth | (conn->auth_type & 0x01);

I.e. follow remote requirement and apply the MITM bit to it if the local
requirement has it. Otherwise TP/SEC/SEM/BV-04-C doesn't want to pass
(test vector used is 1.0.39.0). It seems to require us to mirror the
remote MITM requirement. Not sure why hciops is working and I haven't
had the chance to check the logs there. I'm still continuing testing so
we'll see if there are further issues with other test cases.

Johan

2011-04-25 17:09:54

by Luiz Augusto von Dentz

[permalink] [raw]
Subject: Re: [PATCH v2 6/6] Bluetooth: Respect local MITM req in io_cap reply

Hi,

On Thu, Apr 21, 2011 at 11:24 AM, <[email protected]> wrote:
> Hi Johan,
>
>>> --- a/net/bluetooth/hci_event.c
>>> +++ b/net/bluetooth/hci_event.c
>>> @@ -2369,7 +2369,7 @@ static inline u8 hci_get_auth_req(struct
>>> hci_conn *conn)
>>>
>>> ? ? ?/* If remote requests no-bonding follow that lead */
>>> ? ? ?if (conn->remote_auth == 0x00 || conn->remote_auth == 0x01)
>>> - ? ? ? ? ? ?return 0x00;
>>> + ? ? ? ? ? ?return conn->auth_type & 0x01;
>>>
>>> ? ? ?return conn->auth_type;
>>> ?}
>>
>>Your other patches seem ok to me, but have you verified this
>>one with the BITE tester? This logic is directly copied from
>>how it is in user space right now and that's something we have
>>arrived at after multiple iterations with the BITE tester over
>>the last few years. So I'd be very careful when changing it.
>>
>
> No, I did not. I don't have an access to BITE directly, but I will see if I can verify this.
>
> I simply did some combination of manual tests with three different dongles (2.0 and two 2.1), with sspmode on/off , with auth and encrypt on/off, with required sec_level 1,2,3 in security mode 2 and 4.

I remember we discussing something similar regarding LE security, iirc
this avoid failing in case there is not possible to generate an
authenticated key due to lack of io capability, but I also remember
that we do check what type of link key the kernel wants when reading
from storage and return not found when e.g authenticated key is
required but we have only unauthenticated, so perhaps this is just to
make sure we pass some specific BITE test.


--
Luiz Augusto von Dentz
Computer Engineer

2011-04-21 10:02:12

by Rymarkiewicz Waldemar

[permalink] [raw]
Subject: RE: [PATCH v2 3/6] Bluetooth: Map sec_level to link key requirements

Hi Johan,

> /* Enable security */
> int hci_conn_security(struct hci_conn *conn, __u8 sec_level,
>__u8 auth_type) {

Just to clarify. This change modifies hciops behaviour, but it's not visible for the user.
In case of re-auth an extra authentication request is generated, but hciops will link_key_request_replay (key already exists, no check against pin len) on link_key_request.

As a result, connection will be accepted without any user notification.


Thanks,
Waldek

2011-04-21 09:53:28

by Rymarkiewicz Waldemar

[permalink] [raw]
Subject: RE: [PATCH v2 5/6] Bluetooth: Double check sec req for pre 2.1 device

Hi Johan,

>+static int rfcomm_accept_secure(struct hci_conn *conn, struct
>+rfcomm_dlc *d) {
>+ BT_DBG("");
>+
>+ if (d->sec_level != BT_SECURITY_HIGH)
>+ return 1; /* Accept */
>+
>+ if (conn->key_type == HCI_LK_AUTH_COMBINATION ||
>+ (conn->key_type == HCI_LK_COMBINATION &&
>+ conn->pin_length == 16))
>+ return 1;
>+
>+ return 0; /* Reject */
>+}
>+

I don't know what's your approach to changing hciops behaviour, but I can guess we should not change it.
If it so, I would add

>+static int rfcomm_accept_secure(struct hci_conn *conn, struct
>+rfcomm_dlc *d) {
>+ BT_DBG("");
>+
/* Secure link is not supported in non mgmtops */
if (!test_bit(HCI_MGMT, &hdev->flags))
return 1;

>+ if (d->sec_level != BT_SECURITY_HIGH)
>+ return 1; /* Accept */
...

This way SECURITY_HIGH for hciops will behave as it's now (pin code less then 16 digit will be accepted).

Do you agree?

/Waldek

2011-04-21 08:24:41

by Rymarkiewicz Waldemar

[permalink] [raw]
Subject: RE: [PATCH v2 6/6] Bluetooth: Respect local MITM req in io_cap reply

Hi Johan,

>> --- a/net/bluetooth/hci_event.c
>> +++ b/net/bluetooth/hci_event.c
>> @@ -2369,7 +2369,7 @@ static inline u8 hci_get_auth_req(struct
>> hci_conn *conn)
>>
>> /* If remote requests no-bonding follow that lead */
>> if (conn->remote_auth == 0x00 || conn->remote_auth == 0x01)
>> - return 0x00;
>> + return conn->auth_type & 0x01;
>>
>> return conn->auth_type;
>> }
>
>Your other patches seem ok to me, but have you verified this
>one with the BITE tester? This logic is directly copied from
>how it is in user space right now and that's something we have
>arrived at after multiple iterations with the BITE tester over
>the last few years. So I'd be very careful when changing it.
>

No, I did not. I don't have an access to BITE directly, but I will see if I can verify this.

I simply did some combination of manual tests with three different dongles (2.0 and two 2.1), with sspmode on/off , with auth and encrypt on/off, with required sec_level 1,2,3 in security mode 2 and 4.

Waldek

2011-04-21 08:10:48

by Johan Hedberg

[permalink] [raw]
Subject: Re: [PATCH v2 6/6] Bluetooth: Respect local MITM req in io_cap reply

Hi Waldek,

On Thu, Apr 21, 2011, Waldemar Rymarkiewicz wrote:
> If host requires MITM protection notify that to controller in
> io capabilities reply even if the remote device requires no bonding.
>
> If it is not respected, host can get an unauthenticated link key while
> it expects authenticated one.
>
> Signed-off-by: Waldemar Rymarkiewicz <[email protected]>
> ---
> net/bluetooth/hci_event.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
> index 087953e..3ee0060 100644
> --- a/net/bluetooth/hci_event.c
> +++ b/net/bluetooth/hci_event.c
> @@ -2369,7 +2369,7 @@ static inline u8 hci_get_auth_req(struct hci_conn *conn)
>
> /* If remote requests no-bonding follow that lead */
> if (conn->remote_auth == 0x00 || conn->remote_auth == 0x01)
> - return 0x00;
> + return conn->auth_type & 0x01;
>
> return conn->auth_type;
> }

Your other patches seem ok to me, but have you verified this one with
the BITE tester? This logic is directly copied from how it is in user
space right now and that's something we have arrived at after multiple
iterations with the BITE tester over the last few years. So I'd be very
careful when changing it.

Johan

2011-04-21 07:54:21

by Rymarkiewicz Waldemar

[permalink] [raw]
Subject: [PATCH v2 6/6] Bluetooth: Respect local MITM req in io_cap reply

If host requires MITM protection notify that to controller in
io capabilities reply even if the remote device requires no bonding.

If it is not respected, host can get an unauthenticated link key while
it expects authenticated one.

Signed-off-by: Waldemar Rymarkiewicz <[email protected]>
---
net/bluetooth/hci_event.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index 087953e..3ee0060 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -2369,7 +2369,7 @@ static inline u8 hci_get_auth_req(struct hci_conn *conn)

/* If remote requests no-bonding follow that lead */
if (conn->remote_auth == 0x00 || conn->remote_auth == 0x01)
- return 0x00;
+ return conn->auth_type & 0x01;

return conn->auth_type;
}
--
1.7.1


2011-04-21 07:54:20

by Rymarkiewicz Waldemar

[permalink] [raw]
Subject: [PATCH v2 5/6] Bluetooth: Double check sec req for pre 2.1 device

In case of pre v2.1 devices authentication request will return
success immediately if the link key already exists without any
authentication process.

That means, it's not possible to re-authenticate the link if you
already have combination key and for instance want to re-authenticate
to get the high security (use 16 digit pin).

Therefore, it's necessary to check security requirements on auth
complete event to prevent not enough secure connection.

Signed-off-by: Waldemar Rymarkiewicz <[email protected]>
---
net/bluetooth/rfcomm/core.c | 17 ++++++++++++++++-
1 files changed, 16 insertions(+), 1 deletions(-)

diff --git a/net/bluetooth/rfcomm/core.c b/net/bluetooth/rfcomm/core.c
index c997393..75535cc 100644
--- a/net/bluetooth/rfcomm/core.c
+++ b/net/bluetooth/rfcomm/core.c
@@ -2054,6 +2054,21 @@ static int rfcomm_run(void *unused)
return 0;
}

+static int rfcomm_accept_secure(struct hci_conn *conn, struct rfcomm_dlc *d)
+{
+ BT_DBG("");
+
+ if (d->sec_level != BT_SECURITY_HIGH)
+ return 1; /* Accept */
+
+ if (conn->key_type == HCI_LK_AUTH_COMBINATION ||
+ (conn->key_type == HCI_LK_COMBINATION &&
+ conn->pin_length == 16))
+ return 1;
+
+ return 0; /* Reject */
+}
+
static void rfcomm_security_cfm(struct hci_conn *conn, u8 status, u8 encrypt)
{
struct rfcomm_session *s;
@@ -2093,7 +2108,7 @@ static void rfcomm_security_cfm(struct hci_conn *conn, u8 status, u8 encrypt)
if (!test_and_clear_bit(RFCOMM_AUTH_PENDING, &d->flags))
continue;

- if (!status)
+ if (!status && rfcomm_accept_secure(conn, d))
set_bit(RFCOMM_AUTH_ACCEPT, &d->flags);
else
set_bit(RFCOMM_AUTH_REJECT, &d->flags);
--
1.7.1


2011-04-21 07:54:19

by Rymarkiewicz Waldemar

[permalink] [raw]
Subject: [PATCH v2 4/6] Bluetooth: Ignore key unauthenticated for high security

High security level for pre v2.1 devices requires combination link key
authenticated by at least 16 digit PIN code.

It's also necessary to update key_type and pin_length when the key
exists and is sufficently secured for the connection as there will be
no link key notify event in that case.

Signed-off-by: Waldemar Rymarkiewicz <[email protected]>
---
net/bluetooth/hci_event.c | 20 ++++++++++++++++----
1 files changed, 16 insertions(+), 4 deletions(-)

diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index 1610e5f..087953e 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -2043,11 +2043,23 @@ static inline void hci_link_key_request_evt(struct hci_dev *hdev, struct sk_buff
}

conn = hci_conn_hash_lookup_ba(hdev, ACL_LINK, &ev->bdaddr);
+ if (conn) {
+ if (key->type == HCI_LK_UNAUTH_COMBINATION &&
+ conn->auth_type != 0xff &&
+ (conn->auth_type & 0x01)) {
+ BT_DBG("%s ignoring unauthenticated key", hdev->name);
+ goto not_found;
+ }

- if (key->type == HCI_LK_UNAUTH_COMBINATION && conn &&
- conn->auth_type != 0xff && (conn->auth_type & 0x01)) {
- BT_DBG("%s ignoring unauthenticated key", hdev->name);
- goto not_found;
+ if (key->type == HCI_LK_COMBINATION && key->pin_len < 16 &&
+ conn->pending_sec_level == BT_SECURITY_HIGH) {
+ BT_DBG("%s ignoring key unauthenticated for high \
+ security", hdev->name);
+ goto not_found;
+ }
+
+ conn->key_type = key->type;
+ conn->pin_length = key->pin_len;
}

bacpy(&cp.bdaddr, &ev->bdaddr);
--
1.7.1


2011-04-21 07:54:18

by Rymarkiewicz Waldemar

[permalink] [raw]
Subject: [PATCH v2 3/6] Bluetooth: Map sec_level to link key requirements

Keep the link key type together with connection and use it to
map security level to link key requirements. Authenticate and/or
encrypt connection if the link is insufficiently secure.

Signed-off-by: Waldemar Rymarkiewicz <[email protected]>
---
include/net/bluetooth/hci_core.h | 1 +
net/bluetooth/hci_conn.c | 61 +++++++++++++++++++++++++++++++------
net/bluetooth/hci_event.c | 4 ++
3 files changed, 56 insertions(+), 10 deletions(-)

diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
index 4093133..02e7256 100644
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -226,6 +226,7 @@ struct hci_conn {
__u16 pkt_type;
__u16 link_policy;
__u32 link_mode;
+ __u8 key_type;
__u8 auth_type;
__u8 sec_level;
__u8 pending_sec_level;
diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
index 7a6f56b..74cd755 100644
--- a/net/bluetooth/hci_conn.c
+++ b/net/bluetooth/hci_conn.c
@@ -287,6 +287,7 @@ struct hci_conn *hci_conn_add(struct hci_dev *hdev, int type, bdaddr_t *dst)
conn->auth_type = HCI_AT_GENERAL_BONDING;
conn->io_capability = hdev->io_capability;
conn->remote_auth = 0xff;
+ conn->key_type = 0xff;

conn->power_save = 1;
conn->disc_timeout = HCI_DISCONN_TIMEOUT;
@@ -535,32 +536,72 @@ static int hci_conn_auth(struct hci_conn *conn, __u8 sec_level, __u8 auth_type)
return 0;
}

+/* Encrypt the the link */
+static void hci_conn_encrypt(struct hci_conn *conn)
+{
+ BT_DBG("conn %p", conn);
+
+ if (!test_and_set_bit(HCI_CONN_ENCRYPT_PEND, &conn->pend)) {
+ struct hci_cp_set_conn_encrypt cp;
+ cp.handle = cpu_to_le16(conn->handle);
+ cp.encrypt = 0x01;
+ hci_send_cmd(conn->hdev, HCI_OP_SET_CONN_ENCRYPT, sizeof(cp),
+ &cp);
+ }
+}
+
/* Enable security */
int hci_conn_security(struct hci_conn *conn, __u8 sec_level, __u8 auth_type)
{
BT_DBG("conn %p", conn);

+ /* For sdp we don't need the link key. */
if (sec_level == BT_SECURITY_SDP)
return 1;

+ /* For non 2.1 devices and low security level we don't need the link
+ key. */
if (sec_level == BT_SECURITY_LOW &&
(!conn->ssp_mode || !conn->hdev->ssp_mode))
return 1;

- if (conn->link_mode & HCI_LM_ENCRYPT)
- return hci_conn_auth(conn, sec_level, auth_type);
-
+ /* For other security levels we need the link key. */
+ if (!(conn->link_mode & HCI_LM_AUTH))
+ goto auth;
+
+ /* An authenticated combination key has sufficient security for any
+ security level. */
+ if (conn->key_type == HCI_LK_AUTH_COMBINATION)
+ goto encrypt;
+
+ /* An unauthenticated combination key has sufficient security for
+ security level 1 and 2. */
+ if (conn->key_type == HCI_LK_UNAUTH_COMBINATION &&
+ (sec_level == BT_SECURITY_MEDIUM ||
+ sec_level == BT_SECURITY_LOW))
+ goto encrypt;
+
+ /* A combination key has always sufficient security for the security
+ levels 1 or 2. High security level requires the combination key
+ is generated using maximum PIN code length (16).
+ For pre 2.1 units. */
+ if (conn->key_type == HCI_LK_COMBINATION &&
+ (sec_level != BT_SECURITY_HIGH ||
+ conn->pin_length == 16))
+ goto encrypt;
+
+auth:
if (test_and_set_bit(HCI_CONN_ENCRYPT_PEND, &conn->pend))
return 0;

- if (hci_conn_auth(conn, sec_level, auth_type)) {
- struct hci_cp_set_conn_encrypt cp;
- cp.handle = cpu_to_le16(conn->handle);
- cp.encrypt = 1;
- hci_send_cmd(conn->hdev, HCI_OP_SET_CONN_ENCRYPT,
- sizeof(cp), &cp);
- }
+ hci_conn_auth(conn, sec_level, auth_type);
+ return 0;
+
+encrypt:
+ if (conn->link_mode & HCI_LM_ENCRYPT)
+ return 1;

+ hci_conn_encrypt(conn);
return 0;
}
EXPORT_SYMBOL(hci_conn_security);
diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index 0ceecd7..1610e5f 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -2079,6 +2079,10 @@ static inline void hci_link_key_notify_evt(struct hci_dev *hdev, struct sk_buff
hci_conn_hold(conn);
conn->disc_timeout = HCI_DISCONN_TIMEOUT;
pin_len = conn->pin_length;
+
+ if (ev->key_type != HCI_LK_CHANGED_COMBINATION)
+ conn->key_type = ev->key_type;
+
hci_conn_put(conn);
}

--
1.7.1


2011-04-21 07:54:17

by Rymarkiewicz Waldemar

[permalink] [raw]
Subject: [PATCH v2 2/6] Bluetooth: Don't modify sec_level if auth failed

If authentication fails the security level should stay as it was set
before the process has started. Setting BT_SECURITY_LOW can hide real
security level on a link eg. having BT_SECURITY_MEDIUM on the link,
re-authenticate with failure to get BT_SECURITY_HIGH, as a result we
get BT_SECURITY_LOW on the link while the real security is still medium.

Signed-off-by: Waldemar Rymarkiewicz <[email protected]>
---
net/bluetooth/hci_event.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index 36eb062..0ceecd7 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -1443,7 +1443,6 @@ static inline void hci_auth_complete_evt(struct hci_dev *hdev, struct sk_buff *s
conn->sec_level = conn->pending_sec_level;
} else {
mgmt_auth_failed(hdev->id, &conn->dst, ev->status);
- conn->sec_level = BT_SECURITY_LOW;
}

clear_bit(HCI_CONN_AUTH_PEND, &conn->pend);
--
1.7.1