Re: conn->state vs conn->sk->sk_state

["jaikumar Ganesh" <jaikumarg@gmail.com>]

Hi Marcel,

On Fri, Dec 19, 2008 at 10:58 AM, Marcel Holtmann <marcel@holtmann.org> 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