Hi Marcel,
On Fri, Dec 19, 2008 at 10:58 AM, Marcel Holtmann <marcel@xxxxxxxxxxxx> wrote:
> Hi Jaikumar,
>
>> Looking at this a bit further, I see a discrepancy between the code in
>> function hci_conn_complete_evt and hci_sync_conn_complete_evt.
>> Is this intentional or a bug ? Like I said below, using
>> hci_conn_complete_evt (when the AG doesn't support eSCO) results in
>> the connect() never returning because the socket state is not updated.
>
> I still have no idea what's your problem. It doesn't matter if the
> remote side supports eSCO or not. The sync setup commands can be used
> even for setting up SCO channels.
>
So here is the problem:
The AG doesn't support eSCO i.e disable_esco is Y and
lmp_esco_capable(dev) evaluates to 0, so we try to establish a SCO
channel irrespective of whether the remote support eSCO or not.
So sco_connect is called, and after the hci_connect, hcon->state is
BT_CONNECT and the sk->sk_state = BT_CONNECT.
When we get a response from the remote device
hci_connect_complete_evt is called which sets the conn->state to
BT_CONNECTED. However, as
hci_proto_connect_cfm is not called (this was being called in
2.6.25) , sk->sk_state remained in BT_CONNECT state. Hence, we get
stuck in bt_sock_wait_state
and the connect() times out.
Thanks
Jaikumar
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
