| Message ID | 20210623184355.3685859-1-luiz.dentz@gmail.com |
|---|---|
| State | New |
| Headers | show |
| Series | [BlueZ] doc/agent-api: Add AuthenticationFailed method | expand |
Hi Luiz, > 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. you are forgetting to describe what status is for. Also if we follow the language from the previous agent method, then this should be IndicateAuthenticationFailure. I know it is a mouthful, but we always phrased the method names as action or information targeting a user or UI to do something. Regards Marcel
On Wed, 2021-06-23 at 11:43 -0700, Luiz Augusto von Dentz wrote: > From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> > > 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. 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? Cheers [1]: https://gitlab.gnome.org/GNOME/gnome-bluetooth/-/issues/91
Hi Bastien, On Mon, Jun 28, 2021 at 7:59 AM Bastien Nocera <hadess@hadess.net> wrote: > > On Wed, 2021-06-23 at 11:43 -0700, Luiz Augusto von Dentz wrote: > > From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> > > > > 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. 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 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. > Cheers > > [1]: https://gitlab.gnome.org/GNOME/gnome-bluetooth/-/issues/91 > -- Luiz Augusto von Dentz
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 <hadess@hadess.net> > wrote: > > > > On Wed, 2021-06-23 at 11:43 -0700, Luiz Augusto von Dentz wrote: > > > From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> > > > > > > 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. > > > 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. > > > Cheers > > > > [1]: https://gitlab.gnome.org/GNOME/gnome-bluetooth/-/issues/91 > > > >
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.
From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> 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(+)