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

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

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.

//hci_conn_complete_evt
        if (ev->status) {
                hci_proto_connect_cfm(conn, ev->status);
                hci_conn_del(conn);
        }

unlock:
        hci_dev_unlock(hdev);
        hci_conn_check_pending(hdev);
}

//hci_sync_conn_complete_evt.

        hci_proto_connect_cfm(conn, ev->status);
        if (ev->status)
                hci_conn_del(conn);
unlock:
        hci_dev_unlock(hdev);
}

Any pointers / hints ?

Thanks
Jaikumar
On Wed, Dec 17, 2008 at 2:07 PM, jaikumar Ganesh <jaikumarg@gmail.com> wrote:
>  Folks,
>     I have a device which supports only SCO connections.  So when the
> application calls sco_sock_connect -> sco_connect, the conn->state is
> set to BT_CONNECT and then bt_sock_state is called waiting for the
> conn->sk->sk_state to be set to BT_CONNECTED.
>     When the HCI Connection Complete event comes, the conn->state is
> set to BT_CONNECTED.
>
>     In 2.6.25 ->  hci_proto_connect_cfm(conn, ev->status) was called
> at the end of hci_conn_complete_evt which used to set the
> conn->sk->sk_state to BT_CONNECTED in sco_conn_ready.
>     In 2.6.27->  hci_proto_connect_cfm(conn, ev->status) is called
> only if the ev_status is 1.
>                      Hence, the conn->sk->sk_state doesn't get set to
> BT_CONNECTED and hence the connect() times out.
>
>    Should we be calling sco_conn_ready in sco_connect similar to
> sco_connect_cfm if conn != null ?
>    I didn't see anyone else complain so am I missing something obvious ?
>
>
>     * I am new to this list so please excuse me if the above doesn't
> make sense.
>
>  Thanks
>  Jaikumar
>