LE based Remote Name Request
LE does not have a Remote Name Request like BR/EDR has. It does have the ability to fairly efficiently request the remote device name, however, which we should implement. Currently the only support we offer for obtaining the remote device name is to pluck it out of the Advertising packets (Formatted identically to EIR) which works for most devices, but as with BR/EDR, there is no requirement that devices include their name in their advertising data.
The Device Name characteristic is Mandatory, and may only exist once for a device. If it is less than 20 bytes may therefore be read with a single ReadByType GATT command (uuid16: 0x2a00) over the full 1-0xFFFF range. It must also be readable without security, so can be done without first going through SMP.
We may not want to featurize this particular functionality at all, since all of the components to obtain this info is already available: We just need to set up an ATT socket in BlueZ, and make the request. However, when we talk about Scanning for devices, and automatically forwarding the Remote Name via a MGMT evevnt, the precedence is there to supply it from the kernel. And if we were to go down that path, we would also want to simultaneously offer access to the equally Mandatory and Unsecured "Appearance" Characteristic (uuid16: 0x2a01) which is LE's sort-of equivilent to the BR/EDR Class-Of-Device.
So: What are the feelings about doing Remote Name (And Appearance) discovery in the kernel, probably as part of the LE Discovery mechanism?
I favor putting it in the kernel, due to the equivalent functionality
available to BR/EDR there.
Also, there is no coincidence that I offer this RFC at the same time as I bring up the Write Signed Command functionality from earlier today. Both concern usages of GATT (or at least ATT) in a way not currently supported. It is also a case where ideally, we would use a low-latency connect-read-disconnect methodology.
Signature · 4 lines
Brian Gix [email protected] Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
Hi Brian,
Quoted 26 lines · Brian Gix
LE does not have a Remote Name Request like BR/EDR has. It does have the ability to fairly efficiently request the remote device name, however, which we should implement. Currently the only support we offer for obtaining the remote device name is to pluck it out of the Advertising packets (Formatted identically to EIR) which works for most devices, but as with BR/EDR, there is no requirement that devices include their name in their advertising data.
The Device Name characteristic is Mandatory, and may only exist once for a device. If it is less than 20 bytes may therefore be read with a single ReadByType GATT command (uuid16:
0x2a00) over the full 1-0xFFFF range. It must also be readable without security, so can be done without first going through SMP.We may not want to featurize this particular functionality at all, since all of the components to obtain this info is already
available: We just need to set up an ATT socket in BlueZ, and make the request. However, when we talk about Scanning for devices, and automatically forwarding the Remote Name via a MGMT evevnt, the precedence is there to supply it from the kernel. And if we were to go down that path, we would also want to simultaneously offer access to the equally Mandatory and Unsecured "Appearance" Characteristic (uuid16:0x2a01) which is LE's sort-of equivilent to the BR/EDR Class-Of-Device.
Quoted 4 lines
So: What are the feelings about doing Remote Name (And Appearance) discovery in the kernel, probably as part of the LE Discovery mechanism? I favor putting it in the kernel, due to the equivalent functionality available to BR/EDR there.
I am in favor of this, more because of the Appearance than the Name discovery. The Name most well behaved devices will provide through the Advertising Data, Appearance we can only discover via GATT and it is very useful for the user.
Quoted 16 lines
Also, there is no coincidence that I offer this RFC at the same time as I bring up the Write Signed Command functionality from earlier today. Both concern usages of GATT (or at least ATT) in a way not currently supported. It is also a case where ideally, we would use a low-latency connect-read-disconnect methodology.
Signature · 8 lines
Brian Gix [email protected] Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Cheers,
Signature · 1 line
Vinicius
Brian, Vinicius,
Quoted 57 lines · Vinicius Costa Gomes
Hi Brian,
Quoted 26 lines · Brian Gix
LE does not have a Remote Name Request like BR/EDR has. It does have the ability to fairly efficiently request the remote device name, however, which we should implement. Currently the only support we offer for obtaining the remote device name is to pluck it out of the Advertising packets (Formatted identically to EIR) which works for most devices, but as with BR/EDR, there is no requirement that devices include their name in their advertising data.
The Device Name characteristic is Mandatory, and may only exist once for a device. If it is less than 20 bytes may therefore be read with a single ReadByType GATT command (uuid16:
0x2a00) over the full 1-0xFFFF range. It must also be readable without security, so can be done without first going through SMP.We may not want to featurize this particular functionality at all, since all of the components to obtain this info is already
available: We just need to set up an ATT socket in BlueZ, and make the request. However, when we talk about Scanning for devices, and automatically forwarding the Remote Name via a MGMT evevnt, the precedence is there to supply it from the kernel. And if we were to go down that path, we would also want to simultaneously offer access to the equally Mandatory and Unsecured "Appearance" Characteristic (uuid16:0x2a01) which is LE's sort-of equivilent to the BR/EDR Class-Of-Device.Quoted 4 lines
So: What are the feelings about doing Remote Name (And Appearance) discovery in the kernel, probably as part of the LE Discovery mechanism? I favor putting it in the kernel, due to the equivalent functionality available to BR/EDR there.
I am in favor of this, more because of the Appearance than the Name discovery. The Name most well behaved devices will provide through the Advertising Data, Appearance we can only discover via GATT and it is very useful for the user.
Quoted 7 lines
Also, there is no coincidence that I offer this RFC at the same time as I bring up the Write Signed Command functionality from earlier today. Both concern usages of GATT (or at least ATT) in a way not currently supported. It is also a case where ideally, we would use a low-latency connect-read-disconnect methodology.
Quoted 9 lines
--
Brian Gix
[email protected]
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum --
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 8 lines
Cheers,
--
Vinicius
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
I really do not think this is a good idea. Forcing a connection while scanning for devices is not a good idea for LE devices, which may require a push button or some other user intervention to get discoverable/connectable. Trying to connect to it while scanning may cause it to stop being discoverable/connectable (if the device does not become discoverable after disconnection), which will result in the device either becoming non connectable, or require the user to press the button again, which is making things more difficult and complicated. I would suggest relying on the advertising data, and get the remote name, or every other GAP related GATT characteristics once a connection is established for the purpose it was supposed to be.
Best regards,
Chen Ganir
Hi Brian/Vinicius,
Quoted 34 lines · Vinicius Costa Gomes
Hi Brian,
Quoted 26 lines · Brian Gix
LE does not have a Remote Name Request like BR/EDR has. It does have the ability to fairly efficiently request the remote device name, however, which we should implement. Currently the only support we offer for obtaining the remote device name is to pluck it out of the Advertising packets (Formatted identically to EIR) which works for most devices, but as with BR/EDR, there is no requirement that devices include their name in their advertising data.
The Device Name characteristic is Mandatory, and may only exist once for a device. If it is less than 20 bytes may therefore be read with a single ReadByType GATT command (uuid16:
0x2a00) over the full 1-0xFFFF range. It must also be readable without security, so can be done without first going through SMP.We may not want to featurize this particular functionality at all, since all of the components to obtain this info is already
available: We just need to set up an ATT socket in BlueZ, and make the request. However, when we talk about Scanning for devices, and automatically forwarding the Remote Name via a MGMT evevnt, the precedence is there to supply it from the kernel. And if we were to go down that path, we would also want to simultaneously offer access to the equally Mandatory and Unsecured "Appearance" Characteristic (uuid16:0x2a01) which is LE's sort-of equivilent to the BR/EDR Class-Of-Device.Quoted 4 lines
So: What are the feelings about doing Remote Name (And Appearance) discovery in the kernel, probably as part of the LE Discovery mechanism? I favor putting it in the kernel, due to the equivalent functionality available to BR/EDR there.
Quoted 4 lines
I am in favor of this, more because of the Appearance than the Name discovery. The Name most well behaved devices will provide through the Advertising Data, Appearance we can only discover via GATT and it is very useful for the user.
IMO, the first attempt needs to be in the userspace. Name, Appearance and *ServiceChanged* can be read on every reconnection. Appearance will be exposed though adv data also, it is being discussed by the BT SIG.
If we implement the characteristic storage properly, I don't think we need to read the Name and Appearance always since it will not change.
Another aspect against do it in the kernel as part of the discovery procedure is "connectable and bondable mode", probably we will have problems to re-connect. Peripherals may leave the bondable mode or doesn't send advertises automatically after disconnection.
BR,
Claudio
Quoted 22 lines
Quoted 8 lines
Also, there is no coincidence that I offer this RFC at the same time as I bring up the Write Signed Command functionality from earlier today. Both concern usages of GATT (or at least ATT) in a way not currently supported. It is also a case where ideally, we would use a low-latency connect-read-disconnect methodology.
Quoted 9 lines
--
Brian Gix
[email protected]
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum --
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.htmlCheers,
--
Vinicius
Hi Chen, Claudio,
Quoted 47 lines · Claudio Takahasi
Hi Brian/Vinicius,
Quoted 34 lines · Vinicius Costa Gomes
Hi Brian,
Quoted 26 lines · Brian Gix
LE does not have a Remote Name Request like BR/EDR has. It does have the ability to fairly efficiently request the remote device name, however, which we should implement. Currently the only support we offer for obtaining the remote device name is to pluck it out of the Advertising packets (Formatted identically to EIR) which works for most devices, but as with BR/EDR, there is no requirement that devices include their name in their advertising data.
The Device Name characteristic is Mandatory, and may only exist once for a device. If it is less than 20 bytes may therefore be read with a single ReadByType GATT command (uuid16:
0x2a00) over the full 1-0xFFFF range. It must also be readable without security, so can be done without first going through SMP.We may not want to featurize this particular functionality at all, since all of the components to obtain this info is already
available: We just need to set up an ATT socket in BlueZ, and make the request. However, when we talk about Scanning for devices, and automatically forwarding the Remote Name via a MGMT evevnt, the precedence is there to supply it from the kernel. And if we were to go down that path, we would also want to simultaneously offer access to the equally Mandatory and Unsecured "Appearance" Characteristic (uuid16:0x2a01) which is LE's sort-of equivilent to the BR/EDR Class-Of-Device.Quoted 4 lines
So: What are the feelings about doing Remote Name (And Appearance) discovery in the kernel, probably as part of the LE Discovery mechanism? I favor putting it in the kernel, due to the equivalent functionality available to BR/EDR there.
Quoted 4 lines
I am in favor of this, more because of the Appearance than the Name discovery. The Name most well behaved devices will provide through the Advertising Data, Appearance we can only discover via GATT and it is very useful for the user.
IMO, the first attempt needs to be in the userspace. Name, Appearance and *ServiceChanged* can be read on every reconnection. Appearance will be exposed though adv data also, it is being discussed by the BT SIG.
Quoted 7 lines
If we implement the characteristic storage properly, I don't think we need to read the Name and Appearance always since it will not change.
Another aspect against do it in the kernel as part of the discovery procedure is "connectable and bondable mode", probably we will have problems to re-connect. Peripherals may leave the bondable mode or doesn't send advertises automatically after disconnection.
Those are otherwise good points (not all devices will automatically start advertising again) however ServiceChanged should never be attempted to be read. We should only obtain this via an Indication from the remote device, and at any rate it is only shared with Trusted devices, so we would have to be Bonded.
However, I would definitely NOT try to re-read Name/Appearance at every connection. Those should definitely be cached, and not re-read unless we get the ServiceChanged Indication.
Does anyone object to permanently deciding to NOT do Remote Name/Appearance request at device discovery time? Or in the kernel at all? Particularly if the SIG is heading towards exposing the Appearance in Advertising data, this whole thing becomes nearly moot. I agree with Chen and Claudio that attempting this at Discovery will likely cause the rare IOP problem, and the only drawback to Not doing it would be the rare BD Addr and no Appearance shown during scanning.
Signature · 4 lines
Brian Gix [email protected] Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
Quoted 66 lines · Brian Gix
Hi Chen, Claudio,
Quoted 49 lines · Claudio Takahasi
Hi Brian/Vinicius,
Quoted 35 lines · Vinicius Costa Gomes
Hi Brian,
Quoted 26 lines · Brian Gix
LE does not have a Remote Name Request like BR/EDR has. It does have the ability to fairly efficiently request the remote device name, however, which we should implement. Currently the only support we offer for obtaining the remote device name is to pluck it out of the Advertising packets (Formatted identically to EIR) which works for most devices, but as with BR/EDR, there is no requirement that devices include their name in their advertising data.
The Device Name characteristic is Mandatory, and may only exist once for a device. If it is less than 20 bytes may therefore be read with a single ReadByType GATT command (uuid16:
0x2a00) over the full 1-0xFFFF range. It must also be readable without security, so can be done without first going through SMP.We may not want to featurize this particular functionality at all, since all of the components to obtain this info is already
available: We just need to set up an ATT socket in BlueZ, and make the request. However, when we talk about Scanning for devices, and automatically forwarding the Remote Name via a MGMT evevnt, the precedence is there to supply it from the kernel. And if we were to go down that path, we would also want to simultaneously offer access to the equally Mandatory and Unsecured "Appearance" Characteristic (uuid16:0x2a01) which is LE's sort-of equivilent to the BR/EDR Class-Of-Device.Quoted 4 lines
So: What are the feelings about doing Remote Name (And Appearance) discovery in the kernel, probably as part of the LE Discovery mechanism? I favor putting it in the kernel, due to the equivalent functionality available to BR/EDR there.
Quoted 4 lines
I am in favor of this, more because of the Appearance than the Name discovery. The Name most well behaved devices will provide through the Advertising Data, Appearance we can only discover via GATT and it is very useful for the user.
IMO, the first attempt needs to be in the userspace. Name, Appearance and *ServiceChanged* can be read on every reconnection. Appearance will be exposed though adv data also, it is being discussed by the BT SIG.
Quoted 7 lines
If we implement the characteristic storage properly, I don't think we need to read the Name and Appearance always since it will not change.
Another aspect against do it in the kernel as part of the discovery procedure is "connectable and bondable mode", probably we will have problems to re-connect. Peripherals may leave the bondable mode or doesn't send advertises automatically after disconnection.
Those are otherwise good points (not all devices will automatically start advertising again) however ServiceChanged should never be attempted to be read. We should only obtain this via an Indication from the remote device, and at any rate it is only shared with Trusted devices, so we would have to be Bonded.
Quoted 4 lines
However, I would definitely NOT try to re-read Name/Appearance at every connection. Those should definitely be cached, and not re-read unless we get the ServiceChanged Indication.
ServiceChanged is irrelevant here. ServiceChanged will only notify you if the handles changed, not if the value changed. Name and appearance can and should be read, since we may get only the short name in the advertising data, and we wil need the full name. In addition, a device may change its name, and we will not be notified of this (GAP name characteristic does not notify/indicate). Name may change just like it does in BR/EDR.
Quoted 8 lines
Does anyone object to permanently deciding to NOT do Remote Name/Appearance request at device discovery time? Or in the kernel at all? Particularly if the SIG is heading towards exposing the Appearance in Advertising data, this whole thing becomes nearly moot. I agree with Chen and Claudio that attempting this at Discovery will likely cause the rare IOP problem, and the only drawback to Not doing it would be the rare BD Addr and no Appearance shown during scanning.
Quoted 11 lines
--
Brian Gix
[email protected]
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum --
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Chen Ganir
[email protected]
Hi Chen,
Quoted 11 lines · Chen Ganir
Quoted 10 lines · Brian Gix
Those are otherwise good points (not all devices will automatically start advertising again) however ServiceChanged should never be attempted to be read. We should only obtain this via an Indication from the remote device, and at any rate it is only shared with Trusted devices, so we would have to be Bonded.
However, I would definitely NOT try to re-read Name/Appearance at every connection. Those should definitely be cached, and not re-read unless we get the ServiceChanged Indication.
Quoted 7 lines
ServiceChanged is irrelevant here. ServiceChanged will only notify you if the handles changed, not if the value changed. Name and appearance can and should be read, since we may get only the short name in the advertising data, and we wil need the full name. In addition, a device may change its name, and we will not be notified of this (GAP name characteristic does not notify/indicate). Name may change just like it does in BR/EDR.
I don't think we should do anything automatically on start-up.
If we know that we do not have the full name (if the Adv data has it flagged as "Partial") then we should of course fetch the full name from the characteristic. However, if we get in the habit of re-reading data just because it *may* have changed, then we lose track of what LE is all about, which is minimization of over-the-air traffic.
If a particular high level app wants refresh the Name and/or Appearance, then of course which should provide that ability, but I might consider that App to be poorly written barring a compelling need, like perhaps an indication that it needs to be re-paired. Single mode LE devices will generally be single mode because they want to limit these unneeded transactions. LE Profiles are designed to not require Polling type activities, which a Name or Appearance refresh would be.
Signature · 4 lines
Brian Gix [email protected] Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum