Sniff mode issues regarding Sony Ericsson headsets: kernel patch proposal.

Hi Marcel,

Due to job requirement, I recently fined tuned a kernel to work well with some Sony Erisson A2DP Headsets (namely Motorola HBH-DS970 and HBH-DS980): this means making sure to force the other side to exit sniff mode early on before the AVDTP signalling comes into play.

If i remember well we had a talk a while ago about the way the sniff mode was handled by the kernel due to various issues with some bluetooth keyboards. The conclusion we had at that time, the best way to handle this issue was to add a socket option on an L2CAP channel to force the other side to exit sniff mode even if it was the one who initially entered the sniff mode.

I used this approach and wrote & tested a patch against 2.6.26-mh3. Patch is attached and seems to solve the issue.

*but*

During validation testing we found yet another issue that seems to be related to the way we handle the sniff mode.
The syndrom is that if the user screws up at enterring the pin code during pairing bluez fails to close the acl connection properly,
which means subsequent attempts result in a "connection already exist" error. From the user point of view it is impossible to try to pair again to the same headset...which is quite annoying. Below is an hci trace of the issue:
< ACL data: handle 1 flags 0x02 dlen 12
L2CAP(s): Connect req: psm 25 scid 0x0040

handle 1 packets 1

L2CAP(s): Connect rsp: dcid 0x0051 scid 0x0040 result 1 status 1
Connection pending - Authentication pending

bdaddr 00:1C:A4:2C:FA:4A
< HCI Command: PIN Code Request Reply (0x01|0x000d) plen 23
bdaddr 00:1C:A4:2C:FA:4A len 4 pin '1111'

PIN Code Request Reply (0x01|0x000d) ncmd 2
status 0x00 bdaddr 00:1C:A4:2C:FA:4A

L2CAP(s): Connect rsp: dcid 0x0051 scid 0x0040 result 3 status 0
Connection refused - security block

status 0x00 handle 1 mode 0x02 interval 2048
Mode: Sniff
< HCI Command: Disconnect (0x01|0x0006) plen 3
handle 1 reason 0x13
Reason: Remote User Terminated Connection

Disconnect (0x01|0x0006) status 0x00 ncmd 1

status 0x0c handle 1 reason 0x1f
Error: Command Disallowed

Unknown (0x00|0x0000) status 0x00 ncmd 2

I hacked the kernel to try to see if forcing the headset to exit sniff mode before sending disconnect would solve the issue.... well it did :-) Trace below shows this working:
< ACL data: handle 1 flags 0x02 dlen 12
L2CAP(s): Connect req: psm 25 scid 0x0040

status 0x00 handle 1
Features: 0xff 0x2e 0x2d 0xfa 0x98 0x39 0x00 0x80

Unknown (0x00|0x0000) status 0x00 ncmd 1

Write Link Policy Settings (0x02|0x000d) ncmd 2 status 0x00 handle 1

handle 1 packets 1

L2CAP(s): Connect rsp: dcid 0x0053 scid 0x0040 result 1 status 1
Connection pending - Authentication pending

bdaddr 00:1C:A4:2C:FA:4A
< HCI Command: PIN Code Request Reply (0x01|0x000d) plen 23
bdaddr 00:1C:A4:2C:FA:4A len 4 pin '1111'

PIN Code Request Reply (0x01|0x000d) ncmd 2
status 0x00 bdaddr 00:1C:A4:2C:FA:4A

L2CAP(s): Connect rsp: dcid 0x0053 scid 0x0040 result 3 status 0
Connection refused - security block

status 0x00 handle 1 mode 0x02 interval 2048
Mode: Sniff
< HCI Command: Exit Sniff Mode (0x02|0x0004) plen 2
handle 1

Exit Sniff Mode (0x02|0x0004) status 0x00 ncmd 1
< HCI Command: Disconnect (0x01|0x0006) plen 3
handle 1 reason 0x13
Reason: Remote User Terminated Connection

Disconnect (0x01|0x0006) status 0x00 ncmd 0

status 0x00 handle 1 mode 0x00 interval 0
Mode: Active

Unknown (0x00|0x0000) status 0x00 ncmd 1

status 0x00 handle 1 reason 0x16
Reason: Connection Terminated by Local Host

Unknown (0x00|0x0000) status 0x00 ncmd 2

Conclusion: to have those bloody Sony Erisson headsets working we have to change two things in the kernel:
1) Provide a way for a L2CAP socket user to alter sniff mode exit
behaviour
2) Make sure we exit sniff mode before to disconnect

Question 1: Are you interested in reviewing then merging my patches if i try to fix thoses issues ?
Question 2: I have the gut feeling that we should change default behaviour to the behaviour required by those headsets, and provide a socket option for the bluetooth HID, rather than the other way round. What do you think ?

If we can come on an agreement on the proper way to fix this issue then i should come with a patch in a 3-4 days timeframe.

Regards,

Fabien

diff -ru -x '*.so' -x '*.lds' -x '*.a' -x '*.elf' -x '.*' -x '*.order' -x '*.ko' -x '*.mod.c' -x '*.o' -x '*.cmd' linux-2.6.26/include/net/bluetooth/hci_core.h linux-2.6.26+mh3+fch/include/net/bluetooth/hci_core.h
@@ -170,6 +170,7 @@
 	__u32		 link_mode;
 	__u8             auth_type;
 	__u8             power_save;
+	__u8             force_active_mode;
 	unsigned long	 pend;
 
 	unsigned int	 sent;

diff -ru -x '*.so' -x '*.lds' -x '*.a' -x '*.elf' -x '.*' -x '*.order' -x '*.ko' -x '*.mod.c' -x '*.o' -x '*.cmd' linux-2.6.26/include/net/bluetooth/l2cap.h linux-2.6.26+mh3+fch/include/net/bluetooth/l2cap.h
@@ -62,6 +62,8 @@
 #define L2CAP_LM_RELIABLE	0x0010
 #define L2CAP_LM_SECURE		0x0020
 
+#define L2CAP_FORCE_ACTIVE_MODE	0x04
+
 /* L2CAP command codes */
 #define L2CAP_COMMAND_REJ 0x01
 #define L2CAP_CONN_REQ    0x02

Seulement dans linux-2.6.26+mh3+fch/kernel: bounds.s Seulement dans linux-2.6.26+mh3+fch/kernel: timeconst.h Seulement dans linux-2.6.26+mh3+fch/lib: crc32table.h Seulement dans linux-2.6.26+mh3+fch/lib: gen_crc32table Seulement dans linux-2.6.26+mh3+fch/: Module.symvers

diff -ru -x '*.so' -x '*.lds' -x '*.a' -x '*.elf' -x '.*' -x '*.order' -x '*.ko' -x '*.mod.c' -x '*.o' -x '*.cmd' linux-2.6.26/net/bluetooth/hci_conn.c linux-2.6.26+mh3+fch/net/bluetooth/hci_conn.c
@@ -214,6 +214,7 @@
 	conn->state = BT_OPEN;
 
 	conn->power_save = 1;
