To enable the Bluetooth communication on your wider Digi XBee network you would need to send remote AT command frames to set the BT (Bluetooth Enable) parameter.
You can then send the Salt and Verifier values that allow secure communication between each XBee module and a Bluetooth device. The security protocol used in the Bluetooth communication is SRP (Secure Remote Password). https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol
The password used in the XCTU program is to generate the salt and verifier values. This password is not a parameter that is readable nor is it sent over the air by the modules. The password also is not a value that can be set or queried with an AT command. It is only entered in the XCTU to generate and write the salt and verifier values. The salt and verifier are the values that are used to secure communication.
Below is an example of the commands used to set the Salt and verifier values on a remote radio. The Salt and verifier values were generated using the XCTU tool under the Bluetooth Options feature. The Salt and verifier values will generate differently even when the same password is used to create them. However, different Salt and verifier values will allow communication if they were generated from the same password. Radios with Salt and verifiers generated from the same password will communicate with each other even though the Salt and verifier values may be different on each radio.
Because of the over the air packet size limitation in Zigbee, the verifier value has to be broken up into 4 API frames with 4 separate remote AT commands.
In this example, the API frames were generated and sent from an Digi S2C module to an XBee3 module.
To send these remote AT command API frames from a proprietary gateway, would require that you generate the API frame from your application and send them to the UART of the transmitting radio. At the and of this page is a log of the API frames that reflect the steps below.
- Enable BlueTooth by setting the BT parameter on the remote radio to 1
- Write the BT setting WR
- Apply changes AC
- Send the Salt value $S
- Send first verifier $V
- Send second verifier $W
- Send third verifier $X
- Send fourth verifier $Y
- Write the changes WR
- Apply changes AC
The salt and verifier can be generated from the password that you put into the XCTU. You then put them into your API frame and assign the salt and verifiers to your remote radio(s).
In the Bluetooth operation the flowing is true:
* The same password will not generate the same Salt and Verifier twice
* Salt and Verifiers cannot be reverse engineered to generate or derive a password.
* Never can a password be transmitted over the air
* Salt and Verifiers can be transmitted over the air.
* Salt and Verifiers can be read remotely over the air.
*All radios on your network can have the same Salt and Verifiers.
*The Salt and Verifiers are not the actual values that get transmitted over the air in a Bluetooth communication exchange.
Example log of API frames :
Jan 15, 2020