Regression caused by "Bluetooth: Map sec_level to link key requirements"

Regression caused by "Bluetooth: Map sec_level to link key requirements"

[Keith Packard]

[-- Attachment #1: Type: text/plain, Size: 3686 bytes --]


Patch 13d39315c22b128f4796fc008b04914a7c32bb1a is causing a regression
From 2.6.39. I cannot communicate with my Nokia N900 using either the
SyncML or DUN RFCOMM services.  I get a connection reset error shortly
after startup.

I've reverted this patch on top of something past -rc2 (to be precise,
I'm branching from ef2398019b305827ea7130ebaf7bf521b444530e).
With the following fix-up to make things build again, my bluetooth works
again.

From 9774a1309ef662308c6ffb7db160788f6e2b5e35 Mon Sep 17 00:00:00 2001
From: Keith Packard <keithp@keithp.com>
Date: Thu, 9 Jun 2011 00:11:33 -0700
Subject: [PATCH 2/2] net/bluetooth: Clean up revert of 13d39315c22b128f4796fc008b04914a7c32bb1a.

This removes lingering references to key_type and makes the code work
like it did before the offending commit.

Signed-off-by: Keith Packard <keithp@keithp.com>
---
 net/bluetooth/hci_conn.c    |   17 -----------------
 net/bluetooth/hci_core.c    |    4 +---
 net/bluetooth/hci_event.c   |    1 -
 net/bluetooth/rfcomm/core.c |    2 +-
 4 files changed, 2 insertions(+), 22 deletions(-)

diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
index 25c4ea0..de3a4c0 100644
--- a/net/bluetooth/hci_conn.c
+++ b/net/bluetooth/hci_conn.c
@@ -582,23 +582,6 @@ int hci_conn_security(struct hci_conn *conn, __u8 sec_level, __u8 auth_type)
 }
 EXPORT_SYMBOL(hci_conn_security);
 
-/* Check secure link requirement */
-int hci_conn_check_secure(struct hci_conn *conn, __u8 sec_level)
-{
-	BT_DBG("conn %p", conn);
-
-	if (sec_level != BT_SECURITY_HIGH)
-		return 1; /* Accept if non-secure is required */
-
-	if (conn->key_type == HCI_LK_AUTH_COMBINATION ||
-			(conn->key_type == HCI_LK_COMBINATION &&
-			conn->pin_length == 16))
-		return 1;
-
-	return 0; /* Reject not secure link */
-}
-EXPORT_SYMBOL(hci_conn_check_secure);
-
 /* Change link key */
 int hci_conn_change_link_key(struct hci_conn *conn)
 {
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index 815269b..47dff20 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -1067,7 +1067,7 @@ int hci_add_link_key(struct hci_dev *hdev, struct hci_conn *conn, int new_key,
 		old_key_type = old_key->type;
 		key = old_key;
 	} else {
-		old_key_type = conn ? conn->key_type : 0xff;
+		old_key_type = 0xff;
 		key = kzalloc(sizeof(*key), GFP_ATOMIC);
 		if (!key)
 			return -ENOMEM;
@@ -1083,8 +1083,6 @@ int hci_add_link_key(struct hci_dev *hdev, struct hci_conn *conn, int new_key,
 					(!conn || conn->remote_auth == 0xff) &&
 					old_key_type == 0xff) {
 		type = HCI_LK_COMBINATION;
-		if (conn)
-			conn->key_type = type;
 	}
 
 	bacpy(&key->bdaddr, bdaddr);
diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index a61ca11..b57b971 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -2095,7 +2095,6 @@ static inline void hci_link_key_request_evt(struct hci_dev *hdev, struct sk_buff
 			goto not_found;
 		}
 
-		conn->key_type = key->type;
 		conn->pin_length = key->pin_len;
 	}
 
diff --git a/net/bluetooth/rfcomm/core.c b/net/bluetooth/rfcomm/core.c
index 5759bb7..121a5c1 100644
--- a/net/bluetooth/rfcomm/core.c
+++ b/net/bluetooth/rfcomm/core.c
@@ -2096,7 +2096,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 && hci_conn_check_secure(conn, d->sec_level))
+		if (!status)
 			set_bit(RFCOMM_AUTH_ACCEPT, &d->flags);
 		else
 			set_bit(RFCOMM_AUTH_REJECT, &d->flags);
