public inbox for linux-bluetooth@vger.kernel.org
 help / color / mirror / Atom feed
From: Nick Pelly <npelly@google.com>
To: jaikumar Ganesh <jaikumarg@gmail.com>
Cc: Marcel Holtmann <marcel@holtmann.org>, linux-bluetooth@vger.kernel.org
Subject: Re: conn->state vs conn->sk->sk_state
Date: Mon, 22 Dec 2008 08:16:02 -0800	[thread overview]
Message-ID: <35c90d960812220816g6670580dlb01e49bf9ca56f3e@mail.gmail.com> (raw)
In-Reply-To: <ac290f760812191028p8aa03d6l4374410d742aa9dc@mail.gmail.com>

On Fri, Dec 19, 2008 at 10:28 AM, jaikumar Ganesh <jaikumarg@gmail.com> wrote:
> 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.


Explained another way:

JK found that in 2.6.27 with "echo Y >
/sys/module/sco/parameters/disable_esco" the socket state is never
updated to BT_CONNECTED. The userspace connect() call then times out,
even though the transport is connected. This appears to be because
hci_proto_connect_cfm() is not called when the connection complete
event arrives. Below is a patch that resolves this issue for us.

This is a request for comment as to whether this patch is correct. It
contradicts Marcel's change 769be974 which explicitly moved
hci_proto_connect_cfm() into the ev->status conditional.

Thanks,
Nick



commit 654488a822615b645c43605ab24f0305b56b40dc
Author: Jaikumar Ganesh <jaikumar@google.com>
Date:   Fri Dec 19 14:17:53 2008 -0800

    [Bluetooth] Fix SCO connection issue

    When the AG supports only SCO connections, on receipt of the
    HCI_EV_CONN_COMPLETE packet, the connect state is changed to
    BT_CONNECTED but the socket state is not updated. Hence, the
    connect() call times out even though the SCO connection has
    been established.

    Signed-off-by: Jaikumar Ganesh <jaikumar@google.com>

diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index ad7a553..3cba788 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -916,8 +916,8 @@ static inline void hci_conn_complete_evt(struct
hci_dev *hdev, struct sk_buff *s
                }
        }

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

  reply	other threads:[~2008-12-22 16:16 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <ac290f760812171405r79473a67l6769913bc7e62d2e@mail.gmail.com>
2008-12-17 22:07 ` conn->state vs conn->sk->sk_state jaikumar Ganesh
2008-12-19  2:15   ` jaikumar Ganesh
2008-12-19 18:58     ` Marcel Holtmann
2008-12-19 18:28       ` jaikumar Ganesh
2008-12-22 16:16         ` Nick Pelly [this message]
2008-12-22 19:18           ` Marcel Holtmann
2008-12-22 19:21             ` jaikumar Ganesh

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=35c90d960812220816g6670580dlb01e49bf9ca56f3e@mail.gmail.com \
    --to=npelly@google.com \
    --cc=jaikumarg@gmail.com \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=marcel@holtmann.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox