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);
}
next prev parent 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