-- 
1.7.5.3

-- 
keith.packard@intel.com

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

RE: Regression caused by "Bluetooth: Map sec_level to link key requirements"

[Waldemar.Rymarkiewicz]

Hi Keith,=20

>Patch 13d39315c22b128f4796fc008b04914a7c32bb1a is causing a=20
>regression From 2.6.39. I cannot communicate with my Nokia=20
>N900 using either the SyncML or DUN RFCOMM services.  I get a=20
>connection reset error shortly after startup.
>
>I've reverted this patch on top of something past -rc2 (to be=20
>precise, I'm branching from ef2398019b305827ea7130ebaf7bf521b444530e).
>With the following fix-up to make things build again, my=20
>bluetooth works again.

Logs from kernel and bluez would be much appreciated to see what happend.
As I remember this was pretty well tested with BITE test by Johan.

Thanks,
Waldek

RE: Regression caused by "Bluetooth: Map sec_level to link key requirements"

[Waldemar.Rymarkiewicz]

=20
>Patch 13d39315c22b128f4796fc008b04914a7c32bb1a is causing a=20
>regression From 2.6.39. I cannot communicate with my Nokia=20
>N900 using either the SyncML or DUN RFCOMM services.  I get a=20
>connection reset error shortly after startup.
>
>I've reverted this patch on top of something past -rc2 (to be=20
>precise, I'm branching from ef2398019b305827ea7130ebaf7bf521b444530e).
>With the following fix-up to make things build again, my=20
>bluetooth works again.
>

hcidump -Rt > foo.log  from your test session will help as well


Waldek

Re: Regression caused by "Bluetooth: Map sec_level to link key requirements"

[Johan Hedberg]

Hi,

On Thu, Jun 09, 2011, Waldemar.Rymarkiewicz@tieto.com wrote:
> >Patch 13d39315c22b128f4796fc008b04914a7c32bb1a is causing a 
> >regression From 2.6.39. I cannot communicate with my Nokia 
> >N900 using either the SyncML or DUN RFCOMM services.  I get a 
> >connection reset error shortly after startup.
> >
> >I've reverted this patch on top of something past -rc2 (to be 
> >precise, I'm branching from ef2398019b305827ea7130ebaf7bf521b444530e).
> >With the following fix-up to make things build again, my 
> >bluetooth works again.
> 
> Logs from kernel and bluez would be much appreciated to see what happend.
> As I remember this was pretty well tested with BITE test by Johan.

The patch was not only fine but actually *needed* by the BITE. So
reverting it will make some qualification tests fail.

There's no DUN support in the N900 by default and the only package I'm
aware that provides it uses the command line rfcomm tool with high
security on the socket to block just-works SSP pairing (since the rfcomm
tool doesn't use the authorization framework to guarantee a user pop-up
dialog). The SyncML code I can't comment on since I haven't seen it.

So potentially this might be limited to high security sockets.
Speculating further, if the device connecting to the N900 has a pre-2.1
Bluetooth controller this could simply be about not having a 16-digit
PIN which high security services require. So could whoever is able to
reproduce the issue try repairing and entering a 16-digit PIN to see if
the problem goes away? And if this is in fact the case then the kernel
code is working exactly as it should; the only issue is that these
services should really be using medium security level instead of high.

Johan

Re: Regression caused by "Bluetooth: Map sec_level to link key requirements"

[Keith Packard]

