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

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

[Fabien Chevalier]

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


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
 > HCI Event: Number of Completed Packets (0x13) plen 5
    handle 1 packets 1
 > ACL data: handle 1 flags 0x02 dlen 16
    L2CAP(s): Connect rsp: dcid 0x0051 scid 0x0040 result 1 status 1
      Connection pending - Authentication pending
 > HCI Event: PIN Code Request (0x16) plen 6
    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'
 > HCI Event: Command Complete (0x0e) plen 10
    PIN Code Request Reply (0x01|0x000d) ncmd 2
    status 0x00 bdaddr 00:1C:A4:2C:FA:4A
 > ACL data: handle 1 flags 0x02 dlen 16
    L2CAP(s): Connect rsp: dcid 0x0051 scid 0x0040 result 3 status 0
      Connection refused - security block
 > HCI Event: Mode Change (0x14) plen 6
    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
 > HCI Event: Command Status (0x0f) plen 4
    Disconnect (0x01|0x0006) status 0x00 ncmd 1
 > HCI Event: Disconn Complete (0x05) plen 4
    status 0x0c handle 1 reason 0x1f
    Error: Command Disallowed
 > HCI Event: Command Status (0x0f) plen 4
    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
 > HCI Event: Read Remote Supported Features (0x0b) plen 11
    status 0x00 handle 1
    Features: 0xff 0x2e 0x2d 0xfa 0x98 0x39 0x00 0x80
 > HCI Event: Command Status (0x0f) plen 4
    Unknown (0x00|0x0000) status 0x00 ncmd 1
 > HCI Event: Command Complete (0x0e) plen 6
    Write Link Policy Settings (0x02|0x000d) ncmd 2
    status 0x00 handle 1
 > HCI Event: Number of Completed Packets (0x13) plen 5
    handle 1 packets 1
 > ACL data: handle 1 flags 0x02 dlen 16
    L2CAP(s): Connect rsp: dcid 0x0053 scid 0x0040 result 1 status 1
      Connection pending - Authentication pending
 > HCI Event: PIN Code Request (0x16) plen 6
    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'
 > HCI Event: Command Complete (0x0e) plen 10
    PIN Code Request Reply (0x01|0x000d) ncmd 2
    status 0x00 bdaddr 00:1C:A4:2C:FA:4A
 > ACL data: handle 1 flags 0x02 dlen 16
    L2CAP(s): Connect rsp: dcid 0x0053 scid 0x0040 result 3 status 0
      Connection refused - security block
 > HCI Event: Mode Change (0x14) plen 6
    status 0x00 handle 1 mode 0x02 interval 2048
    Mode: Sniff
< HCI Command: Exit Sniff Mode (0x02|0x0004) plen 2
    handle 1
 > HCI Event: Command Status (0x0f) plen 4
    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
 > HCI Event: Command Status (0x0f) plen 4
    Disconnect (0x01|0x0006) status 0x00 ncmd 0
 > HCI Event: Mode Change (0x14) plen 6
    status 0x00 handle 1 mode 0x00 interval 0
    Mode: Active
 > HCI Event: Command Status (0x0f) plen 4
    Unknown (0x00|0x0000) status 0x00 ncmd 1
 > HCI Event: Disconn Complete (0x05) plen 4
    status 0x00 handle 1 reason 0x16
    Reason: Connection Terminated by Local Host
 > HCI Event: Command Status (0x0f) plen 4
    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




[-- Attachment #2: a2dp-sniff-mode-issue.diff --]
[-- Type: text/plain, Size: 3306 bytes --]

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
--- linux-2.6.26/include/net/bluetooth/hci_core.h	2008-09-01 17:06:22.000000000 +0200
+++ linux-2.6.26+mh3+fch/include/net/bluetooth/hci_core.h	2008-09-01 12:22:36.000000000 +0200
@@ -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
--- linux-2.6.26/include/net/bluetooth/l2cap.h	2008-07-13 23:51:29.000000000 +0200
+++ linux-2.6.26+mh3+fch/include/net/bluetooth/l2cap.h	2008-09-01 16:20:17.000000000 +0200
@@ -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
--- linux-2.6.26/net/bluetooth/hci_conn.c	2008-09-01 17:06:22.000000000 +0200
+++ linux-2.6.26+mh3+fch/net/bluetooth/hci_conn.c	2008-09-01 16:16:33.000000000 +0200
@@ -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
--- linux-2.6.26/net/bluetooth/l2cap.c	2008-09-01 17:06:22.000000000 +0200
+++ linux-2.6.26+mh3+fch/net/bluetooth/l2cap.c	2008-09-01 17:18:23.000000000 +0200
@@ -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;

Re: [Bluez-devel] Sniff mode issues regarding Sony Ericsson headsets: kernel patch proposal.

[Marcel Holtmann]

Hi Fabien,

> 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.

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?

> 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.

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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Sniff mode issues regarding Sony Ericsson headsets: kernel patch proposal.

[Fabien Chevalier]

Hi Marcel,

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

I'm gonna rebase on this one then.

> 
> 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?

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 :-)

