From: Mikel Astiz <mikel.astiz.oss@gmail.com>
To: linux-bluetooth@vger.kernel.org
Cc: Mikel Astiz <mikel.astiz@bmw-carit.de>,
Timo Mueller <timo.mueller@bmw-carit.de>
Subject: [RFC BlueZ v3 4/8] Bluetooth: Refactor hci_get_auth_req()
Date: Fri, 28 Jun 2013 10:56:30 +0200 [thread overview]
Message-ID: <1372409794-24688-5-git-send-email-mikel.astiz.oss@gmail.com> (raw)
In-Reply-To: <1372409794-24688-1-git-send-email-mikel.astiz.oss@gmail.com>
From: Mikel Astiz <mikel.astiz@bmw-carit.de>
Refactor the code without changing its behavior by handling the
no-bonding cases first followed by General Bonding.
Signed-off-by: Mikel Astiz <mikel.astiz@bmw-carit.de>
Signed-off-by: Timo Mueller <timo.mueller@bmw-carit.de>
---
net/bluetooth/hci_event.c | 37 ++++++++++++++++++++++---------------
1 file changed, 22 insertions(+), 15 deletions(-)
diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index 50e39f4..fe78b9c 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -3023,24 +3023,25 @@ unlock:
static u8 hci_get_auth_req(struct hci_conn *conn)
{
- /* If remote requests dedicated bonding follow that lead */
- if (conn->remote_auth == HCI_AT_DEDICATED_BONDING ||
- conn->remote_auth == HCI_AT_DEDICATED_BONDING_MITM) {
- /* If both remote and local IO capabilities allow MITM
- * protection then require it, otherwise don't */
- if (conn->remote_cap == HCI_IO_NO_INPUT_OUTPUT ||
- conn->io_capability == HCI_IO_NO_INPUT_OUTPUT)
- return HCI_AT_DEDICATED_BONDING;
- else
- return HCI_AT_DEDICATED_BONDING_MITM;
- }
-
/* If remote requests no-bonding follow that lead */
if (conn->remote_auth == HCI_AT_NO_BONDING ||
conn->remote_auth == HCI_AT_NO_BONDING_MITM)
return conn->remote_auth | (conn->auth_type & 0x01);
- return conn->auth_type;
+ /* For general bonding, use the given auth_type */
+ if (conn->remote_auth == HCI_AT_GENERAL_BONDING ||
+ conn->remote_auth == HCI_AT_GENERAL_BONDING_MITM)
+ return conn->auth_type;
+
+ /* If both remote and local have enough IO capabilities, require
+ * MITM protection
+ */
+ if (conn->remote_cap != HCI_IO_NO_INPUT_OUTPUT &&
+ conn->io_capability != HCI_IO_NO_INPUT_OUTPUT)
+ return conn->remote_auth | 0x01;
+
+ /* No MITM protection possible so remove requirement */
+ return conn->remote_auth & ~0x01;
}
static void hci_io_capa_request_evt(struct hci_dev *hdev, struct sk_buff *skb)
@@ -3070,8 +3071,14 @@ static void hci_io_capa_request_evt(struct hci_dev *hdev, struct sk_buff *skb)
* to DisplayYesNo as it is not supported by BT spec. */
cp.capability = (conn->io_capability == 0x04) ?
HCI_IO_DISPLAY_YESNO : conn->io_capability;
- conn->auth_type = hci_get_auth_req(conn);
- cp.authentication = conn->auth_type;
+
+ /* If we are initiators, there is no remote information yet */
+ if (conn->remote_auth == 0xff) {
+ cp.authentication = conn->auth_type;
+ } else {
+ conn->auth_type = hci_get_auth_req(conn);
+ cp.authentication = conn->auth_type;
+ }
if (hci_find_remote_oob_data(hdev, &conn->dst) &&
(conn->out || test_bit(HCI_CONN_REMOTE_OOB, &conn->flags)))
--
1.8.1.4
next prev parent reply other threads:[~2013-06-28 8:56 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-28 8:56 [RFC BlueZ v3 0/8] SSP MITM protection Mikel Astiz
2013-06-28 8:56 ` [RFC BlueZ v3 1/8] Bluetooth: Add HCI authentication capabilities macros Mikel Astiz
2013-06-28 8:56 ` [RFC BlueZ v3 2/8] Bluetooth: Use defines in in hci_get_auth_req() Mikel Astiz
2013-06-28 8:56 ` [RFC BlueZ v3 3/8] Bluetooth: Use defines instead of integer literals Mikel Astiz
2013-07-09 15:13 ` Gustavo Padovan
2013-06-28 8:56 ` Mikel Astiz [this message]
2013-06-28 8:56 ` [RFC BlueZ v3 5/8] Bluetooth: Refactor code for outgoing dedicated bonding Mikel Astiz
2013-06-28 8:56 ` [RFC BlueZ v3 6/8] Bluetooth: Use MITM Protection when IO caps allow it Mikel Astiz
2013-06-28 8:56 ` [RFC BlueZ v3 7/8] Bluetooth: Request MITM Protection when initiator Mikel Astiz
2013-06-28 8:56 ` [RFC BlueZ v3 8/8] Bluetooth: Add management command to relax MITM Protection Mikel Astiz
2013-06-28 11:40 ` [RFC BlueZ v3 0/8] SSP MITM protection Mikel Astiz
2013-07-08 11:13 ` Mikel Astiz
2013-07-09 13:32 ` Johan Hedberg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1372409794-24688-5-git-send-email-mikel.astiz.oss@gmail.com \
--to=mikel.astiz.oss@gmail.com \
--cc=linux-bluetooth@vger.kernel.org \
--cc=mikel.astiz@bmw-carit.de \
--cc=timo.mueller@bmw-carit.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).