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