From: Marcel Holtmann <marcel@holtmann.org>
To: Manish Mandlik <mmandlik@google.com>
Cc: Luiz Augusto von Dentz <luiz.dentz@gmail.com>,
linux-bluetooth <linux-bluetooth@vger.kernel.org>,
ChromeOS Bluetooth Upstreaming
<chromeos-bluetooth-upstreaming@chromium.org>,
Alain Michaud <alainm@chromium.org>,
"David S. Miller" <davem@davemloft.net>,
Johan Hedberg <johan.hedberg@gmail.com>,
netdev <netdev@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Jakub Kicinski <kuba@kernel.org>
Subject: Re: [PATCH] Bluetooth: Terminate the link if pairing is cancelled
Date: Wed, 3 Jun 2020 19:50:26 +0200 [thread overview]
Message-ID: <61400662-2434-4D7F-B9D1-19CC698645DC@holtmann.org> (raw)
In-Reply-To: <CAGPPCLC_NkrrjiOT_LgmFV83rOgMab5e+M-S=zDHu_OMKD2-TA@mail.gmail.com>
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
prev parent reply other threads:[~2020-06-03 17:50 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-14 18:58 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 message]
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=61400662-2434-4D7F-B9D1-19CC698645DC@holtmann.org \
--to=marcel@holtmann.org \
--cc=alainm@chromium.org \
--cc=chromeos-bluetooth-upstreaming@chromium.org \
--cc=davem@davemloft.net \
--cc=johan.hedberg@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-bluetooth@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luiz.dentz@gmail.com \
--cc=mmandlik@google.com \
--cc=netdev@vger.kernel.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
all inboxes | Powered by JetHome®