| Message ID | 20211111195423.Bluez.3.I29367ca288fc8f4fcc3b4063425b791501c6534c@changeid (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [Bluez,1/3] Listen and process remote name resolving failure | expand |
| Context | Check | Description |
|---|---|---|
| tedd_an/checkpatch | success | Checkpatch PASS |
| tedd_an/gitlint | success | Gitlint PASS |
Hi Archie, > Userspace should use this new flag to decide whether to do the remote > name resolving or not, by sending Confirm Name MGMT command and set > the appropriate flag. > > This patch also extends the Confirm Name command by allowing userspace > to send 0x02 to show it doesn't care about the peer devices names. > --- > > doc/mgmt-api.txt | 18 +++++++++++++----- > 1 file changed, 13 insertions(+), 5 deletions(-) > > diff --git a/doc/mgmt-api.txt b/doc/mgmt-api.txt > index 97d33e30a1..e4c8de39f0 100644 > --- a/doc/mgmt-api.txt > +++ b/doc/mgmt-api.txt > @@ -1493,7 +1493,7 @@ Confirm Name Command > Controller Index: <controller id> > Command Parameters: Address (6 Octets) > Address_Type (1 Octet) > - Name_Known (1 Octet) > + Name_State (1 Octet) > Return Parameters: Address (6 Octets) > Address_Type (1 Octet) > > @@ -1506,10 +1506,11 @@ Confirm Name Command > 1 LE Public > 2 LE Random > > - The Name_Known parameter should be set to 0x01 if user space > - knows the name for the device and 0x00 if it doesn't. If set to > - 0x00 the kernel will perform a name resolving procedure for the > - device in question. > + The Name_State parameter should be set to 0x00 if user space > + doesn't know the name for the device to make the kernel > + perform a name resolving procedure for the device in question. > + Otherwise, set to 0x01 if user space already knew the device's > + name, or 0x02 if it doesn't care. I am a bit worried about userspace sending a 0x02 for a kernel that doesn’t understand it. Do you think the kernel can make use of this “don’t care” information? Or should we just keep it to userspace to send 0x01 / 0x00 based on its policy. > > This command can only be used when the controller is powered. > > @@ -4089,6 +4090,7 @@ Device Connected Event > 1 Legacy Pairing > 2 Reserved (not in use) > 3 Initiated Connection > + 4 Reserved (not in use) > > > Device Disconnected Event > @@ -4263,6 +4265,7 @@ Device Found Event > 1 Legacy Pairing > 2 Not Connectable > 3 Reserved (not in use) > + 4 Name Resolve Fail I would do “Name Request Failed” here. Just to be a bit inline what the spec term is. > > For the RSSI field a value of 127 indicates that the RSSI is > not available. That can happen with Bluetooth 1.1 and earlier > @@ -4285,6 +4288,11 @@ Device Found Event > accept any connections. This can be indicated by Low Energy > devices that are in broadcaster role. > > + The Name Resolve Fail flag indicates that name resolving > + procedure has ended with failure for this device. The user space > + should use this information to determine when is a good time to > + retry the name resolving procedure. > + > Regards Marcel
Hi Marcel, On Fri, 12 Nov 2021 at 00:35, Marcel Holtmann <marcel@holtmann.org> wrote: > > Hi Archie, > > > Userspace should use this new flag to decide whether to do the remote > > name resolving or not, by sending Confirm Name MGMT command and set > > the appropriate flag. > > > > This patch also extends the Confirm Name command by allowing userspace > > to send 0x02 to show it doesn't care about the peer devices names. > > --- > > > > doc/mgmt-api.txt | 18 +++++++++++++----- > > 1 file changed, 13 insertions(+), 5 deletions(-) > > > > diff --git a/doc/mgmt-api.txt b/doc/mgmt-api.txt > > index 97d33e30a1..e4c8de39f0 100644 > > --- a/doc/mgmt-api.txt > > +++ b/doc/mgmt-api.txt > > @@ -1493,7 +1493,7 @@ Confirm Name Command > > Controller Index: <controller id> > > Command Parameters: Address (6 Octets) > > Address_Type (1 Octet) > > - Name_Known (1 Octet) > > + Name_State (1 Octet) > > Return Parameters: Address (6 Octets) > > Address_Type (1 Octet) > > > > @@ -1506,10 +1506,11 @@ Confirm Name Command > > 1 LE Public > > 2 LE Random > > > > - The Name_Known parameter should be set to 0x01 if user space > > - knows the name for the device and 0x00 if it doesn't. If set to > > - 0x00 the kernel will perform a name resolving procedure for the > > - device in question. > > + The Name_State parameter should be set to 0x00 if user space > > + doesn't know the name for the device to make the kernel > > + perform a name resolving procedure for the device in question. > > + Otherwise, set to 0x01 if user space already knew the device's > > + name, or 0x02 if it doesn't care. > > I am a bit worried about userspace sending a 0x02 for a kernel that doesn’t understand it. Do you think the kernel can make use of this “don’t care” information? Or should we just keep it to userspace to send 0x01 / 0x00 based on its policy. > On the current kernel, 0x02 would be casted to True, and the kernel would treat this as "name is known". Indeed, this "don't care" information is of no use to the Kernel (at least for now). If this is concerning, I'd propose to just express the "don't care" by not sending a Confirm Name command in the first place, similar to what we do when we receive a Device Found event for a device which is already discovered before. > > > > This command can only be used when the controller is powered. > > > > @@ -4089,6 +4090,7 @@ Device Connected Event > > 1 Legacy Pairing > > 2 Reserved (not in use) > > 3 Initiated Connection > > + 4 Reserved (not in use) > > > > > > Device Disconnected Event > > @@ -4263,6 +4265,7 @@ Device Found Event > > 1 Legacy Pairing > > 2 Not Connectable > > 3 Reserved (not in use) > > + 4 Name Resolve Fail > > I would do “Name Request Failed” here. Just to be a bit inline what the spec term is. > Ack, will update. > > > > For the RSSI field a value of 127 indicates that the RSSI is > > not available. That can happen with Bluetooth 1.1 and earlier > > @@ -4285,6 +4288,11 @@ Device Found Event > > accept any connections. This can be indicated by Low Energy > > devices that are in broadcaster role. > > > > + The Name Resolve Fail flag indicates that name resolving > > + procedure has ended with failure for this device. The user space > > + should use this information to determine when is a good time to > > + retry the name resolving procedure. > > + > > > > Regards > > Marcel > Thanks, Archie
diff --git a/doc/mgmt-api.txt b/doc/mgmt-api.txt index 97d33e30a1..e4c8de39f0 100644 --- a/doc/mgmt-api.txt +++ b/doc/mgmt-api.txt @@ -1493,7 +1493,7 @@ Confirm Name Command Controller Index: <controller id> Command Parameters: Address (6 Octets) Address_Type (1 Octet) - Name_Known (1 Octet) + Name_State (1 Octet) Return Parameters: Address (6 Octets) Address_Type (1 Octet) @@ -1506,10 +1506,11 @@ Confirm Name Command 1 LE Public 2 LE Random - The Name_Known parameter should be set to 0x01 if user space - knows the name for the device and 0x00 if it doesn't. If set to - 0x00 the kernel will perform a name resolving procedure for the - device in question. + The Name_State parameter should be set to 0x00 if user space + doesn't know the name for the device to make the kernel + perform a name resolving procedure for the device in question. + Otherwise, set to 0x01 if user space already knew the device's + name, or 0x02 if it doesn't care. This command can only be used when the controller is powered. @@ -4089,6 +4090,7 @@ Device Connected Event 1 Legacy Pairing 2 Reserved (not in use) 3 Initiated Connection + 4 Reserved (not in use) Device Disconnected Event @@ -4263,6 +4265,7 @@ Device Found Event 1 Legacy Pairing 2 Not Connectable 3 Reserved (not in use) + 4 Name Resolve Fail For the RSSI field a value of 127 indicates that the RSSI is not available. That can happen with Bluetooth 1.1 and earlier @@ -4285,6 +4288,11 @@ Device Found Event accept any connections. This can be indicated by Low Energy devices that are in broadcaster role. + The Name Resolve Fail flag indicates that name resolving + procedure has ended with failure for this device. The user space + should use this information to determine when is a good time to + retry the name resolving procedure. + Discovering Event =================
From: Archie Pusaka <apusaka@chromium.org> Userspace should use this new flag to decide whether to do the remote name resolving or not, by sending Confirm Name MGMT command and set the appropriate flag. This patch also extends the Confirm Name command by allowing userspace to send 0x02 to show it doesn't care about the peer devices names. --- doc/mgmt-api.txt | 18 +++++++++++++----- 1 file changed, 13 insertions(+), 5 deletions(-)