> 
>> 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.
> 
> 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.

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' :-)

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

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

Fabien

Re: [Bluez-devel] Sniff mode issues regarding Sony Ericsson headsets: kernel patch proposal.

[Fabien Chevalier]

Hi Marcel,

> Hi Marcel,
> 
>> retest with 2.6.27-rc5 since that has full Simple Pairing support and is
>> the kernel version that counts.
> 
> I'm gonna rebase on this one then.

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

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

Fabien

Re: [Bluez-devel] Sniff mode issues regarding Sony Ericsson headsets: kernel patch proposal.

[Marcel Holtmann]

Hi Fabien,

> > 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?
> 
> 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 :-)

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

> > 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.
> 
> 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' :-)

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

> > For the sniff mode setting you have to use SOL_BLUETOOTH since I will
> > remove all the other SOL_* and consolidate them.
> 
> hmmm... not sure i really see what you mean. :-(

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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Sniff mode issues regarding Sony Ericsson headsets: kernel patch proposal.

[Marcel Holtmann]

Hi Fabien,

> >> retest with 2.6.27-rc5 since that has full Simple Pairing support and is
> >> the kernel version that counts.
> > 
> > I'm gonna rebase on this one then.
> 
> The issue with sniff mode & disconnect has vanished with 2.6.27-rc5 :-)

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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Sniff mode issues regarding Sony Ericsson headsets: kernel patch proposal.

[Fabien Chevalier]

Hi Marcel

>> 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 :-)
> 
> I am seriously sick of this f*cked up hardware. What is it? My guess
> would be a TI chip.

...and you won !!

> 
>>> 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.
>> 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' :-)
> 
> I would first have to know which host controller it is, before I
> actually think about adding something like this.


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).



> 
>>> For the sniff mode setting you have to use SOL_BLUETOOTH since I will
>>> remove all the other SOL_* and consolidate them.
>> hmmm... not sure i really see what you mean. :-(
> 
> 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.

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

Re: [Bluez-devel] Sniff mode issues regarding Sony Ericsson headsets: kernel patch proposal.

[Fabien Chevalier]

Hi Marcel
> 
>>>> retest with 2.6.27-rc5 since that has full Simple Pairing support and is
>>>> the kernel version that counts.
>>> I'm gonna rebase on this one then.
>> The issue with sniff mode & disconnect has vanished with 2.6.27-rc5 :-)
> 
> 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.

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

> 
> 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.
> 

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

Fabien

Re: [Bluez-devel] Sniff mode issues regarding Sony Ericsson headsets: kernel patch proposal.

[Brian Sammon]

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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Sniff mode issues regarding Sony Ericsson headsets: kernel patch proposal.

[Fabien Chevalier]

Hi Brian,

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

Cheers,

Fabien



Brian Sammon wrote:
> 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
> Bluez-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
> 
> 


-------------------------------------------------------------------------
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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Sniff mode issues regarding Sony Ericsson headsets: kernel patch proposal.

[Fabien Chevalier]

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

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

> 
> 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?
> 
>> 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.
> 
> 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
> Bluez-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
> 
> 


