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

Hi,

quoted

quoted

quoted

quoted

quoted

quoted

Can not accept incoming SCO connection. Kernel version 2.6.29. Kernel
log is as below. Is this a kernel bug? Is there any fix already for
this?

<6>[  158.339691] sco_connect_ind: hdev hci0, bdaddr CA:D3:10:55:0C:00
    -------// receive incoming sco
<6>[  158.518554] sco_connect_cfm: hcon cf18ee00 bdaddr CA:D3:10:55:0C:00 status
<6>[  158.721160] sco_connect_cfm: hcon cf149c00 bdaddr CA:D3:10:55:0C:00 status
<6>[  158.728851] sco_conn_add: hcon cf149c00 conn cc772640
<6>[  158.734313] sco_conn_ready: conn cc772640
-----------// handle sco connection complete
<6>[  158.738800] sco_sock_init: sk cf18c400
-----------// start handle sco socket
<6>[  158.742858] __sco_chan_add: conn cc772640
<6>[  159.693023] sco_sock_accept: sk ccfdf400 timeo 0
<6>[  159.708038] sco_sock_accept: new socket cf18c400
<6>[  159.713073] sco_sock_getsockopt: sk cf18c400
<6>[  159.717834] sco_sock_getsockopt_old: sk cf18c400
<6>[  159.722839] sco_sock_getsockopt_old: mtu 180
<6>[  159.727661] sco_sock_getname: sock ce9d80a0, sk cf18c400
<6>[  159.733398] sco_sock_getname: sock ce9d80a0, sk cf18c400
<6>[  159.739166] sco_sock_release: sock ce9d80a0, sk cf18c400
-----------// don't know why it call sco_sock_release
<6>[  159.745025] sco_sock_clear_timer: sock cf18c400 state 1
<6>[  159.750671] sco_sock_close: sk cf18c400 state 1 conn cc772640 socket ce9d8
<6>[  159.758453] sco_chan_del: sk cf18c400, conn cc772640, err 104
<6>[  159.764770] sco_sock_kill: sk cf18c400 state 9
<6>[  159.769592] sco_sock_destruct: sk cf18c400
------------// destruct sco socket, and disconnect SCO connection
<6>[  159.782745] l2cap_disconn_ind: hcon cf149c00
<6>[  159.787384] hci_acl_disconn: cf149c00
<6>[  159.950805] hci_disconn_complete_evt: hci0 status 0
<6>[  159.956207] l2cap_disconn_cfm: hcon cf149c00 reason 22
<6>[  159.961730] sco_disconn_cfm: hcon cf149c00 reason 22
-------------// sco disconnected
<6>[  159.967102] sco_conn_del: hcon cf149c00 conn cc772640, err 103
<6>[  162.130523] hci_disconn_complete_evt: hci0 status 0
<6>[  162.136291] l2cap_disconn_cfm: hcon cf18ee00 reason 19
<6>[  162.149871] sco_disconn_cfm: hcon cf18ee00 reason 19
<4>[  165.382141] done EDISCO CTRL ENABLE
<7>[  165.386077] sholes-panel:  edisco_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.

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 *sock, int
                break;
        }

-       release_sock(sk);
+    if (err != 0) {
+           release_sock(sk);
+    }
        return err;

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

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

so if Android would finally start using upstream BlueZ and not ship
their own stuff, we could have avoided this non-sense.

Regards

Marcel