[-- Attachment #1: Type: text/plain, Size: 4535 bytes --]

On Thu, 9 Jun 2011 17:33:45 +0900, Johan Hedberg <johan.hedberg@gmail.com> wrote:

> The patch was not only fine but actually *needed* by the BITE. So
> reverting it will make some qualification tests fail.

Yeah, it seemed pretty obvious that the patch added some useful security
checks.

> There's no DUN support in the N900 by default and the only package I'm
> aware that provides it uses the command line rfcomm tool with high
> security on the socket to block just-works SSP pairing (since the rfcomm
> tool doesn't use the authorization framework to guarantee a user pop-up
> dialog). The SyncML code I can't comment on since I haven't seen it.

Service Name: Dial-Up Networking
Service RecHandle: 0x10000
Service Class ID List:
  "Dialup Networking" (0x1103)
  "Generic Networking" (0x1201)
Protocol Descriptor List:
  "L2CAP" (0x0100)
  "RFCOMM" (0x0003)
    Channel: 1
Profile Descriptor List:
  "Dialup Networking" (0x1103)
    Version: 0x0100

> So potentially this might be limited to high security sockets.
> Speculating further, if the device connecting to the N900 has a pre-2.1
> Bluetooth controller this could simply be about not having a 16-digit
> PIN which high security services require.

> So could whoever is able to
> reproduce the issue try repairing and entering a 16-digit PIN to see if
> the problem goes away?

I re-pair'ed using a manually entered a 16 digit pin, but now DUN setup
doesn't succeed at all.

> And if this is in fact the case then the kernel
> code is working exactly as it should; the only issue is that these
> services should really be using medium security level instead of high.

I cannot figure out how to reconfigure things so that they work again.

> hcidump -Rt > foo.log  from your test session will help as well

here's a dump of trying to start the syncml session:

HCI sniffer - Bluetooth packet analyzer ver 2.0
device: hci0 snap_len: 1028 filter: 0xffffffff
2011-06-09 09:36:27.729606 < 01 05 04 0D 6E F5 C1 5B 9B EC 18 CC 02 00 00 00 01 
2011-06-09 09:36:27.731045 > 04 0F 04 00 01 05 04 
2011-06-09 09:36:28.281075 > 04 12 08 00 6E F5 C1 5B 9B EC 01 
2011-06-09 09:36:28.435069 > 04 03 0B 00 0C 00 6E F5 C1 5B 9B EC 01 00 
2011-06-09 09:36:28.435115 < 01 1B 04 02 0C 00 
2011-06-09 09:36:28.437015 > 04 1B 03 0C 00 05 
2011-06-09 09:36:28.438023 > 04 0F 04 00 01 1B 04 
2011-06-09 09:36:28.439017 > 04 0B 0B 00 0C 00 BF EE 0F C6 98 3D 59 82 
2011-06-09 09:36:28.439051 < 01 1C 04 03 0C 00 01 
2011-06-09 09:36:28.441060 > 04 1B 03 0C 00 03 
2011-06-09 09:36:28.443060 > 04 0F 04 00 01 1C 04 
2011-06-09 09:36:28.448100 > 04 23 0D 00 0C 00 01 01 01 00 00 00 00 00 00 00 
2011-06-09 09:36:28.448133 < 01 19 04 0A 6E F5 C1 5B 9B EC 02 00 00 00 
2011-06-09 09:36:28.450059 > 04 0F 04 00 01 19 04 
2011-06-09 09:36:28.470089 > 04 07 FF 00 6E F5 C1 5B 9B EC 6E 61 6D 69 00 00 00 00 00 00 
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
2011-06-09 09:36:28.470129 < 01 11 04 02 0C 00 
2011-06-09 09:36:28.472099 > 04 0F 04 00 01 11 04 
2011-06-09 09:36:28.473061 > 04 17 06 6E F5 C1 5B 9B EC 
2011-06-09 09:36:28.473193 < 01 0B 04 16 6E F5 C1 5B 9B EC CC CB 2A 77 3C 2E 5E 6B 75 87 
  67 EC 03 40 67 8E 
2011-06-09 09:36:28.485125 > 04 0E 0A 01 0B 04 00 6E F5 C1 5B 9B EC 
2011-06-09 09:36:28.503097 > 04 06 03 00 0C 00 
2011-06-09 09:36:28.503134 < 01 13 04 03 0C 00 01 
2011-06-09 09:36:28.505069 > 04 0F 04 00 01 13 04 
2011-06-09 09:36:28.533086 > 04 08 04 00 0C 00 01 
2011-06-09 09:36:28.533133 < 02 0C 00 0A 00 06 00 01 00 0A 01 02 00 02 00 
2011-06-09 09:36:28.539338 > 02 0C 20 10 00 0C 00 01 00 0B 01 08 00 02 00 00 00 00 00 00 
  00 
2011-06-09 09:36:28.672083 > 04 13 05 01 0C 00 01 00 
2011-06-09 09:36:36.509207 > 04 05 04 00 0C 00 13 

-- 
keith.packard@intel.com

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

RE: Regression caused by "Bluetooth: Map sec_level to link key requirements"

[Keith Packard]

[-- Attachment #1: Type: text/plain, Size: 6995 bytes --]

On Thu, 9 Jun 2011 11:02:51 +0300, <Waldemar.Rymarkiewicz@tieto.com> wrote:
>  
> >Patch 13d39315c22b128f4796fc008b04914a7c32bb1a is causing a 
> >regression From 2.6.39. I cannot communicate with my Nokia 
> >N900 using either the SyncML or DUN RFCOMM services.  I get a 
> >connection reset error shortly after startup.
> >
> >I've reverted this patch on top of something past -rc2 (to be 
> >precise, I'm branching from ef2398019b305827ea7130ebaf7bf521b444530e).
> >With the following fix-up to make things build again, my 
> >bluetooth works again.
> >
> 
> hcidump -Rt > foo.log  from your test session will help as well

Sent along with my other reply. Running the test generates no additional
dmesg output at all.

As a simpler test than accessing the syncml service, I just tried to
connect to the DUN service using 'cu'. Again, no dmesg additions, and
here's the hcidump -Rt output:

HCI sniffer - Bluetooth packet analyzer ver 2.0
device: hci0 snap_len: 1028 filter: 0xffffffff
2011-06-09 10:02:16.878449 > 04 01 01 00 
2011-06-09 10:02:26.358023 < 01 05 04 0D 6E F5 C1 5B 9B EC 18 CC 02 00 00 00 01 
2011-06-09 10:02:26.359579 > 04 0F 04 00 01 05 04 
2011-06-09 10:02:27.674655 > 04 12 08 00 6E F5 C1 5B 9B EC 01 
2011-06-09 10:02:27.827639 > 04 03 0B 00 0C 00 6E F5 C1 5B 9B EC 01 00 
2011-06-09 10:02:27.827717 < 01 1B 04 02 0C 00 
2011-06-09 10:02:27.829596 > 04 1B 03 0C 00 05 
2011-06-09 10:02:27.830593 > 04 0F 04 00 01 1B 04 
2011-06-09 10:02:27.831591 > 04 0B 0B 00 0C 00 BF EE 0F C6 98 3D 59 82 
2011-06-09 10:02:27.831630 < 01 1C 04 03 0C 00 01 
2011-06-09 10:02:27.833596 > 04 1B 03 0C 00 03 
2011-06-09 10:02:27.834595 > 04 0F 04 00 01 1C 04 
2011-06-09 10:02:27.842634 > 04 23 0D 00 0C 00 01 01 01 00 00 00 00 00 00 00 
2011-06-09 10:02:27.842666 < 01 19 04 0A 6E F5 C1 5B 9B EC 02 00 00 00 
2011-06-09 10:02:27.844622 > 04 0F 04 00 01 19 04 
2011-06-09 10:02:27.864641 > 04 07 FF 00 6E F5 C1 5B 9B EC 6E 61 6D 69 00 00 00 00 00 00 
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
2011-06-09 10:02:27.864670 < 01 11 04 02 0C 00 
2011-06-09 10:02:27.866587 > 04 0F 04 00 01 11 04 
2011-06-09 10:02:27.867596 > 04 17 06 6E F5 C1 5B 9B EC 
2011-06-09 10:02:27.867846 < 01 0B 04 16 6E F5 C1 5B 9B EC 04 E5 A3 63 F2 A4 56 70 F6 39 
  B0 7A BD 91 94 F6 
2011-06-09 10:02:27.879587 > 04 0E 0A 01 0B 04 00 6E F5 C1 5B 9B EC 
2011-06-09 10:02:27.897588 > 04 06 03 00 0C 00 
2011-06-09 10:02:27.897620 < 01 13 04 03 0C 00 01 
2011-06-09 10:02:27.899591 > 04 0F 04 00 01 13 04 
2011-06-09 10:02:27.927654 > 04 08 04 00 0C 00 01 
2011-06-09 10:02:27.927702 < 02 0C 00 0A 00 06 00 01 00 0A 01 02 00 02 00 
2011-06-09 10:02:27.933985 > 02 0C 20 10 00 0C 00 01 00 0B 01 08 00 02 00 00 00 00 00 00 
  00 
2011-06-09 10:02:28.075644 > 04 13 05 01 0C 00 01 00 
2011-06-09 10:02:31.299684 > 04 2F FF 01 6E F5 C1 5B 9B EC 01 00 00 01 5A FF 7F DD 05 09 
  6E 61 6D 69 17 03 03 11 15 11 17 11 16 11 12 11 1F 11 0A 11 
  0C 11 0E 11 05 11 06 11 00 00 00 00 00 00 00 00 00 00 00 00 
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
2011-06-09 10:02:35.975767 > 04 05 04 00 0C 00 13 
2011-06-09 10:02:35.978580 < 01 05 04 0D 6E F5 C1 5B 9B EC 18 CC 02 00 00 00 01 
2011-06-09 10:02:35.980698 > 04 0F 04 00 01 05 04 
2011-06-09 10:02:41.200825 > 04 01 01 00 
2011-06-09 10:02:42.562819 > 04 12 08 00 6E F5 C1 5B 9B EC 01 
2011-06-09 10:02:42.715788 > 04 03 0B 00 0C 00 6E F5 C1 5B 9B EC 01 00 
2011-06-09 10:02:42.715870 < 01 1B 04 02 0C 00 
2011-06-09 10:02:42.716794 > 04 1B 03 0C 00 05 
2011-06-09 10:02:42.718795 > 04 0F 04 00 01 1B 04 
2011-06-09 10:02:42.719791 > 04 0B 0B 00 0C 00 BF EE 0F C6 98 3D 59 82 
2011-06-09 10:02:42.719831 < 01 1C 04 03 0C 00 01 
2011-06-09 10:02:42.720791 > 04 1B 03 0C 00 03 
2011-06-09 10:02:42.722790 > 04 0F 04 00 01 1C 04 
2011-06-09 10:02:42.727796 > 04 23 0D 00 0C 00 01 01 01 00 00 00 00 00 00 00 
2011-06-09 10:02:42.727830 < 01 19 04 0A 6E F5 C1 5B 9B EC 02 00 00 00 
2011-06-09 10:02:42.729789 > 04 0F 04 00 01 19 04 
2011-06-09 10:02:42.749861 > 04 07 FF 00 6E F5 C1 5B 9B EC 6E 61 6D 69 00 00 00 00 00 00 
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
2011-06-09 10:02:42.749889 < 01 11 04 02 0C 00 
2011-06-09 10:02:42.751844 > 04 0F 04 00 01 11 04 
2011-06-09 10:02:42.752792 > 04 17 06 6E F5 C1 5B 9B EC 
2011-06-09 10:02:42.752933 < 01 0B 04 16 6E F5 C1 5B 9B EC 04 E5 A3 63 F2 A4 56 70 F6 39 
  B0 7A BD 91 94 F6 
2011-06-09 10:02:42.764900 > 04 0E 0A 01 0B 04 00 6E F5 C1 5B 9B EC 
2011-06-09 10:02:42.782857 > 04 06 03 00 0C 00 
2011-06-09 10:02:42.782894 < 01 13 04 03 0C 00 01 
2011-06-09 10:02:42.784842 > 04 0F 04 00 01 13 04 
2011-06-09 10:02:42.812897 > 04 08 04 00 0C 00 01 
2011-06-09 10:02:42.812939 < 02 0C 00 0A 00 06 00 01 00 0A 01 02 00 02 00 
2011-06-09 10:02:42.819490 > 02 0C 20 10 00 0C 00 01 00 0B 01 08 00 02 00 00 00 00 00 00 
  00 
2011-06-09 10:02:42.950848 > 04 13 05 01 0C 00 01 00 

-- 
keith.packard@intel.com

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

RE: Regression caused by "Bluetooth: Map sec_level to link key requirements"

[Waldemar.Rymarkiewicz]

Hi Keith,=20

>I re-pair'ed using a manually entered a 16 digit pin, but now=20
>DUN setup doesn't succeed at all.

Did you try to remove all stored link keys and start again?
If you already have a pincode which is insecure you have to remove it manua=
lly.

Try 'hciconfig hciX noauth noencrypt ' before.

Check syslog and switch debug on in the kernel first.


Waldek

Re: Regression caused by "Bluetooth: Map sec_level to link key requirements"

[Johan Hedberg]

Hi,

On Thu, Jun 09, 2011, Waldemar.Rymarkiewicz@tieto.com wrote:
> >I re-pair'ed using a manually entered a 16 digit pin, but now 
> >DUN setup doesn't succeed at all.
> 
> Did you try to remove all stored link keys and start again?
> If you already have a pincode which is insecure you have to remove it manually.
> 
> Try 'hciconfig hciX noauth noencrypt ' before.
> 
> Check syslog and switch debug on in the kernel first.

So I just realized that the BITE tests were only done for mgmtops.c and
not hciops.c. One critical difference is that conn->key_type will not be
set (or actually set to 0xff) for connections which happen after the
initial pairing has occurred. We're right now testing a one-line patch
which might fix the issue. Luiz will send it soon if it turns out to
work fine.

Johan

Re: Regression caused by "Bluetooth: Map sec_level to link key requirements"

[Luiz Augusto von Dentz]

Hi Keith,

On Fri, Jun 10, 2011 at 2:55 PM, Johan Hedberg <johan.hedberg@gmail.com> wrote:
> Hi,
>
> On Thu, Jun 09, 2011, Waldemar.Rymarkiewicz@tieto.com wrote:
>> >I re-pair'ed using a manually entered a 16 digit pin, but now
>> >DUN setup doesn't succeed at all.
>>
>> Did you try to remove all stored link keys and start again?
>> If you already have a pincode which is insecure you have to remove it manually.
>>
>> Try 'hciconfig hciX noauth noencrypt ' before.
>>
>> Check syslog and switch debug on in the kernel first.
>
> So I just realized that the BITE tests were only done for mgmtops.c and
> not hciops.c. One critical difference is that conn->key_type will not be
> set (or actually set to 0xff) for connections which happen after the
> initial pairing has occurred. We're right now testing a one-line patch
> which might fix the issue. Luiz will send it soon if it turns out to
> work fine.

So the fix we were testing looks like this:

diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
index 2f5ae53..b309f84 100644
--- a/net/bluetooth/hci_conn.c
+++ b/net/bluetooth/hci_conn.c
@@ -673,8 +673,8 @@ auth:
        if (test_and_set_bit(HCI_CONN_ENCRYPT_PEND, &conn->pend))
                return 0;

-       hci_conn_auth(conn, sec_level, auth_type);
-       return 0;
+       if (!(hci_conn_auth(conn, sec_level, auth_type)))
+               return 0;

 encrypt:
        if (conn->link_mode & HCI_LM_ENCRYPT)

-- 
Luiz Augusto von Dentz
Computer Engineer

Re: Regression caused by "Bluetooth: Map sec_level to link key requirements"

[Keith Packard]

[-- Attachment #1: Type: text/plain, Size: 759 bytes --]

On Fri, 10 Jun 2011 14:58:50 +0900, Luiz Augusto von Dentz <luiz.dentz@gmail.com> wrote:

> diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
> index 2f5ae53..b309f84 100644
> --- a/net/bluetooth/hci_conn.c
> +++ b/net/bluetooth/hci_conn.c
> @@ -673,8 +673,8 @@ auth:
>         if (test_and_set_bit(HCI_CONN_ENCRYPT_PEND, &conn->pend))
>                 return 0;
> 
> -       hci_conn_auth(conn, sec_level, auth_type);
> -       return 0;
> +       if (!(hci_conn_auth(conn, sec_level, auth_type)))
> +               return 0;
> 
>  encrypt:
>         if (conn->link_mode & HCI_LM_ENCRYPT)

That makes the first connection afer boot succeed, but subsequent
connections fail in the same way.

-- 
keith.packard@intel.com

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Regression caused by "Bluetooth: Map sec_level to link key requirements"

[Johan Hedberg]

Hi Keith,

On Sun, Jun 19, 2011, Keith Packard wrote:
> On Fri, 10 Jun 2011 14:58:50 +0900, Luiz Augusto von Dentz <luiz.dentz@gmail.com> wrote:
> 
> > diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
> > index 2f5ae53..b309f84 100644
> > --- a/net/bluetooth/hci_conn.c
> > +++ b/net/bluetooth/hci_conn.c
> > @@ -673,8 +673,8 @@ auth:
> >         if (test_and_set_bit(HCI_CONN_ENCRYPT_PEND, &conn->pend))
> >                 return 0;
> > 
> > -       hci_conn_auth(conn, sec_level, auth_type);
> > -       return 0;
> > +       if (!(hci_conn_auth(conn, sec_level, auth_type)))
> > +               return 0;
> > 
> >  encrypt:
> >         if (conn->link_mode & HCI_LM_ENCRYPT)
> 
> That makes the first connection afer boot succeed, but subsequent
> connections fail in the same way.

Did you try also the following patch (which should also be making it to
3.0):
http://git.kernel.org/?p=linux/kernel/git/padovan/bluetooth-2.6.git;a=commitdiff;h=330605423ca6eafafb8dcc27502bce1c585d1b06

I think you'll need both of them to fix the pairing/security issues.

Johan

Re: Regression caused by "Bluetooth: Map sec_level to link key requirements"

[Keith Packard]

[-- Attachment #1: Type: text/plain, Size: 312 bytes --]

On Sun, 19 Jun 2011 20:59:37 +0300, Johan Hedberg <johan.hedberg@gmail.com> wrote:

> I think you'll need both of them to fix the pairing/security issues.

Yup, with both of those patches, I get syncml and dun working again.

(sorry for the delayed testing, I'm traveling)

-- 
keith.packard@intel.com

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Regression caused by "Bluetooth: Map sec_level to link key requirements"

[Jeremy Fitzhardinge]

On 06/19/2011 12:01 PM, Keith Packard wrote:
>> I think you'll need both of them to fix the pairing/security issues.
> Yup, with both of those patches, I get syncml and dun working again.
>
> (sorry for the delayed testing, I'm traveling)

I just bisected the problems I had reconnecting my Nokia BH-905i
headphones to the same change that Keith identified, and merging
git://git.kernel.org/pub/scm/linux/kernel/git/padovan/bluetooth-2.6.git
into my tree fixed it.

So +1 from me to get this into mainline soon.

Thanks,
    J

Re: Regression caused by "Bluetooth: Map sec_level to link key requirements"

[Gustavo F. Padovan]

* Jeremy Fitzhardinge <jeremy@goop.org> [2011-06-24 22:45:02 -0700]:

> On 06/19/2011 12:01 PM, Keith Packard wrote:
> >> I think you'll need both of them to fix the pairing/security issues.
> > Yup, with both of those patches, I get syncml and dun working again.
> >
> > (sorry for the delayed testing, I'm traveling)
> 
> I just bisected the problems I had reconnecting my Nokia BH-905i
> headphones to the same change that Keith identified, and merging
> git://git.kernel.org/pub/scm/linux/kernel/git/padovan/bluetooth-2.6.git
> into my tree fixed it.
> 
> So +1 from me to get this into mainline soon.

It's on the way. Right now patches are on David Miller' tree.

	Gustavo