From c4f912e155504e94dd4f3d63c378dab0ff03dbda Mon Sep 17 00:00:00 2001
From: Marcel Holtmann <marcel@holtmann.org>
Date: Thu, 15 Jan 2009 21:52:16 +0100
Subject: Bluetooth: Add global deferred socket parameter

The L2CAP and RFCOMM applications require support for authorization
and the ability of rejecting incoming connection requests. The socket
interface is not really able to support this.

This patch does the ground work for a socket option to defer connection
setup. Setting this option allows calling of accept() and then the
first read() will trigger the final connection setup. Calling close()
would reject the connection.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
---
 include/net/bluetooth/bluetooth.h | 3 +++
 1 file changed, 3 insertions(+)

(limited to 'include/net/bluetooth')

diff --git a/include/net/bluetooth/bluetooth.h b/include/net/bluetooth/bluetooth.h
index a04f8463ac7..847e9e6df08 100644
--- a/include/net/bluetooth/bluetooth.h
+++ b/include/net/bluetooth/bluetooth.h
@@ -53,6 +53,8 @@
 #define SOL_SCO		17
 #define SOL_RFCOMM	18
 
+#define BT_DEFER_SETUP	7
+
 #define BT_INFO(fmt, arg...) printk(KERN_INFO "Bluetooth: " fmt "\n" , ## arg)
 #define BT_ERR(fmt, arg...)  printk(KERN_ERR "%s: " fmt "\n" , __func__ , ## arg)
 #define BT_DBG(fmt, arg...)  pr_debug("%s: " fmt "\n" , __func__ , ## arg)
