Yes, I know that the SDK 2.0.1 included the security feature what I need, but it does not include the 20732 platform, and unfortunately our Beacon device has already in production on that platform, and therefore I have to work on the SDK 1.1.0.
You can try to use the code from 2.0/2.1 and there is a chance it will work on 1.1. By the way. Maybe if it is a Beacon, maybe you do not need to support connections from other devices at all. That would be most secure way to operate :-).
It’s really good to hearing from you, would please share the chance more detail how to merge a library and header files from 2.0/2.1 SDK.
And please note that the Beacon is required to the connection in order to setup some of parameters such as advertising period, Tx output power and so on.
1 of 1 people found this helpful
I meant that you can just copy an application directory from 2.x SDK to 1.1 SDK, change the makefile based on other samples and try to build it. Please note that it is not guaranteed to work in all cases because there is a lot of new functionality, but you might be lucky.
I understand now why you need a connection and why you want passkey pairing. I know some applications force user to push a button on the sensor and only allow connection while button is pushed.
I enabled PASSKEY_PAIRING define and I checked that pin-query window was poped up on smartphone
I know that SMP timeout is expired after 30 sec.
Let me know how to adjust SMP timeout value.
And I wonder if BT(20732) can be known that Cancel button is pressed on pin-query windows on smartphone.
1 of 1 people found this helpful
SMP timeout is not adjustable because it is required by the Bluetooth spec. There is no SMP message to indicate to the other side which button is pushed. I assume that reasonable implementation would drop the connection if user cancels pairing popup.
However in order to prevent any intentional access cause, would you please let me know any idea for that circumstance as when user press the Cancel button and then the connection is established without SMP layer.
Are you worried about application having access to your data without encryption. The simple protection is to add
LEGATTDB_PERM_AUTH_READABLE or LEGATTDB_PERM_AUTH_WRITABLE permissions to your characteristics. In that case the stack will reject any attempt to read/write before encryption is set. You can register to receive notification when link becomes encrypted, and you can verify if the link is encrypted using emconninfo_linkEncrypted function call. Before sending any data out.
I have a problem which i can read characteristic value after bt device is boned with smp
1. I modfied permission of gatt database (from LEGATTDB_READABLE to LEGATTDB_PERM_AUTH_READABLE)
// Handle 0x62: characteristic Battery Level, handle 0x63 characteristic value
CHARACTERISTIC_UUID16 (0x0062, 0x0063, UUID_CHARACTERISTIC_BATTERY_LEVEL,
2. It has boned with smp (log)
hello_sensor_connection_up: ccfa0077ff5b 64
hello_sample, encryption changed 00 00 00 00 00
EncOn ccfa0077ff5b client_configuration:0000 blinks:0
hello_sample, bond result 030 00 00 00 00 00 00
3. Although it has boned , I can't verify Battery Level
would plz let me why i can't read Battery Level
and how to use emconninfo_linkEncrypted.
I do not believe basic security does not work with 1.1(although it was too long ago). I suspect you need to or permissions Readable and Auth Readable. You can try to add following 2 lines in the Create function to see more traces.
extern UINT32 blecm_configFlag ;
blecm_configFlag |= BLECM_DBGUART_LOG | BLECM_DBGUART_LOG_L2CAP | BLECM_DBGUART_LOG_SMP;
I am also having trouble getting LEGATTDB_PERM_AUTH_READABLE to work properly.
If just LEGATTDB_PERM_READABLE is set, the client can read the 8 byte
value set in the GATT DB.
If LEGATTDB_PERM_AUTH_READABLE is added, pairing occurs but then the
8 byte value set in the GATTDB cannot be read. The LightBlue app indicates
no value has been read.
Trace is showing
16:03:44 - blecm evt handler:
16:03:44 - 13050140000100
16:04:00 - Checking readable attribute 0086
16:04:00 - checking auth readable attribute 009e
0x0086 is the handle for AUTH_READABLE attribute but 0x009e
is the handle for something else.
Did you set MITM requirements, and were you using PASSKEY or OOB pairing. The failure should happen if your settings are showing MITM while "Just Works" pairing was used.
Neither PASSKEY nor OOB pairing is being used.
No calls to any lesmp_set functions are used by the example
code from the SDK.