diff options
| author | Marcel Holtmann <marcel@holtmann.org> | 2008-07-14 20:13:45 +0200 |
|---|---|---|
| committer | Marcel Holtmann <marcel@holtmann.org> | 2008-07-14 20:13:45 +0200 |
| commit | ae29319649b80ed9d28d7b4f164e3f5f75020fc8 (patch) | |
| tree | 71026720bc10d9e4c9f1b971a531e175aa9d2e16 /net/bluetooth/hci_event.c | |
| parent | 9719f8afce34d3d04e884873a8a5e3483e30974c (diff) | |
[Bluetooth] Update authentication status after successful encryption
The authentication status is not communicated to both parties. This is
actually a flaw in the Bluetooth specification. Only the requesting side
really knows if the authentication was successful or not. This piece of
information is however needed on the other side to know if it has to
trigger the authentication procedure or not. Worst case is that both
sides will request authentication at different times, but this should
be avoided since it costs extra time when setting up a new connection.
For Bluetooth encryption it is required to authenticate the link first
and the encryption status is communicated to both sides. So when a link
is switched to encryption it is possible to update the authentication
status since it implies an authenticated link.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Diffstat (limited to 'net/bluetooth/hci_event.c')
| -rw-r--r-- | net/bluetooth/hci_event.c | 6 |
1 files changed, 4 insertions, 2 deletions
diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c index 6aef8f24e581..0aba21a03b3c 100644 --- a/net/bluetooth/hci_event.c +++ b/net/bluetooth/hci_event.c @@ -883,9 +883,11 @@ static inline void hci_encrypt_change_evt(struct hci_dev *hdev, struct sk_buff * conn = hci_conn_hash_lookup_handle(hdev, __le16_to_cpu(ev->handle)); if (conn) { if (!ev->status) { - if (ev->encrypt) + if (ev->encrypt) { + /* Encryption implies authentication */ + conn->link_mode |= HCI_LM_AUTH; conn->link_mode |= HCI_LM_ENCRYPT; - else + } else conn->link_mode &= ~HCI_LM_ENCRYPT; } |