Re: sco connection issue for BlueZ 4.x on kernel 2.6.29

Hi Marcel,

2009/8/12 Marcel Holtmann [off-list ref]:

Hi,

quoted

quoted

quoted

quoted

quoted

Can not accept incoming SCO connection. Kernel version 2.6.29. Ker=

nel

quoted

quoted

quoted

quoted

quoted

log is as below. Is this a kernel bug? Is there any fix already fo=

r

quoted

quoted

quoted

quoted

quoted

this?

<6>[ =A0158.339691] sco_connect_ind: hdev hci0, bdaddr CA:D3:10:55=

:0C:00

quoted

quoted

quoted

quoted

quoted

=A0 =A0 -------// receive incoming sco
<6>[ =A0158.518554] sco_connect_cfm: hcon cf18ee00 bdaddr CA:D3:10=

:55:0C:00 status

quoted

quoted

quoted

quoted

quoted

<6>[ =A0158.721160] sco_connect_cfm: hcon cf149c00 bdaddr CA:D3:10=

:55:0C:00 status

quoted

quoted

quoted

quoted

quoted

<6>[ =A0158.728851] sco_conn_add: hcon cf149c00 conn cc772640
<6>[ =A0158.734313] sco_conn_ready: conn cc772640
-----------// handle sco connection complete
<6>[ =A0158.738800] sco_sock_init: sk cf18c400
-----------// start handle sco socket
<6>[ =A0158.742858] __sco_chan_add: conn cc772640
<6>[ =A0159.693023] sco_sock_accept: sk ccfdf400 timeo 0
<6>[ =A0159.708038] sco_sock_accept: new socket cf18c400
<6>[ =A0159.713073] sco_sock_getsockopt: sk cf18c400
<6>[ =A0159.717834] sco_sock_getsockopt_old: sk cf18c400
<6>[ =A0159.722839] sco_sock_getsockopt_old: mtu 180
<6>[ =A0159.727661] sco_sock_getname: sock ce9d80a0, sk cf18c400
<6>[ =A0159.733398] sco_sock_getname: sock ce9d80a0, sk cf18c400
<6>[ =A0159.739166] sco_sock_release: sock ce9d80a0, sk cf18c400
-----------// don't know why it call sco_sock_release
<6>[ =A0159.745025] sco_sock_clear_timer: sock cf18c400 state 1
<6>[ =A0159.750671] sco_sock_close: sk cf18c400 state 1 conn cc772=

640 socket ce9d8

quoted

quoted

quoted

quoted

quoted

<6>[ =A0159.758453] sco_chan_del: sk cf18c400, conn cc772640, err =

104

quoted

quoted

quoted

quoted

quoted

<6>[ =A0159.764770] sco_sock_kill: sk cf18c400 state 9
<6>[ =A0159.769592] sco_sock_destruct: sk cf18c400
------------// destruct sco socket, and disconnect SCO connection
<6>[ =A0159.782745] l2cap_disconn_ind: hcon cf149c00
<6>[ =A0159.787384] hci_acl_disconn: cf149c00
<6>[ =A0159.950805] hci_disconn_complete_evt: hci0 status 0
<6>[ =A0159.956207] l2cap_disconn_cfm: hcon cf149c00 reason 22
<6>[ =A0159.961730] sco_disconn_cfm: hcon cf149c00 reason 22
-------------// sco disconnected
<6>[ =A0159.967102] sco_conn_del: hcon cf149c00 conn cc772640, err=

 103

quoted

quoted

quoted

quoted

quoted

<6>[ =A0162.130523] hci_disconn_complete_evt: hci0 status 0
<6>[ =A0162.136291] l2cap_disconn_cfm: hcon cf18ee00 reason 19
<6>[ =A0162.149871] sco_disconn_cfm: hcon cf18ee00 reason 19
<4>[ =A0165.382141] done EDISCO CTRL ENABLE
<7>[ =A0165.386077] sholes-panel: =A0edisco_ctrl_enable_te

what kind of program are you using?

This issue was found when testing HFP on android platform with a
Bluetooth carkit which is not support eSCO. At first android tries to
establish eSCO with carkit, carkit response with error that eSCO is
not supported. Then carkit send SCO connect request to android
automatically, android accepted this connection but disconnect it
immediately.

I think we fixed all of these. Try a 2.6.31-rc5 kernel. Also you would
need to include the output of hcidump -X -V.

I think there is a bug in the function sco_sock_getsockopt_old() in sco.=

c.

quoted

I changed the code like below and then test sco again, incoming sco
connection can be created successfully now.

@@ -719,7 +715,10 @@ static int sco_sock_getsockopt_old(struct socket *s=

ock, int

quoted

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 break;
=A0 =A0 =A0 =A0 }

- =A0 =A0 =A0 release_sock(sk);
+ =A0 =A0if (err !=3D 0) {
+ =A0 =A0 =A0 =A0 =A0 release_sock(sk);
+ =A0 =A0}
=A0 =A0 =A0 =A0 return err;

that is not it for sure. The release_sock() is the unlock function and
your patch create a locking imbalance.

Regards

Marcel

This issue is fixed by Johan's commit of "Don't enable the SCO server
socket when not necessary"
(http://git.kernel.org/?p=3Dbluetooth/bluez.git;a=3Dcommit;h=3Dcd6678404659=
a1bf6449b5b1d48b17883d895aef)

Thanks,
Zhu Lan