From: Marcel Holtmann <marcel@holtmann.org>
To: BlueZ Mailing List <bluez-devel@lists.sourceforge.net>
Subject: [Bluez-devel] Apple mouse and disconnect problem
Date: Sun, 21 Dec 2003 02:52:32 +0100 [thread overview]
Message-ID: <1071971552.2684.28.camel@pegasus> (raw)
[-- Attachment #1: Type: text/plain, Size: 1701 bytes --]
Hi Folks,
I played with the Apple Bluetooth mouse and I had a problem with the
termination of the ACL link after the two L2CAP channels are closed. The
ACL link still stays there, but not always. After a long time of testing
and tracking possible errors I found that the Apple mouse itself never
terminates the ACL link (like it does not role switch itself or go to
sniff mode after idle time). So the host stack has to terminate the ACL
link if no other L2CAP connection is open. In the case of BlueZ we do
this only for outgoing and not for incoming ones. And this means that if
the mouse reconnects the ACL link will never closed if we terminate the
connection because of idle time or because the bthid daemon was shut
down. I looked through the revisions of the HCI core code, but we never
close the ACL link if the connection was not created by us and so I must
assume that no one else had this problem before. However the relevant
code is in include/net/bluetooth/hci_core.h
static inline void hci_conn_put(struct hci_conn *conn)
{
if (atomic_dec_and_test(&conn->refcnt)) {
if (conn->type == SCO_LINK)
hci_conn_set_timer(conn, HZ / 100);
else if (conn->out)
hci_conn_set_timer(conn, HCI_DISCONN_TIMEOUT);
}
}
My question is now, why we only initiate the disconnect timer for
outgoing connections? Is the device that creates the ACL link also
responsible for its termination? If yes, why the hell is the Bluetooth
stack on the Apple mouse not doing this and how did this device then got
qualified?
I used the attached patch and everything seems to be ok. Any comments?
Regards
Marcel
[-- Attachment #2: patch --]
[-- Type: text/plain, Size: 540 bytes --]
--- 1.13/include/net/bluetooth/hci_core.h Thu Jun 5 02:57:06 2003
+++ edited/include/net/bluetooth/hci_core.h Sun Dec 21 02:29:01 2003
@@ -281,10 +281,9 @@
static inline void hci_conn_put(struct hci_conn *conn)
{
if (atomic_dec_and_test(&conn->refcnt)) {
- if (conn->type == SCO_LINK)
- hci_conn_set_timer(conn, HZ / 100);
- else if (conn->out)
- hci_conn_set_timer(conn, HCI_DISCONN_TIMEOUT);
+ unsigned long timeo = (conn->type == ACL_LINK) ?
+ HCI_DISCONN_TIMEOUT : HZ / 100;
+ hci_conn_set_timer(conn, timeo);
}
}
next reply other threads:[~2003-12-21 1:52 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-12-21 1:52 Marcel Holtmann [this message]
-- strict thread matches above, loose matches on Subject: below --
2004-01-05 16:07 [Bluez-devel] Apple mouse and disconnect problem Chris Hubball
2004-01-05 16:27 ` Marcel Holtmann
2004-01-05 17:15 ` Steven Singer
2004-01-05 16:52 Chris Hubball
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=1071971552.2684.28.camel@pegasus \
--to=marcel@holtmann.org \
--cc=bluez-devel@lists.sourceforge.net \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.