@@ -108,6 +110,7 @@ struct bt_sock {
 	bdaddr_t    dst;
 	struct list_head accept_q;
 	struct sock *parent;
+	u32 defer_setup;
 };
 
 struct bt_sock_list {
-- 
cgit v1.2.3


From bb23c0ab824653be4aa7dfca15b07b3059717004 Mon Sep 17 00:00:00 2001
From: Marcel Holtmann <marcel@holtmann.org>
Date: Thu, 15 Jan 2009 21:56:48 +0100
Subject: Bluetooth: Add support for deferring RFCOMM connection setup

In order to decide if listening RFCOMM sockets should be accept()ed
the BD_ADDR of the remote device needs to be known. This patch adds
a socket option which defines a timeout for deferring the actual
connection setup.

The connection setup is done after reading from the socket for the
first time. Until then writing to the socket returns ENOTCONN.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
---
 include/net/bluetooth/rfcomm.h | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

(limited to 'include/net/bluetooth')

diff --git a/include/net/bluetooth/rfcomm.h b/include/net/bluetooth/rfcomm.h
index 4dc8d92a463..71b45f45968 100644
--- a/include/net/bluetooth/rfcomm.h
+++ b/include/net/bluetooth/rfcomm.h
@@ -185,6 +185,7 @@ struct rfcomm_dlc {
 	u8            out;
 
 	u32           link_mode;
+	u32           defer_setup;
 
 	uint          mtu;
 	uint          cfc;
@@ -202,10 +203,11 @@ struct rfcomm_dlc {
 #define RFCOMM_RX_THROTTLED 0
 #define RFCOMM_TX_THROTTLED 1
 #define RFCOMM_TIMED_OUT    2
-#define RFCOMM_MSC_PENDING  3 
+#define RFCOMM_MSC_PENDING  3
 #define RFCOMM_AUTH_PENDING 4
 #define RFCOMM_AUTH_ACCEPT  5
 #define RFCOMM_AUTH_REJECT  6
+#define RFCOMM_DEFER_SETUP  7
 
 /* Scheduling flags and events */
 #define RFCOMM_SCHED_STATE  0
@@ -239,6 +241,7 @@ int  rfcomm_dlc_close(struct rfcomm_dlc *d, int reason);
 int  rfcomm_dlc_send(struct rfcomm_dlc *d, struct sk_buff *skb);
 int  rfcomm_dlc_set_modem_status(struct rfcomm_dlc *d, u8 v24_sig);
 int  rfcomm_dlc_get_modem_status(struct rfcomm_dlc *d, u8 *v24_sig);
+void rfcomm_dlc_accept(struct rfcomm_dlc *d);
 
 #define rfcomm_dlc_lock(d)     spin_lock(&d->lock)
 #define rfcomm_dlc_unlock(d)   spin_unlock(&d->lock)
@@ -333,7 +336,6 @@ struct rfcomm_dev_req {
 	bdaddr_t src;
 	bdaddr_t dst;
 	u8       channel;
-	
 };
 
 struct rfcomm_dev_info {
-- 
cgit v1.2.3


From 8c1b235594fbab9a13240a1dac12ea9fd99b6440 Mon Sep 17 00:00:00 2001
From: Marcel Holtmann <marcel@holtmann.org>
Date: Thu, 15 Jan 2009 21:58:04 +0100
Subject: Bluetooth: Add enhanced security model for Simple Pairing

The current security model is based around the flags AUTH, ENCRYPT and
SECURE. Starting with support for the Bluetooth 2.1 specification this is
no longer sufficient. The different security levels are now defined as
SDP, LOW, MEDIUM and SECURE.

Previously it was possible to set each security independently, but this
actually doesn't make a lot of sense. For Bluetooth the encryption depends
on a previous successful authentication. Also you can only update your
existing link key if you successfully created at least one before. And of
course the update of link keys without having proper encryption in place
is a security issue.

The new security levels from the Bluetooth 2.1 specification are now
used internally. All old settings are mapped to the new values and this
way it ensures that old applications still work. The only limitation
is that it is no longer possible to set authentication without also
enabling encryption. No application should have done this anyway since
this is actually a security issue. Without encryption the integrity of
the authentication can't be guaranteed.

As default for a new L2CAP or RFCOMM connection, the LOW security level
is used. The only exception here are the service discovery sessions on
PSM 1 where SDP level is used. To have similar security strength as with
a Bluetooth 2.0 and before combination key, the MEDIUM level should be
used. This is according to the Bluetooth specification. The MEDIUM level
will not require any kind of man-in-the-middle (MITM) protection. Only
the HIGH security level will require this.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
---
 include/net/bluetooth/bluetooth.h |  9 +++++++
 include/net/bluetooth/hci_core.h  | 56 +++++++++++++++++++++++----------------
 2 files changed, 42 insertions(+), 23 deletions(-)

(limited to 'include/net/bluetooth')

diff --git a/include/net/bluetooth/bluetooth.h b/include/net/bluetooth/bluetooth.h
index 847e9e6df08..3ad5390a4dd 100644
--- a/include/net/bluetooth/bluetooth.h
+++ b/include/net/bluetooth/bluetooth.h
@@ -53,6 +53,15 @@
 #define SOL_SCO		17
 #define SOL_RFCOMM	18
 
+#define BT_SECURITY	4
+struct bt_security {
+	__u8 level;
+};
+#define BT_SECURITY_SDP		0
+#define BT_SECURITY_LOW		1
+#define BT_SECURITY_MEDIUM	2
+#define BT_SECURITY_HIGH	3
+
 #define BT_DEFER_SETUP	7
 
 #define BT_INFO(fmt, arg...) printk(KERN_INFO "Bluetooth: " fmt "\n" , ## arg)
diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
index 46a43b721dd..4b14972c169 100644
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -169,6 +169,7 @@ struct hci_conn {
 	__u16            link_policy;
 	__u32		 link_mode;
 	__u8             auth_type;
+	__u8             sec_level;
 	__u8             power_save;
 	unsigned long	 pend;
 
@@ -325,12 +326,11 @@ int hci_conn_del(struct hci_conn *conn);
 void hci_conn_hash_flush(struct hci_dev *hdev);
 void hci_conn_check_pending(struct hci_dev *hdev);
 
-struct hci_conn *hci_connect(struct hci_dev *hdev, int type, bdaddr_t *dst, __u8 auth_type);
+struct hci_conn *hci_connect(struct hci_dev *hdev, int type, bdaddr_t *dst, __u8 sec_level, __u8 auth_type);
 int hci_conn_check_link_mode(struct hci_conn *conn);
-int hci_conn_auth(struct hci_conn *conn);
-int hci_conn_encrypt(struct hci_conn *conn);
+int hci_conn_security(struct hci_conn *conn, __u8 sec_level);
 int hci_conn_change_link_key(struct hci_conn *conn);
-int hci_conn_switch_role(struct hci_conn *conn, uint8_t role);
+int hci_conn_switch_role(struct hci_conn *conn, __u8 role);
 
 void hci_conn_enter_active_mode(struct hci_conn *conn);
 void hci_conn_enter_sniff_mode(struct hci_conn *conn);
@@ -470,26 +470,25 @@ void hci_conn_del_sysfs(struct hci_conn *conn);
 
 /* ----- HCI protocols ----- */
 struct hci_proto {
-	char 		*name;
+	char		*name;
 	unsigned int	id;
 	unsigned long	flags;
 
 	void		*priv;
 
-	int (*connect_ind) 	(struct hci_dev *hdev, bdaddr_t *bdaddr, __u8 type);
+	int (*connect_ind)	(struct hci_dev *hdev, bdaddr_t *bdaddr, __u8 type);
 	int (*connect_cfm)	(struct hci_conn *conn, __u8 status);
 	int (*disconn_ind)	(struct hci_conn *conn, __u8 reason);
 	int (*recv_acldata)	(struct hci_conn *conn, struct sk_buff *skb, __u16 flags);
 	int (*recv_scodata)	(struct hci_conn *conn, struct sk_buff *skb);
-	int (*auth_cfm)		(struct hci_conn *conn, __u8 status);
-	int (*encrypt_cfm)	(struct hci_conn *conn, __u8 status, __u8 encrypt);
+	int (*security_cfm)	(struct hci_conn *conn, __u8 status, __u8 encrypt);
 };
 
 static inline int hci_proto_connect_ind(struct hci_dev *hdev, bdaddr_t *bdaddr, __u8 type)
 {
 	register struct hci_proto *hp;
 	int mask = 0;
-	
+
 	hp = hci_proto[HCI_PROTO_L2CAP];
 	if (hp && hp->connect_ind)
 		mask |= hp->connect_ind(hdev, bdaddr, type);
@@ -530,14 +529,20 @@ static inline void hci_proto_disconn_ind(struct hci_conn *conn, __u8 reason)
 static inline void hci_proto_auth_cfm(struct hci_conn *conn, __u8 status)
 {
 	register struct hci_proto *hp;
+	__u8 encrypt;
+
+	if (test_bit(HCI_CONN_ENCRYPT_PEND, &conn->pend))
+		return;
+
+	encrypt = (conn->link_mode & HCI_LM_ENCRYPT) ? 0x01 : 0x00;
 
 	hp = hci_proto[HCI_PROTO_L2CAP];
-	if (hp && hp->auth_cfm)
-		hp->auth_cfm(conn, status);
+	if (hp && hp->security_cfm)
+		hp->security_cfm(conn, status, encrypt);
 
 	hp = hci_proto[HCI_PROTO_SCO];
-	if (hp && hp->auth_cfm)
-		hp->auth_cfm(conn, status);
+	if (hp && hp->security_cfm)
+		hp->security_cfm(conn, status, encrypt);
 }
 
 static inline void hci_proto_encrypt_cfm(struct hci_conn *conn, __u8 status, __u8 encrypt)
@@ -545,12 +550,12 @@ static inline void hci_proto_encrypt_cfm(struct hci_conn *conn, __u8 status, __u
 	register struct hci_proto *hp;
 
 	hp = hci_proto[HCI_PROTO_L2CAP];
-	if (hp && hp->encrypt_cfm)
-		hp->encrypt_cfm(conn, status, encrypt);
+	if (hp && hp->security_cfm)
+		hp->security_cfm(conn, status, encrypt);
 
 	hp = hci_proto[HCI_PROTO_SCO];
-	if (hp && hp->encrypt_cfm)
-		hp->encrypt_cfm(conn, status, encrypt);
+	if (hp && hp->security_cfm)
+		hp->security_cfm(conn, status, encrypt);
 }
 
 int hci_register_proto(struct hci_proto *hproto);
@@ -562,8 +567,7 @@ struct hci_cb {
 
 	char *name;
 
-	void (*auth_cfm)	(struct hci_conn *conn, __u8 status);
-	void (*encrypt_cfm)	(struct hci_conn *conn, __u8 status, __u8 encrypt);
+	void (*security_cfm)	(struct hci_conn *conn, __u8 status, __u8 encrypt);
 	void (*key_change_cfm)	(struct hci_conn *conn, __u8 status);
 	void (*role_switch_cfm)	(struct hci_conn *conn, __u8 status, __u8 role);
 };
@@ -571,14 +575,20 @@ struct hci_cb {
 static inline void hci_auth_cfm(struct hci_conn *conn, __u8 status)
 {
 	struct list_head *p;
+	__u8 encrypt;
 
 	hci_proto_auth_cfm(conn, status);
 
+	if (test_bit(HCI_CONN_ENCRYPT_PEND, &conn->pend))
+		return;
+
+	encrypt = (conn->link_mode & HCI_LM_ENCRYPT) ? 0x01 : 0x00;
+
 	read_lock_bh(&hci_cb_list_lock);
 	list_for_each(p, &hci_cb_list) {
 		struct hci_cb *cb = list_entry(p, struct hci_cb, list);
-		if (cb->auth_cfm)
-			cb->auth_cfm(conn, status);
+		if (cb->security_cfm)
+			cb->security_cfm(conn, status, encrypt);
 	}
 	read_unlock_bh(&hci_cb_list_lock);
 }
@@ -592,8 +602,8 @@ static inline void hci_encrypt_cfm(struct hci_conn *conn, __u8 status, __u8 encr
 	read_lock_bh(&hci_cb_list_lock);
 	list_for_each(p, &hci_cb_list) {
 		struct hci_cb *cb = list_entry(p, struct hci_cb, list);
-		if (cb->encrypt_cfm)
-			cb->encrypt_cfm(conn, status, encrypt);
+		if (cb->security_cfm)
+			cb->security_cfm(conn, status, encrypt);
 	}
 	read_unlock_bh(&hci_cb_list_lock);
 }
-- 
cgit v1.2.3


From 2af6b9d518ddfbc4d6990d5f9c9b1a05341c1cef Mon Sep 17 00:00:00 2001
From: Marcel Holtmann <marcel@holtmann.org>
Date: Thu, 15 Jan 2009 21:58:38 +0100
Subject: Bluetooth: Replace L2CAP link mode with security level

Change the L2CAP internals to use the new security levels and remove
the link mode details.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
---
 include/net/bluetooth/l2cap.h | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

(limited to 'include/net/bluetooth')

diff --git a/include/net/bluetooth/l2cap.h b/include/net/bluetooth/l2cap.h
index 73e115bc12d..29f720e6188 100644
--- a/include/net/bluetooth/l2cap.h
+++ b/include/net/bluetooth/l2cap.h
@@ -237,8 +237,9 @@ struct l2cap_pinfo {
 	__u16		imtu;
 	__u16		omtu;
 	__u16		flush_to;
-
-	__u32		link_mode;
+	__u8            sec_level;
+	__u8		role_switch;
+	__u8            force_reliable;
 
 	__u8		conf_req[64];
 	__u8		conf_len;
-- 
cgit v1.2.3


From 9f2c8a03fbb3048cf38b158f87aa0c3c09bca084 Mon Sep 17 00:00:00 2001
From: Marcel Holtmann <marcel@holtmann.org>
Date: Thu, 15 Jan 2009 21:58:40 +0100
Subject: Bluetooth: Replace RFCOMM link mode with security level

Change the RFCOMM internals to use the new security levels and remove
the link mode details.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
---
 include/net/bluetooth/rfcomm.h | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

(limited to 'include/net/bluetooth')

diff --git a/include/net/bluetooth/rfcomm.h b/include/net/bluetooth/rfcomm.h
index 71b45f45968..bda68d833dd 100644
--- a/include/net/bluetooth/rfcomm.h
+++ b/include/net/bluetooth/rfcomm.h
@@ -183,8 +183,8 @@ struct rfcomm_dlc {
 	u8            remote_v24_sig;
 	u8            mscex;
 	u8            out;
-
-	u32           link_mode;
+	u8            sec_level;
+	u8            role_switch;
 	u32           defer_setup;
 
 	uint          mtu;
@@ -307,7 +307,8 @@ struct rfcomm_pinfo {
 	struct bt_sock bt;
 	struct rfcomm_dlc   *dlc;
 	u8     channel;
-	u32    link_mode;
+	u8     sec_level;
+	u8     role_switch;
 };
 
 int  rfcomm_init_sockets(void);
-- 
cgit v1.2.3


From 8c84b83076b5062f59b6167cdda90d9e5124aa71 Mon Sep 17 00:00:00 2001
From: Marcel Holtmann <marcel@holtmann.org>
Date: Fri, 16 Jan 2009 08:17:51 +0100
Subject: Bluetooth: Pause RFCOMM TX when encryption drops

A role switch with devices following the Bluetooth pre-2.1 standards
or without Encryption Pause and Resume support is not possible if
encryption is enabled. Most newer headsets require the role switch,
but also require that the connection is encrypted.

For connections with a high security mode setting, the link will be
immediately dropped. When the connection uses medium security mode
setting, then a grace period is introduced where the TX is halted and
the remote device gets a change to re-enable encryption after the
role switch. If not re-enabled the link will be dropped.

Based on initial work by Ville Tervo <ville.tervo@nokia.com>

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
---
 include/net/bluetooth/rfcomm.h | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

(limited to 'include/net/bluetooth')

diff --git a/include/net/bluetooth/rfcomm.h b/include/net/bluetooth/rfcomm.h
index bda68d833dd..80072611d26 100644
--- a/include/net/bluetooth/rfcomm.h
+++ b/include/net/bluetooth/rfcomm.h
@@ -204,10 +204,11 @@ struct rfcomm_dlc {
 #define RFCOMM_TX_THROTTLED 1
 #define RFCOMM_TIMED_OUT    2
 #define RFCOMM_MSC_PENDING  3
-#define RFCOMM_AUTH_PENDING 4
-#define RFCOMM_AUTH_ACCEPT  5
-#define RFCOMM_AUTH_REJECT  6
-#define RFCOMM_DEFER_SETUP  7
+#define RFCOMM_SEC_PENDING  4
+#define RFCOMM_AUTH_PENDING 5
+#define RFCOMM_AUTH_ACCEPT  6
+#define RFCOMM_AUTH_REJECT  7
+#define RFCOMM_DEFER_SETUP  8
 
 /* Scheduling flags and events */
 #define RFCOMM_SCHED_STATE  0
-- 
cgit v1.2.3


From efc7688b557dd1be10eead7399b315efcb1dbc74 Mon Sep 17 00:00:00 2001
From: Marcel Holtmann <marcel@holtmann.org>
Date: Fri, 6 Feb 2009 09:13:37 +0100
Subject: Bluetooth: Add SCO fallback for eSCO connection attempts

When attempting to setup eSCO connections it can happen that some link
manager implementations fail to properly negotiate the eSCO parameters
and thus fail the eSCO setup. Normally the link manager is responsible
for the negotiation of the parameters and actually fallback to SCO if
no agreement can be reached. In cases where the link manager is just too
stupid, then at least try to establish a SCO link if eSCO fails.

For the Bluetooth devices with EDR support this includes handling packet
types of EDR basebands. This is particular tricky since for the EDR the
logic of enabling/disabling one specific packet type is turned around.
This fix contains an extra bitmask to disable eSCO EDR packet when
trying to fallback to a SCO connection.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
---
 include/net/bluetooth/hci.h | 8 ++++++++
 1 file changed, 8 insertions(+)

(limited to 'include/net/bluetooth')

diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
index 3645139e68c..f69f015bbcc 100644
--- a/include/net/bluetooth/hci.h
+++ b/include/net/bluetooth/hci.h
@@ -133,8 +133,13 @@ enum {
 #define ESCO_EV3	0x0008
 #define ESCO_EV4	0x0010
 #define ESCO_EV5	0x0020
+#define ESCO_2EV3	0x0040
+#define ESCO_3EV3	0x0080
+#define ESCO_2EV5	0x0100
+#define ESCO_3EV5	0x0200
 
 #define SCO_ESCO_MASK  (ESCO_HV1 | ESCO_HV2 | ESCO_HV3)
+#define EDR_ESCO_MASK  (ESCO_2EV3 | ESCO_3EV3 | ESCO_2EV5 | ESCO_3EV5)
 
 /* ACL flags */
 #define ACL_CONT		0x01
@@ -176,6 +181,9 @@ enum {
 #define LMP_EV5		0x02
 
 #define LMP_SNIFF_SUBR	0x02
+#define LMP_EDR_ESCO_2M	0x20
+#define LMP_EDR_ESCO_3M	0x40
+#define LMP_EDR_3S_ESCO	0x80
 
 #define LMP_SIMPLE_PAIR	0x08
 
-- 
cgit v1.2.3


From 0684e5f9fb9e3f7e168ab831dfca693bcb44805b Mon Sep 17 00:00:00 2001
From: Marcel Holtmann <marcel@holtmann.org>
Date: Mon, 9 Feb 2009 02:48:38 +0100
Subject: Bluetooth: Use general bonding whenever possible

When receiving incoming connection to specific services, always use
general bonding. This ensures that the link key gets stored and can be
used for further authentications.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
---
 include/net/bluetooth/hci_core.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

(limited to 'include/net/bluetooth')

diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
index 4b14972c169..f75028b3388 100644
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -328,7 +328,7 @@ void hci_conn_check_pending(struct hci_dev *hdev);
 
 struct hci_conn *hci_connect(struct hci_dev *hdev, int type, bdaddr_t *dst, __u8 sec_level, __u8 auth_type);
 int hci_conn_check_link_mode(struct hci_conn *conn);
-int hci_conn_security(struct hci_conn *conn, __u8 sec_level);
+int hci_conn_security(struct hci_conn *conn, __u8 sec_level, __u8 auth_type);
 int hci_conn_change_link_key(struct hci_conn *conn);
 int hci_conn_switch_role(struct hci_conn *conn, __u8 role);
 
-- 
cgit v1.2.3


From 984947dc64f82bc6cafa4d84ba1a139718f634a8 Mon Sep 17 00:00:00 2001
From: Marcel Holtmann <marcel@holtmann.org>
Date: Fri, 6 Feb 2009 23:35:19 +0100
Subject: Bluetooth: Fix race condition with L2CAP information request

When two L2CAP connections are requested quickly after the ACL link has
been established there exists a window for a race condition where a
connection request is sent before the information response has been
received. Any connection request should only be sent after an exchange
of the extended features mask has been finished.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
---
 include/net/bluetooth/l2cap.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

(limited to 'include/net/bluetooth')

diff --git a/include/net/bluetooth/l2cap.h b/include/net/bluetooth/l2cap.h
index 29f720e6188..1c8cf3e9b1c 100644
--- a/include/net/bluetooth/l2cap.h
+++ b/include/net/bluetooth/l2cap.h
@@ -223,7 +223,8 @@ struct l2cap_conn {
 };
 
 #define L2CAP_INFO_CL_MTU_REQ_SENT	0x01
-#define L2CAP_INFO_FEAT_MASK_REQ_SENT	0x02
+#define L2CAP_INFO_FEAT_MASK_REQ_SENT	0x04
+#define L2CAP_INFO_FEAT_MASK_REQ_DONE	0x08
 
 /* ----- L2CAP channel and socket info ----- */
 #define l2cap_pi(sk) ((struct l2cap_pinfo *) sk)
-- 
cgit v1.2.3


From 6a8d3010b313d99adbb28f1826fac0234395bb26 Mon Sep 17 00:00:00 2001
From: Marcel Holtmann <marcel@holtmann.org>
Date: Fri, 6 Feb 2009 23:56:36 +0100
Subject: Bluetooth: Fix double L2CAP connection request

If the remote L2CAP server uses authentication pending stage and
encryption is enabled it can happen that a L2CAP connection request is
sent twice due to a race condition in the connection state machine.

When the remote side indicates any kind of connection pending, then
track this state and skip sending of L2CAP commands for this period.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
---
 include/net/bluetooth/l2cap.h | 1 +
 1 file changed, 1 insertion(+)

(limited to 'include/net/bluetooth')

diff --git a/include/net/bluetooth/l2cap.h b/include/net/bluetooth/l2cap.h
index 1c8cf3e9b1c..4781d285b2e 100644
--- a/include/net/bluetooth/l2cap.h
+++ b/include/net/bluetooth/l2cap.h
@@ -259,6 +259,7 @@ struct l2cap_pinfo {
 #define L2CAP_CONF_REQ_SENT	0x01
 #define L2CAP_CONF_INPUT_DONE	0x02
 #define L2CAP_CONF_OUTPUT_DONE	0x04
+#define L2CAP_CONF_CONNECT_PEND	0x80
 
 #define L2CAP_CONF_MAX_RETRIES	2
 
-- 
cgit v1.2.3


From 435fef20acfc48f46476abad55b0cd3aa47b8365 Mon Sep 17 00:00:00 2001
From: Marcel Holtmann <marcel@holtmann.org>
Date: Mon, 9 Feb 2009 03:55:28 +0100
Subject: Bluetooth: Don't enforce authentication for L2CAP PSM 1 and 3

The recommendation for the L2CAP PSM 1 (SDP) is to not use any kind
of authentication or encryption. So don't trigger authentication
for incoming and outgoing SDP connections.

For L2CAP PSM 3 (RFCOMM) there is no clear requirement, but with
Bluetooth 2.1 the initiator is required to enable authentication
and encryption first and this gets enforced. So there is no need
to trigger an additional authentication step. The RFCOMM service
security will make sure that a secure enough link key is present.

When the encryption gets enabled after the SDP connection setup,
then switch the security level from SDP to low security.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
---
 include/net/bluetooth/hci_core.h | 3 +++
 1 file changed, 3 insertions(+)

(limited to 'include/net/bluetooth')

diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
index f75028b3388..9473fce499e 100644
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -597,6 +597,9 @@ static inline void hci_encrypt_cfm(struct hci_conn *conn, __u8 status, __u8 encr
 {
 	struct list_head *p;
 
+	if (conn->sec_level == BT_SECURITY_SDP)
+		conn->sec_level = BT_SECURITY_LOW;
+
 	hci_proto_encrypt_cfm(conn, status, encrypt);
 
 	read_lock_bh(&hci_cb_list_lock);
-- 
cgit v1.2.3


From e1027a7c69700301d14db03d2e049ee60c4f92df Mon Sep 17 00:00:00 2001
From: Marcel Holtmann <marcel@holtmann.org>
Date: Mon, 9 Feb 2009 09:18:02 +0100
Subject: Bluetooth: Request L2CAP fixed channel list if available

If the extended features mask indicates support for fixed channels,
request the list of available fixed channels. This also enables the
fixed channel features bit so remote implementations can request
information about it. Currently only the signal channel will be
listed.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
---
 include/net/bluetooth/l2cap.h | 1 +
 1 file changed, 1 insertion(+)

(limited to 'include/net/bluetooth')

diff --git a/include/net/bluetooth/l2cap.h b/include/net/bluetooth/l2cap.h
index 4781d285b2e..abfec884771 100644
--- a/include/net/bluetooth/l2cap.h
+++ b/include/net/bluetooth/l2cap.h
@@ -185,6 +185,7 @@ struct l2cap_info_rsp {
 /* info type */
 #define L2CAP_IT_CL_MTU     0x0001
 #define L2CAP_IT_FEAT_MASK  0x0002
+#define L2CAP_IT_FIXED_CHAN 0x0003
 
 /* info result */
 #define L2CAP_IR_SUCCESS    0x0000
-- 
cgit v1.2.3


From f29972de8e7476706ab3c01304a505e7c95d9040 Mon Sep 17 00:00:00 2001
From: Marcel Holtmann <marcel@holtmann.org>
Date: Thu, 12 Feb 2009 05:07:45 +0100
Subject: Bluetooth: Add CID field to L2CAP socket address structure

In preparation for L2CAP fixed channel support, the CID value of a
L2CAP connection needs to be accessible via the socket interface. The
CID is the connection identifier and exists as source and destination
value. So extend the L2CAP socket address structure with this field and
change getsockname() and getpeername() to fill it in.

The bind() and connect() functions have been modified to handle L2CAP
socket address structures of variable sizes. This makes them future
proof if additional fields need to be added.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
---
 include/net/bluetooth/l2cap.h | 1 +
 1 file changed, 1 insertion(+)

(limited to 'include/net/bluetooth')

diff --git a/include/net/bluetooth/l2cap.h b/include/net/bluetooth/l2cap.h
index abfec884771..54737c5dc86 100644
--- a/include/net/bluetooth/l2cap.h
+++ b/include/net/bluetooth/l2cap.h
@@ -37,6 +37,7 @@ struct sockaddr_l2 {
 	sa_family_t	l2_family;
 	__le16		l2_psm;
 	bdaddr_t	l2_bdaddr;
+	__le16		l2_cid;
 };
 
 /* L2CAP socket options */
-- 
cgit v1.2.3


From 2950f21acb0f6b8fcd964485c2ebf1e06545ac20 Mon Sep 17 00:00:00 2001
From: Marcel Holtmann <marcel@holtmann.org>
Date: Thu, 12 Feb 2009 14:02:50 +0100
Subject: Bluetooth: Ask upper layers for HCI disconnect reason

Some of the qualification tests demand that in case of failures in L2CAP
the HCI disconnect should indicate a reason why L2CAP fails. This is a
bluntly layer violation since multiple L2CAP connections could be using
the same ACL and thus forcing a disconnect reason is not a good idea.

To comply with the Bluetooth test specification, the disconnect reason
is now stored in the L2CAP connection structure and every time a new
L2CAP channel is added it will set back to its default. So only in the
case where the L2CAP channel with the disconnect reason is really the
last one, it will propagated to the HCI layer.

The HCI layer has been extended with a disconnect indication that allows
it to ask upper layers for a disconnect reason. The upper layer must not
support this callback and in that case it will nicely default to the
existing behavior. If an upper layer like L2CAP can provide a disconnect
reason that one will be used to disconnect the ACL or SCO link.

No modification to the ACL disconnect timeout have been made. So in case
of Linux to Linux connection the initiator will disconnect the ACL link
before the acceptor side can signal the specific disconnect reason. That
is perfectly fine since Linux doesn't make use of this value anyway. The
L2CAP layer has a perfect valid error code for rejecting connection due
to a security violation. It is unclear why the Bluetooth specification
insists on having specific HCI disconnect reason.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
---
 include/net/bluetooth/hci_core.h | 25 +++++++++++++++++++++----
 include/net/bluetooth/l2cap.h    |  2 ++
 2 files changed, 23 insertions(+), 4 deletions(-)

(limited to 'include/net/bluetooth')

diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
index 9473fce499e..01f9316b4c2 100644
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -478,7 +478,8 @@ struct hci_proto {
 
 	int (*connect_ind)	(struct hci_dev *hdev, bdaddr_t *bdaddr, __u8 type);
 	int (*connect_cfm)	(struct hci_conn *conn, __u8 status);
-	int (*disconn_ind)	(struct hci_conn *conn, __u8 reason);
+	int (*disconn_ind)	(struct hci_conn *conn);
+	int (*disconn_cfm)	(struct hci_conn *conn, __u8 reason);
 	int (*recv_acldata)	(struct hci_conn *conn, struct sk_buff *skb, __u16 flags);
 	int (*recv_scodata)	(struct hci_conn *conn, struct sk_buff *skb);
 	int (*security_cfm)	(struct hci_conn *conn, __u8 status, __u8 encrypt);
@@ -513,17 +514,33 @@ static inline void hci_proto_connect_cfm(struct hci_conn *conn, __u8 status)
 		hp->connect_cfm(conn, status);
 }
 
-static inline void hci_proto_disconn_ind(struct hci_conn *conn, __u8 reason)
+static inline int hci_proto_disconn_ind(struct hci_conn *conn)
 {
 	register struct hci_proto *hp;
+	int reason = 0x13;
 
 	hp = hci_proto[HCI_PROTO_L2CAP];
 	if (hp && hp->disconn_ind)
-		hp->disconn_ind(conn, reason);
+		reason = hp->disconn_ind(conn);
 
 	hp = hci_proto[HCI_PROTO_SCO];
 	if (hp && hp->disconn_ind)
-		hp->disconn_ind(conn, reason);
+		reason = hp->disconn_ind(conn);
+
+	return reason;
+}
+
+static inline void hci_proto_disconn_cfm(struct hci_conn *conn, __u8 reason)
+{
+	register struct hci_proto *hp;
+
+	hp = hci_proto[HCI_PROTO_L2CAP];
+	if (hp && hp->disconn_cfm)
+		hp->disconn_cfm(conn, reason);
+
+	hp = hci_proto[HCI_PROTO_SCO];
+	if (hp && hp->disconn_cfm)
+		hp->disconn_cfm(conn, reason);
 }
 
 static inline void hci_proto_auth_cfm(struct hci_conn *conn, __u8 status)
diff --git a/include/net/bluetooth/l2cap.h b/include/net/bluetooth/l2cap.h
index 54737c5dc86..f566aa1f0a4 100644
--- a/include/net/bluetooth/l2cap.h
+++ b/include/net/bluetooth/l2cap.h
@@ -221,6 +221,8 @@ struct l2cap_conn {
 	__u8		rx_ident;
 	__u8		tx_ident;
 
+	__u8		disc_reason;
+
 	struct l2cap_chan_list chan_list;
 };
 
-- 
cgit v1.2.3