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

[Lan Zhu <zhu.lan.cn@gmail.com>]

Hi Marcel,

2009/8/8 Marcel Holtmann <marcel@holtmann.org>:
> Hi,
>
>> >> 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>[ =A0158.339691] sco_connect_ind: hdev hci0, bdaddr CA:D3:10:55:0C=
:00
>> >> =A0 =A0 -------// receive incoming sco
>> >> <6>[ =A0158.518554] sco_connect_cfm: hcon cf18ee00 bdaddr CA:D3:10:55=
:0C:00 status
>> >> <6>[ =A0158.721160] sco_connect_cfm: hcon cf149c00 bdaddr CA:D3:10:55=
:0C:00 status
>> >> <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 cc772640=
 socket ce9d8
>> >> <6>[ =A0159.758453] sco_chan_del: sk cf18c400, conn cc772640, err 104
>> >> <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 10=
3
>> >> <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.
>
> Regards
>
> Marcel
>
>
>

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 !=3D 0) {
+           release_sock(sk);
+    }
        return err;


Thanks,
Zhu Lan