From: Syam Sidhardhan <[email protected]>
For certain devices (ex: HID mouse), support for authentication,
pairing and bonding is optional. For such devices, the ACL alive
for too long after the L2CAP disconnection.
To avoid the ACL alive for too long after L2CAP disconnection, reset the ACL
disconnect timeout back to HCI_DISCONN_TIMEOUT during L2CAP connect.
While merging the commit id:a9ea3ed9b71cc3271dd59e76f65748adcaa76422
this issue might have introduced.
Signed-off-by: Sang-Ki Park <[email protected]>
Signed-off-by: Chan-yeol Park <[email protected]>
Signed-off-by: Jaganath Kanakkassery <[email protected]>
Signed-off-by: Syam Sidhardhan <[email protected]>
---
v1 -> Modified the code as per the latest code.
v2 -> Add descriptive comment as per Marcel request.
v3 -> Moved from l2cap_conn_ready() to l2cap_connect() inorder to fix remote
non ssp pairing timeout. Generated the patch based on bluetooth.git tree.
net/bluetooth/l2cap_core.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
index 68843a2..8179fc3 100644
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -3753,6 +3753,13 @@ static struct l2cap_chan *l2cap_connect(struct l2cap_conn *conn,
hci_conn_hold(conn->hcon);
+ /* For certain devices (ex: HID mouse), support for authentication,
+ * pairing and bonding is optional. For such devices, inorder to avoid
+ * the ACL alive for too long after L2CAP disconnection, reset the ACL
+ * disc_timeout back to HCI_DISCONN_TIMEOUT during L2CAP connect.
+ */
+ conn->hcon->disc_timeout = HCI_DISCONN_TIMEOUT;
+
bacpy(&bt_sk(sk)->src, conn->src);
bacpy(&bt_sk(sk)->dst, conn->dst);
chan->psm = psm;
--
1.7.9.5
Hi Syam,
> For certain devices (ex: HID mouse), support for authentication,
> pairing and bonding is optional. For such devices, the ACL alive
> for too long after the L2CAP disconnection.
>
> To avoid the ACL alive for too long after L2CAP disconnection, reset the ACL
> disconnect timeout back to HCI_DISCONN_TIMEOUT during L2CAP connect.
>
> While merging the commit id:a9ea3ed9b71cc3271dd59e76f65748adcaa76422
> this issue might have introduced.
>
> Signed-off-by: Sang-Ki Park <[email protected]>
> Signed-off-by: Chan-yeol Park <[email protected]>
> Signed-off-by: Jaganath Kanakkassery <[email protected]>
> Signed-off-by: Syam Sidhardhan <[email protected]>
> ---
> v1 -> Modified the code as per the latest code.
> v2 -> Add descriptive comment as per Marcel request.
> v3 -> Moved from l2cap_conn_ready() to l2cap_connect() inorder to fix remote
> non ssp pairing timeout. Generated the patch based on bluetooth.git tree.
>
> net/bluetooth/l2cap_core.c | 7 +++++++
> 1 file changed, 7 insertions(+)
is the any chance you have btmon or hcidump traces that would show this kind of behavior. Adding these to the commit message might be really helpful in case we have understand again why we did this.
Regards
Marcel
Hi Marcel,
On Mon, Jul 29, 2013 at 7:13 AM, Marcel Holtmann <[email protected]> wrote:
> Hi Syam,
>
>> For certain devices (ex: HID mouse), support for authentication,
>> pairing and bonding is optional. For such devices, the ACL alive
>> for too long after the L2CAP disconnection.
>>
>> To avoid the ACL alive for too long after L2CAP disconnection, reset the ACL
>> disconnect timeout back to HCI_DISCONN_TIMEOUT during L2CAP connect.
>>
>> While merging the commit id:a9ea3ed9b71cc3271dd59e76f65748adcaa76422
>> this issue might have introduced.
>>
>> Signed-off-by: Sang-Ki Park <[email protected]>
>> Signed-off-by: Chan-yeol Park <[email protected]>
>> Signed-off-by: Jaganath Kanakkassery <[email protected]>
>> Signed-off-by: Syam Sidhardhan <[email protected]>
>> ---
>> v1 -> Modified the code as per the latest code.
>> v2 -> Add descriptive comment as per Marcel request.
>> v3 -> Moved from l2cap_conn_ready() to l2cap_connect() inorder to fix remote
>> non ssp pairing timeout. Generated the patch based on bluetooth.git tree.
>>
>> net/bluetooth/l2cap_core.c | 7 +++++++
>> 1 file changed, 7 insertions(+)
>
> is the any chance you have btmon or hcidump traces that would show this kind of behavior. Adding these to the commit message might be really helpful in case we have understand again why we did this.
Yes, I found the particular mouse device after a long search and
captured the hcidump log.
I'll send another patch version with the logs. Sorry for the delay.
Regards,
Syam