All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] Bluetooth: Terminate the link if pairing is cancelled
@ 2020-04-14 18:58 Manish Mandlik
  2020-04-28  9:38 ` Marcel Holtmann
  0 siblings, 1 reply; 5+ messages in thread
From: Manish Mandlik @ 2020-04-14 18:58 UTC (permalink / raw)
  To: marcel, luiz.dentz
  Cc: linux-bluetooth, chromeos-bluetooth-upstreaming, Alain Michaud,
	Manish Mandlik, David S. Miller, Johan Hedberg, netdev,
	linux-kernel, Jakub Kicinski

If user decides to cancel ongoing pairing process (e.g. by clicking
the cancel button on the pairing/passkey window), abort any ongoing
pairing and then terminate the link.

Signed-off-by: Manish Mandlik <mmandlik@google.com>
---
Hello Linux-Bluetooth,

  This patch aborts any ongoing pairing and then terminates the link
  by calling hci_abort_conn() in cancel_pair_device() function.

  However, I'm not very sure if hci_abort_conn() should be called here
  in cancel_pair_device() or in smp for example to terminate the link
  after it had sent the pairing failed PDU.

  Please share your thoughts on this.

Thanks and regards,
Manish.

 net/bluetooth/mgmt.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c
index 6552003a170eb..1aaa44282af4f 100644
--- a/net/bluetooth/mgmt.c
+++ b/net/bluetooth/mgmt.c
@@ -3030,6 +3030,18 @@ static int cancel_pair_device(struct sock *sk, struct hci_dev *hdev, void *data,
 
 	err = mgmt_cmd_complete(sk, hdev->id, MGMT_OP_CANCEL_PAIR_DEVICE, 0,
 				addr, sizeof(*addr));
+
+	/* Since user doesn't want to proceed with the connection,
+	 * abort any ongoing pairing and then terminate the link.
+	 */
+	if (addr->type == BDADDR_BREDR)
+		hci_remove_link_key(hdev, &addr->bdaddr);
+	else
+		smp_cancel_and_remove_pairing(hdev, &addr->bdaddr,
+					      le_addr_type(addr->type));
+
+	hci_abort_conn(conn, HCI_ERROR_REMOTE_USER_TERM);
+
 unlock:
 	hci_dev_unlock(hdev);
 	return err;
-- 
2.26.0.110.g2183baf09c-goog


^ permalink raw reply related	[flat|nested] 5+ messages in thread

* Re: [PATCH] Bluetooth: Terminate the link if pairing is cancelled
  2020-04-14 18:58 [PATCH] Bluetooth: Terminate the link if pairing is cancelled Manish Mandlik
@ 2020-04-28  9:38 ` Marcel Holtmann
  2020-05-05 23:59   ` Luiz Augusto von Dentz
  0 siblings, 1 reply; 5+ messages in thread
From: Marcel Holtmann @ 2020-04-28  9:38 UTC (permalink / raw)
  To: Manish Mandlik
  Cc: Luiz Augusto von Dentz, linux-bluetooth,
	ChromeOS Bluetooth Upstreaming, Alain Michaud, David S. Miller,
	Johan Hedberg, netdev, LKML, Jakub Kicinski

Hi Manish,

> If user decides to cancel ongoing pairing process (e.g. by clicking
> the cancel button on the pairing/passkey window), abort any ongoing
> pairing and then terminate the link.
> 
> Signed-off-by: Manish Mandlik <mmandlik@google.com>
> ---
> Hello Linux-Bluetooth,
> 
>  This patch aborts any ongoing pairing and then terminates the link
>  by calling hci_abort_conn() in cancel_pair_device() function.
> 
>  However, I'm not very sure if hci_abort_conn() should be called here
>  in cancel_pair_device() or in smp for example to terminate the link
>  after it had sent the pairing failed PDU.
> 
>  Please share your thoughts on this.

I am look into this. Just bare with me for a bit to verify the call chain.

Regards

Marcel


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] Bluetooth: Terminate the link if pairing is cancelled
  2020-04-28  9:38 ` Marcel Holtmann
@ 2020-05-05 23:59   ` Luiz Augusto von Dentz
  2020-05-06 11:09     ` Marcel Holtmann
  0 siblings, 1 reply; 5+ messages in thread
From: Luiz Augusto von Dentz @ 2020-05-05 23:59 UTC (permalink / raw)
  To: Marcel Holtmann
  Cc: Manish Mandlik, linux-bluetooth, ChromeOS Bluetooth Upstreaming,
	Alain Michaud, David S. Miller, Johan Hedberg, netdev, LKML,
	Jakub Kicinski

Hi Manish, Marcel,

On Tue, Apr 28, 2020 at 2:38 AM Marcel Holtmann <marcel@holtmann.org> wrote:
>
> Hi Manish,
>
> > If user decides to cancel ongoing pairing process (e.g. by clicking
> > the cancel button on the pairing/passkey window), abort any ongoing
> > pairing and then terminate the link.
> >
> > Signed-off-by: Manish Mandlik <mmandlik@google.com>
> > ---
> > Hello Linux-Bluetooth,
> >
> >  This patch aborts any ongoing pairing and then terminates the link
> >  by calling hci_abort_conn() in cancel_pair_device() function.
> >
> >  However, I'm not very sure if hci_abort_conn() should be called here
> >  in cancel_pair_device() or in smp for example to terminate the link
> >  after it had sent the pairing failed PDU.
> >

