From: Nick Pelly <npelly@google.com>
To: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Cc: Marcel Holtmann <marcel@holtmann.org>, linux-bluetooth@vger.kernel.org
Subject: Re: bug? kernel does not send HCI Create Connection Cancel Command on shutdown() or close() of a connecting rfcomm socket
Date: Tue, 14 Jul 2009 09:15:15 -0700 [thread overview]
Message-ID: <35c90d960907140915u71f20473x83b25579c4117a2d@mail.gmail.com> (raw)
In-Reply-To: <2d5a2c100907131427x18f26f82g405a781cd8670b88@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 971 bytes --]
On Mon, Jul 13, 2009 at 2:27 PM, Luiz Augusto von
Dentz<luiz.dentz@gmail.com> wrote:
> Hi Nick,
>
> On Mon, Jul 13, 2009 at 12:46 PM, Nick Pelly<npelly@google.com> wrote:
>> Any comments on this patch?
>>
>> It works for me, but my understanding of the RFCOMM state machine is naive.
>>
>
> iirc BT_CONFIG(PN frame) means the DLC is being configured than we got
> into connecting phase (BT_CONNECT) and send SABM frame. Only when
> receiving UA frame DLC is consider connected (BT_CONNECTED), so your
> patch seems good by assuming that we don't need to send a DISC for a
> DLC not connected. But there is still a good use for it to cancel the
> DLC connection attempt, so perhaps a better alternative would be to
> use a much shorter timeout in those cases.
Thanks for the advice.
I have prepared a new patch which uses a very short timeout (10ms) on
the DLC disconnect when in BT_CONFIG. I have tested this patch and it
also resolves the issue. Patch attached.
Nick
[-- Attachment #2: 0001-Bluetooth-Use-a-very-short-timeout-for-dlci-disconne.patch --]
[-- Type: text/x-patch, Size: 2434 bytes --]
From 80bc07e9703e4303f04c26158b096bcbd00fd665 Mon Sep 17 00:00:00 2001
From: Nick Pelly <npelly@google.com>
Date: Tue, 14 Jul 2009 07:57:54 -0700
Subject: [PATCH] Bluetooth: Use a very short timeout for dlci disconnect when in BT_CONFIG.
This fixes a bug where shutdown() and close() on a rfcomm socket during ACL
connection would not cause HCI Create Connection Cancel.
Signed-off-by: Nick Pelly <npelly@google.com>
---
include/net/bluetooth/rfcomm.h | 7 ++++---
net/bluetooth/rfcomm/core.c | 10 +++++++---
2 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/include/net/bluetooth/rfcomm.h b/include/net/bluetooth/rfcomm.h
index 8007261..eeb3ffa 100644
--- a/include/net/bluetooth/rfcomm.h
+++ b/include/net/bluetooth/rfcomm.h
@@ -26,9 +26,10 @@
#define RFCOMM_PSM 3
-#define RFCOMM_CONN_TIMEOUT (HZ * 30)
-#define RFCOMM_DISC_TIMEOUT (HZ * 20)
-#define RFCOMM_AUTH_TIMEOUT (HZ * 25)
+#define RFCOMM_CONN_TIMEOUT (HZ * 30)
+#define RFCOMM_DISC_TIMEOUT (HZ * 20)
+#define RFCOMM_AUTH_TIMEOUT (HZ * 25)
+#define RFCOMM_CONFIG_DISC_TIMEOUT (HZ / 100)
#define RFCOMM_DEFAULT_MTU 127
#define RFCOMM_DEFAULT_CREDITS 7
diff --git a/net/bluetooth/rfcomm/core.c b/net/bluetooth/rfcomm/core.c
index 1d0fb0f..476d856 100644
--- a/net/bluetooth/rfcomm/core.c
+++ b/net/bluetooth/rfcomm/core.c
@@ -419,6 +419,7 @@ int rfcomm_dlc_open(struct rfcomm_dlc *d, bdaddr_t *src, bdaddr_t *dst, u8 chann
static int __rfcomm_dlc_close(struct rfcomm_dlc *d, int err)
{
+ long timeout = RFCOMM_DISC_TIMEOUT;
struct rfcomm_session *s = d->session;
if (!s)
return 0;
@@ -427,8 +428,11 @@ static int __rfcomm_dlc_close(struct rfcomm_dlc *d, int err)
d, d->state, d->dlci, err, s);
switch (d->state) {
- case BT_CONNECT:
case BT_CONFIG:
+ timeout = RFCOMM_CONFIG_DISC_TIMEOUT;
+ /* Fall-through */
+
+ case BT_CONNECT:
if (test_and_clear_bit(RFCOMM_DEFER_SETUP, &d->flags)) {
set_bit(RFCOMM_AUTH_REJECT, &d->flags);
rfcomm_schedule(RFCOMM_SCHED_AUTH);
@@ -440,10 +444,10 @@ static int __rfcomm_dlc_close(struct rfcomm_dlc *d, int err)
d->state = BT_DISCONN;
if (skb_queue_empty(&d->tx_queue)) {
rfcomm_send_disc(s, d->dlci);
- rfcomm_dlc_set_timer(d, RFCOMM_DISC_TIMEOUT);
+ rfcomm_dlc_set_timer(d, timeout);
} else {
rfcomm_queue_disc(d);
- rfcomm_dlc_set_timer(d, RFCOMM_DISC_TIMEOUT * 2);
+ rfcomm_dlc_set_timer(d, timeout * 2);
}
break;
--
1.6.3.1
next prev parent reply other threads:[~2009-07-14 16:15 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-20 1:20 bug? kernel does not send HCI Create Connection Cancel Command on shutdown() or close() of a connecting rfcomm socket Nick Pelly
2009-05-20 2:49 ` Marcel Holtmann
2009-05-20 21:57 ` Nick Pelly
2009-07-06 18:55 ` Nick Pelly
2009-07-06 23:31 ` Marcel Holtmann
2009-07-09 19:37 ` Nick Pelly
2009-07-13 15:46 ` Nick Pelly
2009-07-13 21:27 ` Luiz Augusto von Dentz
2009-07-14 16:15 ` Nick Pelly [this message]
2009-07-15 22:11 ` Nick Pelly
2009-08-06 18:03 ` Nick Pelly
2010-02-03 1:54 ` Nick Pelly
2010-02-03 1:56 ` Nick Pelly
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=35c90d960907140915u71f20473x83b25579c4117a2d@mail.gmail.com \
--to=npelly@google.com \
--cc=linux-bluetooth@vger.kernel.org \
--cc=luiz.dentz@gmail.com \
--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;
as well as URLs for NNTP newsgroup(s).