+	conn->force_active_mode = 0;
 
 	switch (type) {
 	case ACL_LINK:

@@ -464,7 +465,10 @@
 	if (test_bit(HCI_RAW, &hdev->flags))
 		return;
 
-	if (conn->mode != HCI_CM_SNIFF || !conn->power_save)
+	if (conn->mode != HCI_CM_SNIFF)
+		goto timer;
+
+	if (!conn->power_save && !conn->force_active_mode)
 		goto timer;
 
 	if (!test_and_set_bit(HCI_CONN_MODE_CHANGE_PEND, &conn->pend)) {

diff -ru -x '*.so' -x '*.lds' -x '*.a' -x '*.elf' -x '.*' -x '*.order' -x '*.ko' -x '*.mod.c' -x '*.o' -x '*.cmd' linux-2.6.26/net/bluetooth/l2cap.c linux-2.6.26+mh3+fch/net/bluetooth/l2cap.c
@@ -1133,6 +1133,20 @@
 		l2cap_pi(sk)->link_mode = opt;
 		break;
 
+	case L2CAP_FORCE_ACTIVE_MODE:
+		if (sk->sk_state != BT_CONNECTED) {
+			err = -ENOTCONN;
+			break;
+		}
+
+		if (get_user(opt, (u32 __user *) optval)) {
+			err = -EFAULT;
+			break;
+		}
+
+		l2cap_pi(sk)->conn->hcon->force_active_mode = opt;
+		break;
+
 	default:
 		err = -ENOPROTOOPT;
 		break;

@@ -1189,6 +1203,17 @@
 
 		break;
 
+	case L2CAP_FORCE_ACTIVE_MODE:
+		if (sk->sk_state != BT_CONNECTED) {
+			err = -ENOTCONN;
+			break;
+		}
+
+		if (put_user(l2cap_pi(sk)->conn->hcon->force_active_mode,
+				 (u32 __user *) optval))
+			err = -EFAULT;
+		break;
+
 	default:
 		err = -ENOPROTOOPT;
 		break;

Hi Fabien,

retest with 2.6.27-rc5 since that has full Simple Pairing support and is the kernel version that counts.

Also this is not BlueZ screwing anything up. Where is written that we have to get out of sniff mode before we can disconnect a link. What kind of hardware are you using? Does BlueZ always have to cleanup after broken hardware and f*cked up stacks?

Make it two separate patches. We can send the exit sniff mode command that is not a problem. I still don't like it, because it is the job of the Link Manager to do this.

For the sniff mode setting you have to use SOL_BLUETOOTH since I will remove all the other SOL_* and consolidate them.

Regards

Marcel

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Hi Marcel,

I'm gonna rebase on this one then.

Lol :-)
I never said that Bluez was screwing up anything.
But as usual, there are compromises to make between sticking close to the standard and having good interoperability, which usually involves some level of workaround :-)

Will do.

You didn't answer to question 2: what's your choice ? (btw to question 1 neither, but i guess that means a 'yes' :-)

hmmm... not sure i really see what you mean. :-(

Fabien

Hi Marcel,

The issue with sniff mode & disconnect has vanished with 2.6.27-rc5 :-)

It just remains one issue to be fixed then...

Fabien

Hi Fabien,

are you sure? I am not recalling that I fixed anything in this area. The ACL link setup has changed to do proper features retrieval before allowing L2CAP do get into it. However it cools down the phase for the first L2CAP package.

Btw. report this bug to your hardware manufacturer, because they are not working according to the HCI specification. It is a bug if disconnect fails when they are in sniff mode.

Regards

Marcel

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Hi Marcel