Id recommend leaving the hci_abort_conn out since that is a policy
decision the userspace should be in charge to decide if the link
should be disconnected or not.

> >  Please share your thoughts on this.
>
> I am look into this. Just bare with me for a bit to verify the call chain.
>
> Regards
>
> Marcel
>


-- 
Luiz Augusto von Dentz

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] Bluetooth: Terminate the link if pairing is cancelled
  2020-05-05 23:59   ` Luiz Augusto von Dentz
@ 2020-05-06 11:09     ` Marcel Holtmann
       [not found]       ` <CAGPPCLC_NkrrjiOT_LgmFV83rOgMab5e+M-S=zDHu_OMKD2-TA@mail.gmail.com>
  0 siblings, 1 reply; 5+ messages in thread
From: Marcel Holtmann @ 2020-05-06 11:09 UTC (permalink / raw)
  To: Luiz Augusto von Dentz
  Cc: Manish Mandlik, linux-bluetooth, ChromeOS Bluetooth Upstreaming,
	Alain Michaud, David S. Miller, Johan Hedberg, netdev, LKML,
	Jakub Kicinski

Hi Luiz,

>>> If user decides to cancel ongoing pairing process (e.g. by clicking
>>> the cancel button on the pairing/passkey window), abort any ongoing
>>> pairing and then terminate the link.
>>> 
>>> Signed-off-by: Manish Mandlik <mmandlik@google.com>
>>> ---
>>> Hello Linux-Bluetooth,
>>> 
>>> This patch aborts any ongoing pairing and then terminates the link
>>> by calling hci_abort_conn() in cancel_pair_device() function.
>>> 
>>> However, I'm not very sure if hci_abort_conn() should be called here
>>> in cancel_pair_device() or in smp for example to terminate the link
>>> after it had sent the pairing failed PDU.
>>> 
> 
> Id recommend leaving the hci_abort_conn out since that is a policy
> decision the userspace should be in charge to decide if the link
> should be disconnected or not.

eventually the link will disconnect anyway if we have no users. However maybe we should try to track if we created the link because Pair Device action. If created the link, then aborting the pairing should disconnect the link right away. Otherwise we can leave it around.

Regards

Marcel


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] Bluetooth: Terminate the link if pairing is cancelled
       [not found]       ` <CAGPPCLC_NkrrjiOT_LgmFV83rOgMab5e+M-S=zDHu_OMKD2-TA@mail.gmail.com>
@ 2020-06-03 17:50         ` Marcel Holtmann
  0 siblings, 0 replies; 5+ messages in thread
From: Marcel Holtmann @ 2020-06-03 17:50 UTC (permalink / raw)
  To: Manish Mandlik
  Cc: Luiz Augusto von Dentz, linux-bluetooth,
	ChromeOS Bluetooth Upstreaming, Alain Michaud, David S. Miller,
	Johan Hedberg, netdev, LKML, Jakub Kicinski

Hi Manish,

> Based on your feedback, in the BlueZ kernel, if we plan to track whether the link was created because of Pair Device action or not, we'll need to add a flag in struch hci_conn and update related functions/APIs. I was wondering if this would look like a clean fix or not. 
> 
> Another option could be disconnecting from BlueZ daemon while handling 'cancel pairing' user request. But the problem with this approach is that there is no way to request the kernel to send SMP failure PDU with the existing implementation.
> 
> Third option could be handling this in the chromium and requesting a disconnect when the user hits the cancel button. I believe Ubuntu/Android are taking a similar approach. However, on Android, if the 'cancel' button is selected on the pairing window, it shows 'pairing failed because of invalid passkey' message.
> 
> Bluetooth specification doesn't have any mention about how to handle the pairing cancel case. Based on the statistics we have for ChromeOS, over 60% pairing attempts are cancelled by users. Since the link is not terminated, the bluetooth keyboard keeps on requesting to enter a new passkey even if the user selects to cancel the pairing and there is no way to cancel the pairing process.
> 
> Can you please help me select the better approach to handle the pairing cancel case? Should we need to propose this to be addressed in the Bluetooth Specification as well?

are we sending Cancel Pairing correctly? If so and we only care about the cancel case, then I would just track if the connection was triggered by a pairing and then only cancel pairing terminate the connection.

Regards

Marcel


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2020-06-03 17:50 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-04-14 18:58 [PATCH] Bluetooth: Terminate the link if pairing is cancelled Manish Mandlik
2020-04-28  9:38 ` Marcel Holtmann
2020-05-05 23:59   ` Luiz Augusto von Dentz
2020-05-06 11:09     ` Marcel Holtmann
     [not found]       ` <CAGPPCLC_NkrrjiOT_LgmFV83rOgMab5e+M-S=zDHu_OMKD2-TA@mail.gmail.com>
2020-06-03 17:50         ` Marcel Holtmann

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.