there are many posts regarding security, pairing and bonding, but I did not find an answer to my problem yet.
I want to bond a BT121 (BLE master) with a BGM123 (BLE slave), using on both devices the NCP mode (BG-API)
I need to use Just works method, since both devices are noInput/noOutput. Both devices shall be fixed assigned to each other and so I want to bond them once.
To do so, I allow bonding nn both devices with cmd_sm_set_bondable_mode(1) at startup. I also configure the SM with the I/O capabilities noInput/noOutput, and no MITM.To initiate pairing/bonding I used the command sm_increase_security. I tried this on master side as well as alternatively on slave side after connecction_opened_evt (and also alternatively at other times).
I get an additional le_connection_parameter event (with security mode = 1) and a sm_bonded event, on BGM123 with a vaild bonding handle (0) as expected but on BT121 side with a bonding handle (0xff), indicating pairing, but not bonding.
I also traced out the bonding list at startup, there is no entry at BT121. (Note that I get entries there when BT121 is slave at a classic bluetooth connection).
Any idea what to do?
Have you tried calling that command only after le_connection_parameters event?
first I tried (only) after the le_connection_opened event. There is an effect, which can be seen by the le_connection_parameters event (with increased security mode) and later on the bonding_event.
But the bonding handle is 0xff. On a community thread I found, that this indicates only a pairing has been done (with STK). Afterwards I can read GATT characteristics with encryption=true, but not with authentication = true (as expected).
I also tried to "increase_security" after the first le_connection_parameters event, or after first access to an "protected" GATT characteristic with reading error, or a second time. I also tried on slave instead. Always the same result.
In the meanwhile I even tried to get a authenticated connection (not just works) with same result.
I assume the command sm_set_bondable_mode(1) is for classic and LE connection isn't it. Or is there any global configuration I missed?
You need to set bondable mode on both sides yes, it's not just for classic. That needs to be done on both devices prior to any bonding attempts.
I already did set bonding mode on both sides (i.e. on BT121 and BGM123, BLE connection).
In the meanwhile I tested this scenario on the evaluation kits (Blue Gecko Module Wireless Starter Kit and DKBT Blue Giga BT121 kit).
Using BG-TOOL I configured Set Bondable Mode (using Security Manager Tab) on both devices.
Then I discover on BT121 and Advertise on BGM123. The BGM123 device was found, I stopped scanning and opened the connection. (No configuration on classic mode for BT121).
The I pushed "Increase Security" tab on BT121.
-> BGM123: Creating a bond (index 0), which can be seen by the events and also when refreshing the bonded device list (on Security Manager Tab).
-> BT121: Pairing but not creating a bond, bonding handle in bonding event = 0xff; no entry on the bonded devices list.
Note 1:Closing the connection and reconnect works without security, but trying to increase security now fails (till bonded device is deleted in BGM123). No wonder when not bonded at BT121.
Note 2: Having BGM123 as master and BT121 as slave gives the same result (no bonding on BT121)
Note 3: Copied from bluegiga API reference, regarding "cmd_sm_increase_security":
"For Bluetooth LE connections, this command initiates encryption, as there are only two levels of security: unencrypted and encrypted. If the devices are bonded, the existing bonding will be used. If the devices are not bonded, a new key will be created; if bonding is enabled the key will be stored for future use, if not the key will be discarded after the connection is closed."
The latter one "the key will be stored for future use" is not done. I guess "if bonding is enabled" that's the bondable mode setting, isn't it?
I just tried it and it works. I used NCP firmware on both (built with the latest stack versions for each device) and controlled them via BGTool.
Here's the log for BGM:
13:10:01,0216 1 gecko_cmd_sm_increase_security connection: 5 (0x05)
13:10:01,0257 4 gecko_rsp_sm_increase_security result:0x0000 'Command completed succesfully'
13:10:04,0682 0 gecko_evt_le_connection_parameters connection: 5 (0x05) interval: 200 (0x00c8) latency: 0 (0x0000) timeout: 100 (0x0064) security_mode: 1 (0x01) txsize: 27 (0x001b)
13:10:05,0514 0 gecko_evt_sm_bonded connection: 5 (0x05) bonding: 0 (0x00)
And for BT121:
13:10:05,0702 0 dumo_evt_sm_bonded connection: 72 (0x48) bonding: 1 (0x01)
So the only issue that I can see on your side is that you probably don't have the latest SDK version on the BT121 side?
I get the same trace for BGM123, but not for BT121:
dumo_evt_le_connection_parameters connection: 2 (0x02) interval: 200 (0x00c8) latency: 0 (0x0000) timeout: 100 (0x0064) security_mode: 1 (0x01) address:00:0b:57:25:b5:dd
dumo_evt_sm_bonded connection: 2 (0x02) bonding: 255 (0xff)
Regarding my development environment:
For BT121 I use (latest) Bluetooth Smart Ready SDK V.1.1.2-184. I build with BG-TOOL (Upload Tool).
See the attached zip file with the build directory including the image and the build output. The used example is from this SDK (...\SiliconLabs\Bluegiga\smart ready-1.1.2-184\example\bt121).
Is there a newer SDK?
Can you please try my image, to know that the issue is due to this BT121 image.
What about on the BGM side, are you using SDK 2.4.1?
I used the SDK 2.3.1-2044 for BGM123.
I'm have the devices in a medical project, so updating SW version has to be documented and such always causes effort.
But I tried with latest SDK 2.4.1 sample project load on eval kit and now BT121 created a bond as expected! so its either a configuration issues on my current build or it's really the stack version that causes the misbehavior.
I wonder, that the newest version BG-TOOL (of SDK 2.4.1) misses the Upload Tool menu. Up to now I used this to build the module image, based only on .bgproj and other xml files (hardware, gatt, ...). Has this feature been removed? Is there another possibility to build without a Simplicity IDE project (e.g. bgbuild...)?
Thank you very much.
Bgbuild and bgscript have been removed on the latest SDK. They had been already marked as deprecated in SDK 2.3.
To build an NCP image you need to use Simplicity IDE but there is also a pre-compiled NCP example that you can just flash to the WSTK. If you need to make modifications to this (additional GATT services or a different UART location) then you need to change the C example.
indeed the latest Release Notes state that BG-Script is removed from tooling. Why? Were there no (or too less) users for this feature?
On the other hand, I found the statement "BGTool and bgbuild tools updated" in the section Quality Improvements. Further on the bgbuild tool is still in the bin directory of the SDK. What does that mean?
To be confident, I want to ask once more if there is still a way to use the .xml (hardware.xml) and project file (.bgproj) to configure UART, Sleep and DFU bootloader, or must I configure via Simplicity studio with #defines in .h/.c files, and the HwConfigurator tool? (The GATT graphical tool I already used to create the gatt.xml files.)
Previously a last question: Are there any plans to skip the NCP mode in future releases?
Thanks again, regards
Yes they were updated, bgbuild is now only used to generate the gatt_db.c/.h from the gatt.xml file if you're using IAR. If you're using studio IDE the VGE (Visual Gatt Editor) will generate gatt_db.c/.h directly without calling bgbuild.
Why were they removed? Well, that's a question you need to put to our marketing department.
There is no way to use hardware.xml to generate a firmware for the module, you must use studio.
I don't think NCP can't be skipped as such, it's essentially just a firmware configuration.