See previous e-mail, i screwed up, issue seems to come from ST chip. :-(

Yep, i would definately report this... however don't have any support anymore from ST :-(

Fabien

Hi Fabien,

I am seriously sick of this f*cked up hardware. What is it? My guess would be a TI chip.

I would first have to know which host controller it is, before I actually think about adding something like this.

Don't use SOL_L2CAP or SOL_RFCOMM anymore. They will be all SOL_BLUETOOTH since there are no different between the socket options itself.

Regards

Marcel

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Hi Marcel

...and you won !!

I dug deeper in this second problem.
In fact it has not been solved by the 2.6.17-rc5 kernel.

I misinterpreted the result as i inadvertedly changed bluetooth dongle at the same time. So issue with wrong pin code only arise whith Sony Erisson(TI) + ST + bluez. Sony Erisson(TI) + BCM + bluez works.

As you said issue is clearly seems to come from the hardware (LMP).

Yeah sure but from the kernel point of view there is a a level parameter passed to setsockopt/getsockopt which is already ignored... or maybe you were just speeking about user space ?

Regards,

Fabien

Hi Marcel,

Here are patches against 2.6.27-rc6 and latest bluez git that add support for point 1 below.

Please tell me how you feel about them...

Cheers,

Fabien

From: Fabien Chevalier <[email protected]>
Date: Sat, 13 Sep 2008 19:30:04 +0200
Subject: [PATCH] Add L2CAP_FORCE_ACTIVE_MODE constant

---
 include/l2cap.h |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

index 0c22d48..78ddcb4 100644
@@ -66,6 +66,8 @@ struct l2cap_conninfo {
 #define L2CAP_LM_RELIABLE	0x0010
 #define L2CAP_LM_SECURE		0x0020
 
+#define L2CAP_FORCE_ACTIVE_MODE 0x04
+
 /* L2CAP command codes */
 #define L2CAP_COMMAND_REJ	0x01
 #define L2CAP_CONN_REQ		0x02

1.5.6.5

From: Fabien Chevalier <[email protected]>
Date: Sat, 13 Sep 2008 19:30:26 +0200
Subject: [PATCH] Set L2CAP_FORCE_ACTIVE_MODE on for incoming and outgoing AVDTP/AVRCP channels

---
 audio/avdtp.c |   22 ++++++++++++++++++++++
 1 files changed, 22 insertions(+), 0 deletions(-)

index 4ba94ad..4af19df 100644
@@ -1532,6 +1532,7 @@ static void l2cap_connect_cb(GIOChannel *chan, int err, const bdaddr_t *src,
 	socklen_t len;
 	int sk;
 	char address[18];
+	uint32_t force_active_mode;
 
 	if (!g_slist_find(sessions, session)) {
 		debug("l2cap_connect_cb: session got removed");

@@ -1565,6 +1566,16 @@ static void l2cap_connect_cb(GIOChannel *chan, int err, const bdaddr_t *src,
 		goto failed;
 	}
 
+	force_active_mode = 1;
+	if (setsockopt(sk, SOL_BLUETOOTH, L2CAP_FORCE_ACTIVE_MODE, &force_active_mode,
+				sizeof(force_active_mode)) < 0) {
+		err = -errno;
+		info("setsockopt L2CAP_FORCE_ACTIVE_MODE failed, some headsets may "
+		"take longer than needed to reconnect");
+		/* Continue even in case of failure, as this option is not 
+		 * mandatory to support */
+	}
+	
 	if (session->state == AVDTP_SESSION_STATE_CONNECTING) {
 		struct audio_device *dev;
 

@@ -2748,6 +2759,7 @@ static void avdtp_server_cb(GIOChannel *chan, int err, const bdaddr_t *src,
 	struct l2cap_options l2o;
 	struct avdtp *session;
 	char address[18];
+	uint32_t force_active_mode;
 
 	if (err < 0) {
 		error("accept: %s (%d)", strerror(-err), -err);

@@ -2779,6 +2791,16 @@ static void avdtp_server_cb(GIOChannel *chan, int err, const bdaddr_t *src,
 		goto drop;
 	}
 
+	force_active_mode = 1;
+	if (setsockopt(sk, SOL_BLUETOOTH, L2CAP_FORCE_ACTIVE_MODE, &force_active_mode,
+				sizeof(force_active_mode)) < 0) {
+		err = -errno;
+		info("setsockopt L2CAP_FORCE_ACTIVE_MODE failed, some headsets may "
+		"take longer than needed to reconnect");
+		/* Continue even in case of failure, as this option is not 
+		 * mandatory to support */
+	}
+
 	session->mtu = l2o.imtu;
 	session->sock = sk;
 

1.5.6.5

From: Fabien Chevalier <[email protected]>
Date: Sat, 13 Sep 2008 16:11:33 +0200
Subject: [PATCH] Port sniff mode fixes from 2.6.27-rc5

---
 include/net/bluetooth/hci_core.h |    1 +
 include/net/bluetooth/l2cap.h    |    2 ++
 net/bluetooth/hci_conn.c         |    6 +++++-
 net/bluetooth/l2cap.c            |   25 +++++++++++++++++++++++++
 4 files changed, 33 insertions(+), 1 deletions(-)

index 46a43b7..352c4ce 100644
@@ -170,6 +170,7 @@ struct hci_conn {
 	__u32		 link_mode;
 	__u8             auth_type;
 	__u8             power_save;
+	__u8             force_active_mode;
 	unsigned long	 pend;
 
 	unsigned int	 sent;

index 73e115b..917fa6b 100644
@@ -62,6 +62,8 @@ struct l2cap_conninfo {
 #define L2CAP_LM_RELIABLE	0x0010
 #define L2CAP_LM_SECURE		0x0020
 
+#define L2CAP_FORCE_ACTIVE_MODE	0x04
+
 /* L2CAP command codes */
 #define L2CAP_COMMAND_REJ 0x01
 #define L2CAP_CONN_REQ    0x02

index b700242..7df1f4a 100644
@@ -214,6 +214,7 @@ struct hci_conn *hci_conn_add(struct hci_dev *hdev, int type, bdaddr_t *dst)
 	conn->state = BT_OPEN;
 
 	conn->power_save = 1;
+	conn->force_active_mode = 0;
 
 	switch (type) {
 	case ACL_LINK:

@@ -479,7 +480,10 @@ void hci_conn_enter_active_mode(struct hci_conn *conn)
 	if (test_bit(HCI_RAW, &hdev->flags))
 		return;
 
-	if (conn->mode != HCI_CM_SNIFF || !conn->power_save)
+	if (conn->mode != HCI_CM_SNIFF)
+		goto timer;
+
+	if (!conn->power_save && !conn->force_active_mode)
 		goto timer;
 
 	if (!test_and_set_bit(HCI_CONN_MODE_CHANGE_PEND, &conn->pend)) {

index 9610a9c..9925bdc 100644
@@ -1148,6 +1148,20 @@ static int l2cap_sock_setsockopt(struct socket *sock, int level, int optname, ch
 		l2cap_pi(sk)->link_mode = opt;
 		break;
 
+	case L2CAP_FORCE_ACTIVE_MODE:
+		if (sk->sk_state != BT_CONNECTED) {
+			err = -ENOTCONN;
+			break;
+		}
+
+		if (get_user(opt, (u32 __user *) optval)) {
+			err = -EFAULT;
+			break;
+		}
+
+		l2cap_pi(sk)->conn->hcon->force_active_mode = opt;
+		break;
+
 	default:
 		err = -ENOPROTOOPT;
 		break;

@@ -1204,6 +1218,17 @@ static int l2cap_sock_getsockopt(struct socket *sock, int level, int optname, ch
 
 		break;
 
+	case L2CAP_FORCE_ACTIVE_MODE:
+		if (sk->sk_state != BT_CONNECTED) {
+			err = -ENOTCONN;
+			break;
+		}
+
+		if (put_user(l2cap_pi(sk)->conn->hcon->force_active_mode,
+				 (u32 __user *) optval))
+			err = -EFAULT;
+		break;
+
 	default:
 		err = -ENOPROTOOPT;
 		break;

1.5.6.5

Hi Fabien,

problem with these patches is that they are a layer violation between L2CAP and HCI. It should also work on incoming and outgoing connections the same way. Also when using socket options, I prefer that we set them and store the value and the execute it once the connections is up.

Personally I prefer if we would enhance hci_send_acl() to indicate that we expect it got get out of any power state before processing this data packet.

And of course this socket option also has to work for RFCOMM.

Regards

Marcel

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Yes that is true but that is nothing that isn't already existing. Same trick is used for L2CAP_CONNINFO.

I'm gonna try to improve that.

I'm not following you there...

Agreed. I was just too lazy to do that :-)

That's pretty much useless as i don't know if that will ever get used. However that's not much work, i can do it if that makes you happy. ;-)

Do you have any comments on the user-land side or is it how you see things ?

Cheers,

Fabien

Hi Fabien,

no they don't. Look at the code. It is nicely abstracted on how we handle the two layers.

We wanna be able to set this on a server socket and also enforce it on a connection we created.

Lazy doesn't get it upstream :)

I treat RFCOMM and L2CAP the same. If we implement something for one protocol, we do have to do the same for the other.

Actually I do have to figure out the exact naming, but it is basically set this option once approach. And the kernel will do the rest.

Regards

Marcel

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Hi Marcel,

Having a closer look to the code, it looks that only write access to HCI layer variables is forbidden. There are numerous places in the code where L2CAP for instance goes and peeks some HCI values. I think i skipped that distinction in my first understanding of the code.

Anyway, i'm gonna stop chatting and starting to fix that too :-).

lol :-)

That sounds reasonable...

Agreed.

So i'm gonna start coding now to see of things are going...

Cheers,

Fabien

No wonder I couldn't get my HBH-DS980 to work!

This kind of information belongs on the wiki.
I've created http://wiki.bluez.org/wiki/HardwareCompatibility
and http://wiki.bluez.org/wiki/MotorolaHBHDS9x0 as a start, but I don't really understand the issue, so it would be good if someone who understands it better could flesh out the wiki article.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Hi Brian,

This headset is supposed to work, the issue is that sometimes it can be very slow to connect...

Cheers,

Fabien

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel