Some kernel changes

RFC In review Ville Tervo 5 participants 20 messages Jan 10, 2009 – Jan 28, 2009

Subsystems (2)

Bluetooth drivers Bluetooth

lore

Share & tools

lore

Ville Tervo

author

2009-01-10 12:33 UTC #0 lore raw

RFC 1/1 Some kernel changes

Hi,

Here is set of unclean patches for discussion. These are still untested and contain issues, but I would like to know if we should continue with these or change something radically. Also commit messages are somewhat misleading in some places.

Basically idea is to implement connection rejection support for l2cap and rfcomm sockets. IOW possibility to check initiator bd-address and ask for authorization before accepting connection.

Other goal is to fix encryption and authentication levels to fulfill 2.1 requirements.

Signature · 1 line

Ville

Quoted 1 line

From 954d3e82ee5e0a8a440021a80d763922bd5d0e55 Mon Sep 17 00:00:00 2001

From: Ville Tervo <[email protected]>
Date: Thu, 18 Dec 2008 16:43:33 +0200
Subject: [PATCH 1/7] Support for deferring rfcomm connection

In order to decide if listening rfcomm socket should be accept()ed the bd_addr of remote device needs to be known. This patch add a socket option which defines timeout for deferring connection setup.

The connection is actually allowed after reading from socket first time. Until reading first time writing to socket returns -ENOTCONN.

Signed-off-by Ville Tervo <[email protected]>

---
 include/net/bluetooth/bluetooth.h |    4 +
 include/net/bluetooth/rfcomm.h    |    6 ++-
 net/bluetooth/rfcomm/core.c       |   48 ++++++++++++++--
 net/bluetooth/rfcomm/sock.c       |  111 ++++++++++++++++++++++++++-----------
 4 files changed, 130 insertions(+), 39 deletions(-)

include/net/bluetooth/bluetooth.h +4 -0

index 6f8418b..1a0fa21 100644
@@ -53,6 +53,10 @@
 #define SOL_SCO		17
 #define SOL_RFCOMM	18
 
+#define BT_INFORMATION	0x01
+
+#define BT_DEFER_SETUP	0x02
+
 #define BT_INFO(fmt, arg...) printk(KERN_INFO "Bluetooth: " fmt "\n" , ## arg)
 #define BT_DBG(fmt, arg...)  printk(KERN_INFO "%s: " fmt "\n" , __FUNCTION__ , ## arg)
 #define BT_ERR(fmt, arg...)  printk(KERN_ERR  "%s: " fmt "\n" , __FUNCTION__ , ## arg)

include/net/bluetooth/rfcomm.h +5 -1

index 4dc8d92..eaa1365 100644
@@ -184,6 +184,7 @@ struct rfcomm_dlc {
 	u8            mscex;
 	u8            out;
 
+	u32           defer_setup;
 	u32           link_mode;
 
 	uint          mtu;

@@ -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);
+int  rfcomm_dlc_accept_conn(struct rfcomm_dlc *d);
 
 #define rfcomm_dlc_lock(d)     spin_lock(&d->lock)
 #define rfcomm_dlc_unlock(d)   spin_unlock(&d->lock)

@@ -305,6 +308,7 @@ struct rfcomm_pinfo {
 	struct rfcomm_dlc   *dlc;
 	u8     channel;
 	u32    link_mode;
+	u32    defer_setup;
 };
 
 int  rfcomm_init_sockets(void);

net/bluetooth/rfcomm/core.c +42 -6

96 lines not on this page · raw message

net/bluetooth/rfcomm/sock.c +79 ~~-32~~

188 lines not on this page · raw message

Signature · 1 line

1.6.0.4

Quoted 1 line

From 0b28c2c7d0fa9df936995019522f887e9d743ef2 Mon Sep 17 00:00:00 2001

From: Ville Tervo <[email protected]>
Date: Mon, 22 Dec 2008 15:22:23 +0200
Subject: [PATCH 2/7] bluetooth: Introduce security levels

This patch introduces security levels for RFCOMM sockets.

---
 include/net/bluetooth/bluetooth.h |    9 +++++++++
 include/net/bluetooth/hci_core.h  |    1 +
 include/net/bluetooth/l2cap.h     |    2 ++
 include/net/bluetooth/rfcomm.h    |    2 ++
 net/bluetooth/rfcomm/core.c       |   36 ++++++++++++++++++++++++++++++++----
 net/bluetooth/rfcomm/sock.c       |   34 +++++++++++++++++++++++++++++++++-
 6 files changed, 79 insertions(+), 5 deletions(-)

include/net/bluetooth/bluetooth.h +9 -0

index 1a0fa21..b5af61c 100644
@@ -57,6 +57,15 @@
 
 #define BT_DEFER_SETUP	0x02
 
+#define BT_SECURITY	0x03
+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_INFO(fmt, arg...) printk(KERN_INFO "Bluetooth: " fmt "\n" , ## arg)
 #define BT_DBG(fmt, arg...)  printk(KERN_INFO "%s: " fmt "\n" , __FUNCTION__ , ## arg)
 #define BT_ERR(fmt, arg...)  printk(KERN_ERR  "%s: " fmt "\n" , __FUNCTION__ , ## arg)

include/net/bluetooth/hci_core.h +1 -0

index 019cd93..419c518 100644
@@ -169,6 +169,7 @@ struct hci_conn {
 	__u16            link_policy;
 	__u32		 link_mode;
 	__u8             auth_type;
+	__u8		 seclevel;
 	__u8             power_save;
 	unsigned long	 pend;

include/net/bluetooth/l2cap.h +2 -0

index 73e115b..a178778 100644
@@ -234,10 +234,12 @@ struct l2cap_pinfo {
 	__u16		dcid;
 	__u16		scid;
 
+	__u8		seclevel;
 	__u16		imtu;
 	__u16		omtu;
 	__u16		flush_to;
 
+	__u32		defer_setup;
 	__u32		link_mode;
 
 	__u8		conf_req[64];

include/net/bluetooth/rfcomm.h +2 -0

index eaa1365..7161def 100644
@@ -186,6 +186,7 @@ struct rfcomm_dlc {
 
 	u32           defer_setup;
 	u32           link_mode;
+	u8            seclevel;
 
 	uint          mtu;
 	uint          cfc;

@@ -309,6 +310,7 @@ struct rfcomm_pinfo {
 	u8     channel;
 	u32    link_mode;
 	u32    defer_setup;
+	u8     seclevel;
 };
 
 int  rfcomm_init_sockets(void);

net/bluetooth/rfcomm/core.c +32 -4

index 7878e3c..f0cd6ee 100644
@@ -239,6 +239,20 @@ static inline int rfcomm_check_link_mode(struct rfcomm_dlc *d)
 {
 	struct sock *sk = d->session->sock->sk;
 
+	if (d->seclevel == BT_SECURITY_HIGH)
+		if (!hci_conn_auth(l2cap_pi(sk)->conn->hcon))
+			return 1;
+
+	if (d->seclevel == BT_SECURITY_MEDIUM)
+		if (!hci_conn_encrypt(l2cap_pi(sk)->conn->hcon))
+			return 1;
+
+	if (d->seclevel == BT_SECURITY_LOW)
+		if (l2cap_pi(sk)->conn->hcon->hdev->ssp_mode > 0 &&
+				l2cap_pi(sk)->conn->hcon->ssp_mode > 0)
+			if (!hci_conn_encrypt(l2cap_pi(sk)->conn->hcon))
+				return 1;
+
 	if (d->link_mode & (RFCOMM_LM_ENCRYPT | RFCOMM_LM_SECURE)) {
 		if (!hci_conn_encrypt(l2cap_pi(sk)->conn->hcon))
 			return 1;

@@ -2007,17 +2021,21 @@ static void rfcomm_auth_cfm(struct hci_conn *conn, u8 status)
 	list_for_each_safe(p, n, &s->dlcs) {
 		d = list_entry(p, struct rfcomm_dlc, list);
 
+		if (d->seclevel == BT_SECURITY_HIGH ||
+		    d->seclevel == BT_SECURITY_MEDIUM)
+			continue;
+
 		if ((d->link_mode & (RFCOMM_LM_ENCRYPT | RFCOMM_LM_SECURE)) &&
-				!(conn->link_mode & HCI_LM_ENCRYPT) && !status)
+				(conn->link_mode & HCI_LM_ENCRYPT) && !status)
 			continue;
 
 		if (!test_and_clear_bit(RFCOMM_AUTH_PENDING, &d->flags))
 			continue;
 
-		if (!status)
-			set_bit(RFCOMM_AUTH_ACCEPT, &d->flags);
-		else
+		if (status)
 			set_bit(RFCOMM_AUTH_REJECT, &d->flags);
+		else
+			set_bit(RFCOMM_AUTH_ACCEPT, &d->flags);
 	}
 
 	rfcomm_session_put(s);

@@ -2030,6 +2048,7 @@ static void rfcomm_encrypt_cfm(struct hci_conn *conn, u8 status, u8 encrypt)
 	struct rfcomm_session *s;
 	struct rfcomm_dlc *d;
 	struct list_head *p, *n;
+	int sec;
 
 	BT_DBG("conn %p status 0x%02x encrypt 0x%02x", conn, status, encrypt);

@@ -2041,6 +2060,15 @@ static void rfcomm_encrypt_cfm(struct hci_conn *conn, u8 status, u8 encrypt)
 
 	list_for_each_safe(p, n, &s->dlcs) {
 		d = list_entry(p, struct rfcomm_dlc, list);
+		sec = d->seclevel;
+	
+		if ((sec == BT_SECURITY_HIGH || sec == BT_SECURITY_MEDIUM) &&
+					(d->state == BT_CONNECTED ||
+						d->state == BT_CONFIG) &&
+						!status && encrypt == 0x00) {
+			__rfcomm_dlc_close(d, ECONNREFUSED);
+			continue;
+		}
 
 		if ((d->link_mode & (RFCOMM_LM_ENCRYPT | RFCOMM_LM_SECURE)) &&
 					(d->state == BT_CONNECTED ||

net/bluetooth/rfcomm/sock.c +33 -1

index 0ffe813..cb4f7ba 100644
@@ -268,13 +268,16 @@ static void rfcomm_sock_init(struct sock *sk, struct sock *parent)
 		sk->sk_type = parent->sk_type;
 		pi->link_mode = rfcomm_pi(parent)->link_mode;
 		pi->defer_setup = rfcomm_pi(parent)->defer_setup;
+		pi->seclevel = rfcomm_pi(parent)->seclevel;
 	} else {
 		pi->link_mode = 0;
 		pi->defer_setup = 0;
+		pi->seclevel = BT_SECURITY_LOW;
 	}
 
 	pi->dlc->link_mode = pi->link_mode;
 	pi->dlc->defer_setup = pi->defer_setup;
+	pi->dlc->seclevel = pi->seclevel;
 }
 
 static struct proto rfcomm_proto = {

@@ -415,6 +418,7 @@ static int rfcomm_sock_connect(struct socket *sock, struct sockaddr *addr, int a
 	rfcomm_pi(sk)->channel = sa->rc_channel;
 
 	d->link_mode = rfcomm_pi(sk)->link_mode;
+	d->link_mode = rfcomm_pi(sk)->seclevel;
 
 	err = rfcomm_dlc_open(d, &bt_sk(sk)->src, &sa->rc_bdaddr, sa->rc_channel);
 	if (!err)

@@ -728,7 +732,8 @@ out:
 static int rfcomm_sock_setsockopt(struct socket *sock, int level, int optname, char __user *optval, int optlen)
 {
 	struct sock *sk = sock->sk;
-	int err = 0;
+	struct bt_security sec;
+	int len, err = 0;
 	u32 opt;
 
 	BT_DBG("sk %p", sk);

@@ -737,6 +742,23 @@ static int rfcomm_sock_setsockopt(struct socket *sock, int level, int optname, c
 
 	if (level == SOL_BLUETOOTH) {
 		switch (optname) {
+		case BT_SECURITY:
+			sec.level = BT_SECURITY_LOW;
+
+			len = min_t(unsigned int, sizeof(sec), optlen);
+			if (copy_from_user((char *) &sec, optval, len)) {
+				err = -EFAULT;
+				break;
+			}
+
+			if (sec.level > 3) {
+				err = -EINVAL;
+				break;
+			}
+
+			rfcomm_pi(sk)->seclevel = sec.level;
+			break;
+
 		case BT_DEFER_SETUP:
 			if (get_user(opt, (u32 __user *) optval)) {
 				err = -EFAULT;

@@ -775,6 +797,7 @@ static int rfcomm_sock_setsockopt(struct socket *sock, int level, int optname, c
 static int rfcomm_sock_getsockopt(struct socket *sock, int level, int optname, char __user *optval, int __user *optlen)
 {
 	struct sock *sk = sock->sk;
+	struct bt_security sec;
 	struct sock *l2cap_sk;
 	struct rfcomm_conninfo cinfo;
 	int len, err = 0;

@@ -816,6 +839,15 @@ static int rfcomm_sock_getsockopt(struct socket *sock, int level, int optname, c
 		}
 	} else if (level == SOL_BLUETOOTH) {
 		switch (optname) {
+		case BT_SECURITY:
+			sec.level = rfcomm_pi(sk)->seclevel;
+
+			len = min_t(unsigned int, len, sizeof(sec));
+			if (copy_to_user(optval, (char *) &sec, len))
+				err = -EFAULT;
+
+			break;
+
 		case BT_DEFER_SETUP:
 			if (put_user(rfcomm_pi(sk)->defer_setup, (u32 __user *) optval))
 				err = -EFAULT;

Signature · 1 line

1.6.0.4

Quoted 1 line

From d72c9195905214020408d989eca902330d3c19f0 Mon Sep 17 00:00:00 2001

From: Ville Tervo <[email protected]>
Date: Mon, 29 Dec 2008 13:56:30 +0200
Subject: [PATCH 4/7] bluetooth: l2cap seclevel

This patch introduces preliminary l2cap seclevel support.

---
 net/bluetooth/l2cap.c |  130 +++++++++++++++++++++++++++++++++++++------------
 1 files changed, 98 insertions(+), 32 deletions(-)

net/bluetooth/l2cap.c +98 ~~-32~~

186 lines not on this page · raw message

Signature · 1 line

1.6.0.4

Quoted 1 line

From 8220b7c1cac4fb3dd0e645d557c1828a7eb20345 Mon Sep 17 00:00:00 2001

From: Ville Tervo <[email protected]>
Date: Mon, 5 Jan 2009 16:12:09 +0200
Subject: [PATCH 5/7] Compilation fix

---
 net/bluetooth/l2cap.c |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

net/bluetooth/l2cap.c +3 -3

index 6a643f7..4fc5925 100644
@@ -1146,7 +1146,7 @@ static int l2cap_sock_setsockopt(struct socket *sock, int level, int optname, ch
 
 	lock_sock(sk);
 
-	if (level== SOL_BLUETOOTH) {
+	if (level == SOL_BLUETOOTH) {
 		switch (optname) {
 		case BT_SECURITY:
 			sec.level = BT_SECURITY_LOW;

@@ -1163,12 +1163,12 @@ static int l2cap_sock_setsockopt(struct socket *sock, int level, int optname, ch
 
 			l2cap_pi(sk)->seclevel = sec.level;
 			break;
-		}
 
 		default:
 			err = -ENOPROTOOPT;
 			break;
-	} else if (level = SOL_L2CAP) {
+		}
+	} else if (level == SOL_L2CAP) {
 		switch (optname) {
 		case L2CAP_OPTIONS:
 			opts.imtu     = l2cap_pi(sk)->imtu;

Signature · 1 line

1.6.0.4

Quoted 1 line

From 7d9f27632bc4482b7c30e9b0088c979ebbb0ff4b Mon Sep 17 00:00:00 2001

From: Ville Tervo <[email protected]>
Date: Wed, 7 Jan 2009 16:36:20 +0200
Subject: [PATCH 6/7] [BLUETOOTH] Pause rfcomm TX if encryption is dropped

Role switch is not possible with pre 2.1 devices if encryption is enabled. With this patch TX is halted instead of disconnecting the links if the other end disables encryption.

---
 net/bluetooth/rfcomm/core.c |   32 +++++++++++++++++++++++++-------
 1 files changed, 25 insertions(+), 7 deletions(-)

net/bluetooth/rfcomm/core.c +25 -7

index f0cd6ee..76ab491 100644
@@ -2061,19 +2061,37 @@ static void rfcomm_encrypt_cfm(struct hci_conn *conn, u8 status, u8 encrypt)
 	list_for_each_safe(p, n, &s->dlcs) {
 		d = list_entry(p, struct rfcomm_dlc, list);
 		sec = d->seclevel;
-	
+
+		if ((sec == BT_SECURITY_HIGH || sec == BT_SECURITY_MEDIUM) &&
+					d->state == BT_CONNECTED &&
+					!status && encrypt == 0x00) {
+			clear_bit(RFCOMM_AUTH_ACCEPT, &d->flags);
+			clear_bit(RFCOMM_AUTH_REJECT, &d->flags);
+			set_bit(RFCOMM_AUTH_PENDING, &d->flags);
+			rfcomm_dlc_set_timer(d, RFCOMM_CONN_TIMEOUT);
+			continue;
+		}
+
 		if ((sec == BT_SECURITY_HIGH || sec == BT_SECURITY_MEDIUM) &&
-					(d->state == BT_CONNECTED ||
-						d->state == BT_CONFIG) &&
-						!status && encrypt == 0x00) {
+					d->state == BT_CONFIG &&
+					!status && encrypt == 0x00) {
 			__rfcomm_dlc_close(d, ECONNREFUSED);
 			continue;
 		}
 
 		if ((d->link_mode & (RFCOMM_LM_ENCRYPT | RFCOMM_LM_SECURE)) &&
-					(d->state == BT_CONNECTED ||
-						d->state == BT_CONFIG) &&
-						!status && encrypt == 0x00) {
+					d->state == BT_CONNECTED &&
+					!status && encrypt == 0x00) {
+			clear_bit(RFCOMM_AUTH_ACCEPT, &d->flags);
+			clear_bit(RFCOMM_AUTH_REJECT, &d->flags);
+			set_bit(RFCOMM_AUTH_PENDING, &d->flags);
+			rfcomm_dlc_set_timer(d, RFCOMM_CONN_TIMEOUT);
+			continue;
+		}
+
+		if ((d->link_mode & (RFCOMM_LM_ENCRYPT | RFCOMM_LM_SECURE)) &&
+					d->state == BT_CONFIG &&
+					!status && encrypt == 0x00) {
 			__rfcomm_dlc_close(d, ECONNREFUSED);
 			continue;
 		}

Signature · 1 line

1.6.0.4

Quoted 1 line

From 8e4cca7a6b962b46021921ddef1d101b76bfb96b Mon Sep 17 00:00:00 2001

From: Ville Tervo <[email protected]>
Date: Sat, 10 Jan 2009 13:53:49 +0200
Subject: [PATCH 7/7] [BLUETOOTH] Preliminary l2cap connection rejection support

This is preliminary and untested version of l2cap
connection rejection.

---
 include/net/bluetooth/bluetooth.h |    1 +
 net/bluetooth/af_bluetooth.c      |    3 +-
 net/bluetooth/l2cap.c             |  156 ++++++++++++++++++++++++++++++-------
 3 files changed, 130 insertions(+), 30 deletions(-)

include/net/bluetooth/bluetooth.h +1 -0

index b5af61c..72f7869 100644
@@ -78,6 +78,7 @@ enum {
 	BT_LISTEN,
 	BT_CONNECT,
 	BT_CONNECT2,
+	BT_DEFERRED,
 	BT_CONFIG,
 	BT_DISCONN,
 	BT_CLOSED

net/bluetooth/af_bluetooth.c +2 -1

index f6348e0..7547c03 100644
@@ -223,7 +223,8 @@ struct sock *bt_accept_dequeue(struct sock *parent, struct socket *newsock)
 			continue;
 		}
 
-		if (sk->sk_state == BT_CONNECTED || !newsock) {
+		if (sk->sk_state == BT_DEFERRED || sk->sk_state == BT_CONNECTED
+		    || !newsock) {
 			bt_accept_unlink(sk);
 			if (newsock)
 				sock_graft(sk, newsock);

net/bluetooth/l2cap.c +127 ~~-29~~

214 lines not on this page · raw message

Signature · 1 line

1.6.0.4

Marcel Holtmann

maintainer

2009-01-10 14:18 UTC #1 lore raw

Hi Ville,

Quoted 4 lines

Here is set of unclean patches for discussion. These are still untested and contain issues, but I would like to know if we should continue with these or change something radically. Also commit messages are somewhat misleading in some places.

any reason why patch 0003 is missing?

Regards

Marcel

Johan Hedberg

2009-01-10 14:26 UTC #2 lore raw

Hi,

Quoted 6 lines · ext Marcel Holtmann

Quoted 4 lines
Here is set of unclean patches for discussion. These are still untested and contain issues, but I would like to know if we should continue with these or change something radically. Also commit messages are somewhat misleading in some places.
any reason why patch 0003 is missing?

Just checked with Ville and it was apparently some non-bluetooth related OMAP patch, i.e. it has been left out on purpose.

Johan

Marcel Holtmann

maintainer

2009-01-12 13:53 UTC #3 lore raw

In reply to Ville Tervo

Hi Ville,

Quoted 11 lines

Here is set of unclean patches for discussion. These are still untested and contain issues, but I would like to know if we should continue with these or change something radically. Also commit messages are somewhat misleading in some places.
Basically idea is to implement connection rejection support for l2cap and rfcomm sockets. IOW possibility to check initiator bd-address and ask for authorization before accepting connection.
Other goal is to fix encryption and authentication levels to fulfill 2.1 requirements.

so I pushed my re-worked and pending patches to bluetooth-testing.git now. This adds support for BT_DEFER_SETUP and BT_SECURITY (only the logic and not the actual socket option).

Regards

Marcel

Nick Pelly

2009-01-12 17:15 UTC #4 lore raw

Quoted 11 lines · Marcel Holtmann

Hi Ville,
Quoted 9 lines
Here is set of unclean patches for discussion. These are still untested and contain issues, but I would like to know if we should continue with these or change something radically. Also commit messages are somewhat misleading in some places.
Basically idea is to implement connection rejection support for l2cap and rfcomm sockets. IOW possibility to check initiator bd-address and ask for authorization before accepting connection.

Quoted 6 lines

Quoted 2 lines
Other goal is to fix encryption and authentication levels to fulfill 2.1 requirements.
so I pushed my re-worked and pending patches to bluetooth-testing.git now. This adds support for BT_DEFER_SETUP and BT_SECURITY (only the logic and not the actual socket option).

Ville: thanks for the patches, pausing RFCOMM while encryption is disabled is a nice fix.

I imagine that if encryption is not quickly re-established we need to drop the RFCOMM link rather than leaving it paused though.

We will do some testing of the current rfcomm-pause patches.

Nick

Marcel Holtmann

maintainer

2009-01-13 19:12 UTC #5 lore raw

Hi Nick,

Quoted 16 lines

Quoted 9 lines
Quoted 9 lines
Here is set of unclean patches for discussion. These are still untested and contain issues, but I would like to know if we should continue with these or change something radically. Also commit messages are somewhat misleading in some places.
Basically idea is to implement connection rejection support for l2cap and rfcomm sockets. IOW possibility to check initiator bd-address and ask for authorization before accepting connection.
Quoted 6 lines
Quoted 2 lines
Other goal is to fix encryption and authentication levels to fulfill 2.1 requirements.
so I pushed my re-worked and pending patches to bluetooth-testing.git now. This adds support for BT_DEFER_SETUP and BT_SECURITY (only the logic and not the actual socket option).

Quoted 7 lines

Ville: thanks for the patches, pausing RFCOMM while encryption is disabled is a nice fix.
I imagine that if encryption is not quickly re-established we need to drop the RFCOMM link rather than leaving it paused though.
We will do some testing of the current rfcomm-pause patches.

so I pushed another set of patches to the bluetooth-testing.git tree and it should include the full BT_SECURITY implemention, BT_DEFER_SETUP for RFCOMM and SCO rejection if no listen socket is present.

It currently only drops the connection is encryption is disabled when using BT_SECURITY_HIGH. That is only used for SAP anyway. For all other profiles we use BT_SECURITY_MEDIUM.

Regards

Marcel

jaikumar Ganesh

2009-01-15 19:13 UTC #6 lore raw

Hi Marcel,

Quoted 29 lines · Marcel Holtmann

Hi Nick,
Quoted 1 line
Quoted 1 line
Quoted 1 line
Here is set of unclean patches for discussion. These are still
untested
Quoted 1 line
Quoted 1 line
Quoted 1 line
and contain issues, but I would like to know if we should continue
with
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
these or change something radically. Also commit messages are somewhat misleading in some places.
Basically idea is to implement connection rejection support for l2cap and rfcomm sockets. IOW possibility to check initiator bd-address and ask for authorization before accepting connection.
Other goal is to fix encryption and authentication levels to fulfill
2.1
Quoted 6 lines
Quoted 5 lines
Quoted 1 line
requirements.
so I pushed my re-worked and pending patches to bluetooth-testing.git now. This adds support for BT_DEFER_SETUP and BT_SECURITY (only the logic and not the actual socket option).
Quoted 7 lines
Ville: thanks for the patches, pausing RFCOMM while encryption is disabled is a nice fix.
I imagine that if encryption is not quickly re-established we need to drop the RFCOMM link rather than leaving it paused though.
We will do some testing of the current rfcomm-pause patches.

Quoted 7 lines

so I pushed another set of patches to the bluetooth-testing.git tree and it should include the full BT_SECURITY implemention, BT_DEFER_SETUP for RFCOMM and SCO rejection if no listen socket is present.
It currently only drops the connection is encryption is disabled when using BT_SECURITY_HIGH. That is only used for SAP anyway. For all other profiles we use BT_SECURITY_MEDIUM.

I updated our build with the patches and after picking up 6e26576c
(Pause RFCOMM TX when encryption drops) and fixes upto f32ef1836 (Enforce authentication before encryption) I see a couple of problems::

a) I see that in rfcomm/core.c in function rfcomm_security_cfm: when
the remote side has dropped the encryption for the role change, we set the RFCOMM_SEC_PENDING bit but we don't set RFCOMM_AUTH_PENDING as suggested in Ville's original patch and so when encryption is re-established we dont get past the - test_and_clear_bit (RFCOMM_AUTH_PENDING) check in the function.

b) I also see that we are not clearing the timer and hence after
RFCOMM_AUTH_TIMEOUT period expires we bring down the RFCOMM connection even though the encryption has been established.

Sorry, I don't have a patch ready as yet and hence the description above
to check if you have encountered the same.

Thanks
Jaikumar

Quoted 13 lines

Regards
Marcel
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

jaikumar Ganesh

2009-01-15 19:14 UTC #19 lore raw

In reply to Marcel Holtmann

Hi Marcel
[Sorry sending again as the mail bounced]

Quoted 26 lines · Marcel Holtmann

Hi Nick,
Quoted 16 lines
Quoted 9 lines
Quoted 9 lines
Here is set of unclean patches for discussion. These are still untested and contain issues, but I would like to know if we should continue with these or change something radically. Also commit messages are somewhat misleading in some places.
Basically idea is to implement connection rejection support for l2cap and rfcomm sockets. IOW possibility to check initiator bd-address and ask for authorization before accepting connection.
Quoted 6 lines
Quoted 2 lines
Other goal is to fix encryption and authentication levels to fulfill 2.1 requirements.
so I pushed my re-worked and pending patches to bluetooth-testing.git now. This adds support for BT_DEFER_SETUP and BT_SECURITY (only the logic and not the actual socket option).
Quoted 7 lines
Ville: thanks for the patches, pausing RFCOMM while encryption is disabled is a nice fix.
I imagine that if encryption is not quickly re-established we need to drop the RFCOMM link rather than leaving it paused though.
We will do some testing of the current rfcomm-pause patches.

Quoted 7 lines

so I pushed another set of patches to the bluetooth-testing.git tree and it should include the full BT_SECURITY implemention, BT_DEFER_SETUP for RFCOMM and SCO rejection if no listen socket is present.
It currently only drops the connection is encryption is disabled when using BT_SECURITY_HIGH. That is only used for SAP anyway. For all other profiles we use BT_SECURITY_MEDIUM.

I updated our build with the patches and after picking up 6e26576c (Pause RFCOMM TX when encryption drops) and fixes upto f32ef1836 (Enforce authentication before encryption) I see a couple of problems::

a) I see that in rfcomm/core.c in function rfcomm_security_cfm:
when the remote side has dropped the encryption for the role change, we set the RFCOMM_SEC_PENDING bit but we don't set RFCOMM_AUTH_PENDING as suggested in Ville's original patch and so when encryption is re-established we dont get past the - test_and_clear_bit (RFCOMM_AUTH_PENDING) check in the function.

b) I also see that we are not clearing the timer and hence after
RFCOMM_AUTH_TIMEOUT period expires we bring down the RFCOMM connection even though the encryption has been established.

Sorry, I don't have a patch ready as yet and hence the description
above to check if you have encountered the same.

Thanks
Jaikumar

Quoted 10 lines

Regards
Marcel
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Marcel Holtmann

maintainer

2009-01-15 23:25 UTC #7 lore raw

In reply to jaikumar Ganesh

Hi,

Quoted 17 lines

so I pushed another set of patches to the bluetooth-testing.git tree and
it should include the full BT_SECURITY implemention, BT_DEFER_SETUP for
RFCOMM and SCO rejection if no listen socket is present.
It currently only drops the connection is encryption is disabled when
using BT_SECURITY_HIGH. That is only used for SAP anyway. For all other
profiles we use BT_SECURITY_MEDIUM.
I updated our build with the patches and after picking up 6e26576c
(Pause RFCOMM TX when encryption drops) and fixes upto f32ef1836 (Enforce authentication before encryption) I see a couple of problems::

Quoted 6 lines

a) I see that in rfcomm/core.c in function rfcomm_security_cfm:
when the remote side has dropped the encryption for the role change, we set the RFCOMM_SEC_PENDING bit but we don't set RFCOMM_AUTH_PENDING as suggested in Ville's original patch and so when encryption is re-established we dont get past the - test_and_clear_bit (RFCOMM_AUTH_PENDING) check in the function.

why do you wanna set AUTH_PENDING again. That is not needed we only wanna know once encryption comes back on. If no in time, then we just disconnect the link. That simple.

Quoted 3 lines

b) I also see that we are not clearing the timer and hence after
RFCOMM_AUTH_TIMEOUT period expires we bring down the RFCOMM connection even though the encryption has been established.

Good catch. Fixed it.

Regards

Marcel

jaikumar Ganesh

2009-01-15 23:52 UTC #8 lore raw

Hi Marcel,

Quoted 30 lines · Marcel Holtmann

Hi,
Quoted 17 lines
so I pushed another set of patches to the bluetooth-testing.git tree and
it should include the full BT_SECURITY implemention, BT_DEFER_SETUP for
RFCOMM and SCO rejection if no listen socket is present.
It currently only drops the connection is encryption is disabled when
using BT_SECURITY_HIGH. That is only used for SAP anyway. For all other
profiles we use BT_SECURITY_MEDIUM.
I updated our build with the patches and after picking up 6e26576c
(Pause RFCOMM TX when encryption drops) and fixes upto f32ef1836 (Enforce authentication before encryption) I see a couple of problems::
Quoted 6 lines
a) I see that in rfcomm/core.c in function rfcomm_security_cfm:
when the remote side has dropped the encryption for the role change, we set the RFCOMM_SEC_PENDING bit but we don't set RFCOMM_AUTH_PENDING as suggested in Ville's original patch and so when encryption is re-established we dont get past the - test_and_clear_bit (RFCOMM_AUTH_PENDING) check in the function.
why do you wanna set AUTH_PENDING again. That is not needed we only wanna know once encryption comes back on. If no in time, then we just disconnect the link. That simple.

Quoted 5 lines

Quoted 3 lines
b) I also see that we are not clearing the timer and hence after
RFCOMM_AUTH_TIMEOUT period expires we bring down the RFCOMM connection even though the encryption has been established.
Good catch. Fixed it.

Cool. Can you upload it to bluetooth-testing git ? I saw a related problem while looking at the timer issue and wanted to see if the fix takes care of it.

The timer thats started in rfcomm_security_cfm (for the drop in encryption) does get cleared in rfcomm_process_dlcs
but then we have some data to send. So we send the RFCOMM PN packet just after encryption is re-established.
This results in a new timer being started in rfcomm_process_dlcs and we don't get the UA packet to clear this timer and hence when the timer expires, the connection is dropped.

Thanks
Jaikumar

Quoted 6 lines

Regards
Marcel

Marcel Holtmann

maintainer

2009-01-16 09:47 UTC #9 lore raw

Hi,

Quoted 8 lines

Quoted 8 lines
why do you wanna set AUTH_PENDING again. That is not needed we only wanna know once encryption comes back on. If no in time, then we just disconnect the link. That simple.
Quoted 3 lines
b) I also see that we are not clearing the timer and hence after
RFCOMM_AUTH_TIMEOUT period expires we bring down the RFCOMM connection even though the encryption has been established.

Quoted 5 lines

Quoted 1 line
Good catch. Fixed it.
Cool. Can you upload it to bluetooth-testing git ? I saw a related problem while looking at the timer issue and wanted to see if the fix takes care of it.

I am in the process in doing so, but there are other important things that need to be done first.

Quoted 7 lines

The timer thats started in rfcomm_security_cfm (for the drop in encryption) does get cleared in rfcomm_process_dlcs
but then we have some data to send. So we send the RFCOMM PN packet just after encryption is re-established.
This results in a new timer being started in rfcomm_process_dlcs and we don't get the UA packet to clear this timer and hence when the timer expires, the connection is dropped.

I think you are confusing the work-flow here. The initial stage here is that we get security_cfm when establishing the connection. Then we will either reject or accept the link depending if encryption is enabled or not. In case of dropping encryption during an existing connection we don't need to send PN again. We do have to be in BT_CONNECTED state to have the encryption droping check to kick in. The SEC_PENDING only ensures that we stay encrypted. It has nothing to with the auth step. Also we combine auth+encrypt since one without the other makes no sense at all. So the initial call of security_cfm will always include auth and encrypt enabled.

Regards

Marcel

jaikumar Ganesh

2009-01-20 18:54 UTC #10 lore raw

Hi Marcel,

Quoted 10 lines · Marcel Holtmann

Hi,
Quoted 8 lines
Quoted 8 lines
why do you wanna set AUTH_PENDING again. That is not needed we only wanna know once encryption comes back on. If no in time, then we just disconnect the link. That simple.
Quoted 3 lines
b) I also see that we are not clearing the timer and hence after
RFCOMM_AUTH_TIMEOUT period expires we bring down the RFCOMM connection even though the encryption has been established.

Quoted 8 lines

Quoted 5 lines
Quoted 1 line
Good catch. Fixed it.
Cool. Can you upload it to bluetooth-testing git ? I saw a related problem while looking at the timer issue and wanted to see if the fix takes care of it.
I am in the process in doing so, but there are other important things that need to be done first.

Sorry to push you on this, is this patch been uploaded ?

Quoted 19 lines

Quoted 7 lines
The timer thats started in rfcomm_security_cfm (for the drop in encryption) does get cleared in rfcomm_process_dlcs
but then we have some data to send. So we send the RFCOMM PN packet just after encryption is re-established.
This results in a new timer being started in rfcomm_process_dlcs and we don't get the UA packet to clear this timer and hence when the timer expires, the connection is dropped.
I think you are confusing the work-flow here. The initial stage here is that we get security_cfm when establishing the connection. Then we will either reject or accept the link depending if encryption is enabled or not. In case of dropping encryption during an existing connection we don't need to send PN again. We do have to be in BT_CONNECTED state to have the encryption droping check to kick in. The SEC_PENDING only ensures that we stay encrypted. It has nothing to with the auth step. Also we combine auth+encrypt since one without the other makes no sense at all. So the initial call of security_cfm will always include auth and encrypt enabled.

Quoted 4 lines

Regards
Marcel

Regards
Jaikumar

Marcel Holtmann

maintainer

2009-01-20 20:02 UTC #11 lore raw

Hi,

Quoted 10 lines

Quoted 10 lines
Quoted 10 lines
Quoted 9 lines
why do you wanna set AUTH_PENDING again. That is not needed we only wanna know once encryption comes back on. If no in time, then we just disconnect the link. That simple.
Quoted 3 lines
b) I also see that we are not clearing the timer and hence after
RFCOMM_AUTH_TIMEOUT period expires we bring down the RFCOMM connection even though the encryption has been established.
Good catch. Fixed it.

Quoted 8 lines

Quoted 6 lines
Quoted 3 lines
Cool. Can you upload it to bluetooth-testing git ? I saw a related problem while looking at the timer issue and wanted to see if the fix takes care of it.
I am in the process in doing so, but there are other important things that need to be done first.
Sorry to push you on this, is this patch been uploaded ?

since a few days now. Check the bluetooth-testing.git and it is even rebased against 2.6.29-rc2.

Regards

Marcel

jaikumar Ganesh

2009-01-21 00:28 UTC #12 lore raw

Hi Marcel

Quoted 19 lines · Marcel Holtmann

Hi,
Quoted 17 lines
Quoted 16 lines
Quoted 8 lines
Quoted 8 lines
why do you wanna set AUTH_PENDING again. That is not needed we only wanna know once encryption comes back on. If no in time, then we just disconnect the link. That simple.
Quoted 3 lines
b) I also see that we are not clearing the timer and hence after
RFCOMM_AUTH_TIMEOUT period expires we bring down the RFCOMM connection even though the encryption has been established.
Quoted 5 lines
Quoted 1 line
Good catch. Fixed it.
Cool. Can you upload it to bluetooth-testing git ? I saw a related problem while looking at the timer issue and wanted to see if the fix takes care of it.
I am in the process in doing so, but there are other important things that need to be done first.

Quoted 10 lines

Quoted 1 line
Sorry to push you on this, is this patch been uploaded ?
since a few days now. Check the bluetooth-testing.git and it is even rebased against 2.6.29-rc2.
Regards
Marcel

I applied the patches and I see that we actually don't pause the RFCOMM tx traffic because we don't check on
the RFCOMM_SEC_PENDING flag when sending the tx packets in rfcomm_process_dlcs. I verified this using the "attest" command - we keep sending RFCOMM traffic even though encryption is off.

Please look at the patch attached.

Also should we drop the "rx" packets too when the encryption is dropped ?

Thanks
Jaikumar

From 574f3943808b249fdb89ac47e18ae9bed0d09330 Mon Sep 17 00:00:00 2001
From: Jaikumar Ganesh <[email protected]>
Date: Tue, 20 Jan 2009 16:26:31 -0800
Subject: [PATCH] Bluetooth: When encryption is off, do not send RFCOMM tx packets.

Signed-off-by Jaikumar Ganesh <[email protected]>

---
 net/bluetooth/rfcomm/core.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

net/bluetooth/rfcomm/core.c +3 -0

index ae2ecaa..e8aaf78 100644
@@ -1754,6 +1754,9 @@ static inline void rfcomm_process_dlcs(struct rfcomm_session *s)
 			continue;
 		}
 
+		if (test_bit(RFCOMM_SEC_PENDING, &d->flags))
+			continue;
+
 		if (test_bit(RFCOMM_TX_THROTTLED, &s->flags))
 			continue;

Signature · 1 line

1.5.4.5

Marcel Holtmann

maintainer

2009-01-21 11:19 UTC #13 lore raw

Hi Jaikumar,

Quoted 28 lines

Quoted 14 lines
Quoted 14 lines
Quoted 14 lines
Quoted 13 lines
Quoted 9 lines
why do you wanna set AUTH_PENDING again. That is not needed we only wanna know once encryption comes back on. If no in time, then we just disconnect the link. That simple.
Quoted 3 lines
b) I also see that we are not clearing the timer and hence after
RFCOMM_AUTH_TIMEOUT period expires we bring down the RFCOMM connection even though the encryption has been established.
Good catch. Fixed it.
Cool. Can you upload it to bluetooth-testing git ? I saw a related problem while looking at the timer issue and wanted to see if the fix takes care of it.
Quoted 8 lines
Quoted 4 lines
Quoted 2 lines
I am in the process in doing so, but there are other important things that need to be done first.
Sorry to push you on this, is this patch been uploaded ?
since a few days now. Check the bluetooth-testing.git and it is even rebased against 2.6.29-rc2.
I applied the patches and I see that we actually don't pause the RFCOMM tx traffic because we don't check on
the RFCOMM_SEC_PENDING flag when sending the tx packets in rfcomm_process_dlcs. I verified this using the "attest" command - we keep sending RFCOMM traffic even though encryption is off.

Quoted 3 lines

Please look at the patch attached.
Also should we drop the "rx" packets too when the encryption is dropped ?

can you get me a version with a proper commit message. Just the subject is not gonna be good enough.

Regards

Marcel

jaikumar Ganesh

2009-01-21 17:46 UTC #14 lore raw

Hi Marcel,

Quoted 30 lines · Marcel Holtmann

Hi Jaikumar,
Quoted 28 lines
Quoted 14 lines
Quoted 14 lines
Quoted 14 lines
Quoted 13 lines
Quoted 9 lines
why do you wanna set AUTH_PENDING again. That is not needed we only wanna know once encryption comes back on. If no in time, then we just disconnect the link. That simple.
Quoted 3 lines
b) I also see that we are not clearing the timer and hence after
RFCOMM_AUTH_TIMEOUT period expires we bring down the RFCOMM connection even though the encryption has been established.
Good catch. Fixed it.
Cool. Can you upload it to bluetooth-testing git ? I saw a related problem while looking at the timer issue and wanted to see if the fix takes care of it.
Quoted 8 lines
Quoted 4 lines
Quoted 2 lines
I am in the process in doing so, but there are other important things that need to be done first.
Sorry to push you on this, is this patch been uploaded ?
since a few days now. Check the bluetooth-testing.git and it is even rebased against 2.6.29-rc2.
I applied the patches and I see that we actually don't pause the RFCOMM tx traffic because we don't check on
the RFCOMM_SEC_PENDING flag when sending the tx packets in rfcomm_process_dlcs. I verified this using the "attest" command - we keep sending RFCOMM traffic even though encryption is off.

Quoted 7 lines

Quoted 3 lines
Please look at the patch attached.
Also should we drop the "rx" packets too when the encryption is dropped ?
can you get me a version with a proper commit message. Just the subject is not gonna be good enough.

Sorry, its attached. Also like mentioned above the patch checks only while sending tx packets ?
Should we drop "rx" packets also ?

Quoted 6 lines

Regards
Marcel

From e2ed1c106da9fe764924d662a9bb8b9ddad4914f Mon Sep 17 00:00:00 2001
From: Jaikumar Ganesh <[email protected]>
Date: Wed, 21 Jan 2009 09:42:01 -0800
Subject: [PATCH] Bluetooth: When encyption is dropped, do not send RFCOMM tx packets.

When encryption is dropped RFCOMM_SEC_PENDING flag gets set. Check this flag before sending the tx packets.

Signed-off-by Jaikumar Ganesh <[email protected]>

---
 net/bluetooth/rfcomm/core.c |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

net/bluetooth/rfcomm/core.c +4 -1

index ae2ecaa..73ffc0c 100644
@@ -1,4 +1,4 @@
-/*
+f*
    RFCOMM implementation for Linux Bluetooth stack (BlueZ).
    Copyright (C) 2002 Maxim Krasnyansky <[email protected]>
    Copyright (C) 2002 Marcel Holtmann <[email protected]>

@@ -1754,6 +1754,9 @@ static inline void rfcomm_process_dlcs(struct rfcomm_session *s)
 			continue;
 		}
 
+		if (test_bit(RFCOMM_SEC_PENDING, &d->flags))
+			continue;
+		
 		if (test_bit(RFCOMM_TX_THROTTLED, &s->flags))
 			continue;

Signature · 1 line

1.5.4.5

jaikumar Ganesh

2009-01-28 09:27 UTC #15 lore raw

Hi Marcel,

Quoted 37 lines · jaikumar Ganesh

Hi Marcel,
Quoted 34 lines · Marcel Holtmann
Hi Jaikumar,
Quoted 31 lines
Quoted 14 lines
Quoted 14 lines
Quoted 14 lines
Quoted 13 lines
Quoted 9 lines
why do you wanna set AUTH_PENDING again. That is not needed we only wanna know once encryption comes back on. If no in time, then we just disconnect the link. That simple.
Quoted 3 lines
b) I also see that we are not clearing the timer and hence after
RFCOMM_AUTH_TIMEOUT period expires we bring down the RFCOMM connection even though the encryption has been established.
Good catch. Fixed it.
Cool. Can you upload it to bluetooth-testing git ? I saw a related problem while looking at the timer issue and wanted to see if the fix takes care of it.
Quoted 8 lines
Quoted 4 lines
Quoted 2 lines
I am in the process in doing so, but there are other important things that need to be done first.
Sorry to push you on this, is this patch been uploaded ?
since a few days now. Check the bluetooth-testing.git and it is even rebased against 2.6.29-rc2.
I applied the patches and I see that we actually don't pause the RFCOMM tx traffic because we don't check on
the RFCOMM_SEC_PENDING flag when sending the tx packets in rfcomm_process_dlcs. I verified this using the "attest" command - we keep sending RFCOMM traffic even though encryption is off.
Please look at the patch attached.
Also should we drop the "rx" packets too when the encryption is dropped ?

Quoted 15 lines

Quoted 3 lines
can you get me a version with a proper commit message. Just the subject is not gonna be good enough.
Sorry, its attached. Also like mentioned above the patch checks only while sending tx packets ?
Should we drop "rx" packets also ?
Quoted 6 lines
Regards
Marcel

Hope you got a chance to look at the above patch and comment regarding rx packets.

-Thanks
Jaikumar

Marcel Holtmann

maintainer

2009-01-28 09:59 UTC #16 lore raw

In reply to jaikumar Ganesh

Hi Jaikumar,

Quoted 32 lines

Quoted 32 lines
Quoted 31 lines
Quoted 14 lines
Quoted 14 lines
Quoted 14 lines
Quoted 13 lines
Quoted 9 lines
why do you wanna set AUTH_PENDING again. That is not needed we only wanna know once encryption comes back on. If no in time, then we just disconnect the link. That simple.
Quoted 3 lines
b) I also see that we are not clearing the timer and hence after
RFCOMM_AUTH_TIMEOUT period expires we bring down the RFCOMM connection even though the encryption has been established.
Good catch. Fixed it.
Cool. Can you upload it to bluetooth-testing git ? I saw a related problem while looking at the timer issue and wanted to see if the fix takes care of it.
Quoted 8 lines
Quoted 4 lines
Quoted 2 lines
I am in the process in doing so, but there are other important things that need to be done first.
Sorry to push you on this, is this patch been uploaded ?
since a few days now. Check the bluetooth-testing.git and it is even rebased against 2.6.29-rc2.
I applied the patches and I see that we actually don't pause the RFCOMM tx traffic because we don't check on
the RFCOMM_SEC_PENDING flag when sending the tx packets in rfcomm_process_dlcs. I verified this using the "attest" command - we keep sending RFCOMM traffic even though encryption is off.
Please look at the patch attached.
Also should we drop the "rx" packets too when the encryption is dropped ?

Quoted 7 lines

Quoted 3 lines
can you get me a version with a proper commit message. Just the subject is not gonna be good enough.
Sorry, its attached. Also like mentioned above the patch checks only while sending tx packets ?
Should we drop "rx" packets also ?

patch looks fine to me, but you need to fix/revert the comment change ;)

net/bluetooth/rfcomm/core.c +1 -1

index ae2ecaa..73ffc0c 100644
@@ -1,4 +1,4 @@
-/*
+f*
    RFCOMM implementation for Linux Bluetooth stack (BlueZ).
    Copyright (C) 2002 Maxim Krasnyansky <[email protected]>
    Copyright (C) 2002 Marcel Holtmann <[email protected]>

And I like to have a little bit more detailed commit message please.

Regards

Marcel

jaikumar Ganesh

2009-01-28 10:18 UTC #17 lore raw

Hi Marcel,

Quoted 55 lines · Marcel Holtmann

Hi Jaikumar,
Quoted 32 lines
Quoted 32 lines
Quoted 31 lines
Quoted 14 lines
Quoted 14 lines
Quoted 14 lines
Quoted 13 lines
Quoted 9 lines
why do you wanna set AUTH_PENDING again. That is not needed we only wanna know once encryption comes back on. If no in time, then we just disconnect the link. That simple.
Quoted 3 lines
b) I also see that we are not clearing the timer and hence after
RFCOMM_AUTH_TIMEOUT period expires we bring down the RFCOMM connection even though the encryption has been established.
Good catch. Fixed it.
Cool. Can you upload it to bluetooth-testing git ? I saw a related problem while looking at the timer issue and wanted to see if the fix takes care of it.
Quoted 8 lines
Quoted 4 lines
Quoted 2 lines
I am in the process in doing so, but there are other important things that need to be done first.
Sorry to push you on this, is this patch been uploaded ?
since a few days now. Check the bluetooth-testing.git and it is even rebased against 2.6.29-rc2.
I applied the patches and I see that we actually don't pause the RFCOMM tx traffic because we don't check on
the RFCOMM_SEC_PENDING flag when sending the tx packets in rfcomm_process_dlcs. I verified this using the "attest" command - we keep sending RFCOMM traffic even though encryption is off.
Please look at the patch attached.
Also should we drop the "rx" packets too when the encryption is dropped ?
Quoted 7 lines
Quoted 3 lines
can you get me a version with a proper commit message. Just the subject is not gonna be good enough.
Sorry, its attached. Also like mentioned above the patch checks only while sending tx packets ?
Should we drop "rx" packets also ?
patch looks fine to me, but you need to fix/revert the comment change ;)
net/bluetooth/rfcomm/core.c +1 -1
index ae2ecaa..73ffc0c 100644
@@ -1,4 +1,4 @@
-/*
+f*
   RFCOMM implementation for Linux Bluetooth stack (BlueZ).
   Copyright (C) 2002 Maxim Krasnyansky <[email protected]>
   Copyright (C) 2002 Marcel Holtmann <[email protected]>

Quoted 2 lines

And I like to have a little bit more detailed commit message please.

Sure I will resubmit
Also, should we drop the "rx" packets ?

Thanks
Jaikumar

Quoted 7 lines

Regards
Marcel

Marcel Holtmann

maintainer

2009-01-28 10:35 UTC #18 lore raw

Hi Jaikumar,

Quoted 53 lines

Quoted 53 lines
Quoted 32 lines
Quoted 32 lines
Quoted 31 lines
Quoted 14 lines
Quoted 14 lines
Quoted 14 lines
Quoted 13 lines
Quoted 9 lines
why do you wanna set AUTH_PENDING again. That is not needed we only wanna know once encryption comes back on. If no in time, then we just disconnect the link. That simple.
Quoted 3 lines
b) I also see that we are not clearing the timer and hence after
RFCOMM_AUTH_TIMEOUT period expires we bring down the RFCOMM connection even though the encryption has been established.
Good catch. Fixed it.
Cool. Can you upload it to bluetooth-testing git ? I saw a related problem while looking at the timer issue and wanted to see if the fix takes care of it.
Quoted 8 lines
Quoted 4 lines
Quoted 2 lines
I am in the process in doing so, but there are other important things that need to be done first.
Sorry to push you on this, is this patch been uploaded ?
since a few days now. Check the bluetooth-testing.git and it is even rebased against 2.6.29-rc2.
I applied the patches and I see that we actually don't pause the RFCOMM tx traffic because we don't check on
the RFCOMM_SEC_PENDING flag when sending the tx packets in rfcomm_process_dlcs. I verified this using the "attest" command - we keep sending RFCOMM traffic even though encryption is off.
Please look at the patch attached.
Also should we drop the "rx" packets too when the encryption is dropped ?
Quoted 7 lines
Quoted 3 lines
can you get me a version with a proper commit message. Just the subject is not gonna be good enough.
Sorry, its attached. Also like mentioned above the patch checks only while sending tx packets ?
Should we drop "rx" packets also ?
patch looks fine to me, but you need to fix/revert the comment change ;)
net/bluetooth/rfcomm/core.c +1 -1
index ae2ecaa..73ffc0c 100644
@@ -1,4 +1,4 @@
-/*
+f*
   RFCOMM implementation for Linux Bluetooth stack (BlueZ).
   Copyright (C) 2002 Maxim Krasnyansky <[email protected]>
   Copyright (C) 2002 Marcel Holtmann <[email protected]>

Quoted 4 lines

Quoted 2 lines
And I like to have a little bit more detailed commit message please.
Sure I will resubmit
Also, should we drop the "rx" packets ?

no, we can't do that since RFCOMM support to be a reliable stream.

Regards

Marcel