Re: [PATCH BlueZ] doc/agent-api: Add AuthenticationFailed method

On Mon, 2021-06-28 at 10:32 -0700, Luiz Augusto von Dentz wrote:

Hi Bastien,

On Mon, Jun 28, 2021 at 7:59 AM Bastien Nocera [off-list ref]
wrote:

quoted

On Wed, 2021-06-23 at 11:43 -0700, Luiz Augusto von Dentz wrote:

quoted

From: Luiz Augusto von Dentz <redacted>

This introduces AuthenticationFailed method which is used to
indicate
when there was an authentication failure with a remote device
which is
recommended by the core spec:

BLUETOOTH CORE SPECIFICATION Version 5.2 | Vol 3, Part C page
1314:
 '5.2.2.3 Simple Pairing after authentication failure
 When the link key is stored, subsequent connections to the same
device
 will use authentication but this may fail if the remote device
has
 deleted the link key. Table 5.2 defines what shall be done
depending
 on the type of the link key and whether bonding was performed or
not.'

So following Table 5.2 recommendation the AuthenticationFailed
method
would be called when authentication fails with a bonded device.
---
 doc/agent-api.txt | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/doc/agent-api.txt b/doc/agent-api.txt
index 0d9347cab..91d752b0a 100644
--- a/doc/agent-api.txt
+++ b/doc/agent-api.txt

@@ -183,3 +183,8 @@ Methods             void Release()

                        This method gets called to indicate that
the
agent
                        request failed before a reply was
returned.
+
+               void AuthenticationFailed(object device, byte
status)
+
+                       This method indicates that there was an
authentication
+                       failure with a remote device.

Is there a way that we could have some persistent storage for when
the
last authentication error happened?

This would allow showing a /!\ icon in the device list even though
we
don't have an agent running in the session, just when the settings
are
open, in GNOME.

I guess you are suggesting introducing a property to the device
object
e.g. AuthenticationStatus or something like that, that way one can
figure out if the device needs repairing or not.

That would work pretty well, yes.

 Alternatively we
could just remove the device, after a few attempts, if there is no
agent of the agent don't implement the new method.

This is very much a dark pattern. I can expect to get bug reports about
devices disappearing from the known devices list on the computer when
it's actually the device losing its link keys for example.

I wouldn't recommend doing this at all, or by default.

quoted

This would also allow the settings to get this information in the
first
place, otherwise we'd need to have some side-channel to funnel that
information from the "desktop-wide" agent to the settings agent.

I've made the upstream bug[1] public now, can you reference it in
the
commit message?

Sure.

quoted

Cheers

[1]: https://gitlab.gnome.org/GNOME/gnome-bluetooth/-/issues/91