[-- Attachment #2: 0001-Add-L2CAP_FORCE_ACTIVE_MODE-constant.patch --]
[-- Type: text/x-patch, Size: 667 bytes --]

>From 7fdff17d92d6723de518e5c1bc39bd8fab981757 Mon Sep 17 00:00:00 2001
From: Fabien Chevalier <fabchevalier@free.fr>
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(-)

diff --git a/include/l2cap.h b/include/l2cap.h
index 0c22d48..78ddcb4 100644
--- a/include/l2cap.h
+++ b/include/l2cap.h
@@ -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


[-- Attachment #3: 0002-Set-L2CAP_FORCE_ACTIVE_MODE-on-for-incoming-and-outg.patch --]
[-- Type: text/x-patch, Size: 2157 bytes --]

>From 3146919310fdb65da55c62c353a96b9593b714de Mon Sep 17 00:00:00 2001
From: Fabien Chevalier <fabchevalier@free.fr>
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(-)

diff --git a/audio/avdtp.c b/audio/avdtp.c
index 4ba94ad..4af19df 100644
--- a/audio/avdtp.c
+++ b/audio/avdtp.c
@@ -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


[-- Attachment #4: 0001-Port-sniff-mode-fixes-from-2.6.27-rc5.patch --]
[-- Type: text/x-patch, Size: 3033 bytes --]

>From 623078406e581c1ca79baf430ddf83219f6aa9ca Mon Sep 17 00:00:00 2001
From: Fabien Chevalier <fabchevalier@free.fr>
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(-)

diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
index 46a43b7..352c4ce 100644
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -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;
diff --git a/include/net/bluetooth/l2cap.h b/include/net/bluetooth/l2cap.h
index 73e115b..917fa6b 100644
--- a/include/net/bluetooth/l2cap.h
+++ b/include/net/bluetooth/l2cap.h
@@ -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
diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
index b700242..7df1f4a 100644
--- a/net/bluetooth/hci_conn.c
+++ b/net/bluetooth/hci_conn.c
@@ -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)) {
diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
index 9610a9c..9925bdc 100644
--- a/net/bluetooth/l2cap.c
+++ b/net/bluetooth/l2cap.c
@@ -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

Re: [Bluez-devel] Sniff mode issues regarding Sony Ericsson headsets: kernel patch proposal.

[Marcel Holtmann]

Hi Fabien,

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

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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Sniff mode issues regarding Sony Ericsson headsets: kernel patch proposal.

[Fabien Chevalier]

Marcel Holtmann wrote:
> Hi Fabien,
> 
>> Here are patches against 2.6.27-rc6 and latest bluez git that add 
>> support for point 1 below.
> 
> problem with these patches is that they are a layer violation between
> L2CAP and HCI. 

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.

> It should also work on incoming and outgoing connections
> the same way. 

I'm not following you there...

> Also when using socket options, I prefer that we set them
> and store the value and the execute it once the connections is up.

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

> 
> 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.

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

Re: [Bluez-devel] Sniff mode issues regarding Sony Ericsson headsets: kernel patch proposal.

[Marcel Holtmann]

Hi Fabien,

> >> Here are patches against 2.6.27-rc6 and latest bluez git that add 
> >> support for point 1 below.
> > 
> > problem with these patches is that they are a layer violation between
> > L2CAP and HCI. 
> 
> Yes that is true but that is nothing that isn't already existing. Same 
> trick is used for L2CAP_CONNINFO.

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

> > It should also work on incoming and outgoing connections
> > the same way. 
> 
> I'm not following you there...

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

> > Also when using socket options, I prefer that we set them
> > and store the value and the execute it once the connections is up.
> 
> Agreed. I was just too lazy to do that :-)

Lazy doesn't get it upstream :)

> > 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.
> 
> 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. ;-)

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

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

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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Sniff mode issues regarding Sony Ericsson headsets: kernel patch proposal.

[Fabien Chevalier]

Hi Marcel,

>>>> Here are patches against 2.6.27-rc6 and latest bluez git that add 
>>>> support for point 1 below.
>>> problem with these patches is that they are a layer violation between
>>> L2CAP and HCI. 
>> Yes that is true but that is nothing that isn't already existing. Same 
>> trick is used for L2CAP_CONNINFO.
> 
> no they don't. Look at the code. It is nicely abstracted on how we
> handle the two layers.

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 :-).

> 
>>> It should also work on incoming and outgoing connections
>>> the same way. 
>> I'm not following you there...
> 
> We wanna be able to set this on a server socket and also enforce it on a
> connection we created.
> 
>>> Also when using socket options, I prefer that we set them
>>> and store the value and the execute it once the connections is up.
>> Agreed. I was just too lazy to do that :-)
> 
> Lazy doesn't get it upstream :)

lol :-)

> 
>>> 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.
>>>

That sounds reasonable...

>>> And of course this socket option also has to work for RFCOMM.
>> 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. ;-)
> 
> I treat RFCOMM and L2CAP the same. If we implement something for one
> protocol, we do have to do the same for the other.
> 
>> Do you have any comments on the user-land side or is it how you see things ?
> 
> 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.
> 
Agreed.

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

Cheers,

Fabien