forcing BLE 4.2 and above connection - Avoiding fallback to BLE 4.0

[yes]

We use nRF52832 (S112  / S130) and nRF840 (S140) for our future products

By default server device which supports BLE 4.2 shall fallback to BLE 4.0 and accept connection request from observer device which doesn't support BLE 4.2. 

Can we force BLE 4.2 (and above) connection i.e BLE 4.0 device connection request shall be rejected?

Thanks in advance

[Håkon Alseth]

Hi,

 

Can we force BLE 4.2 (and above) connection i.e BLE 4.0 device connection request shall be rejected?

No, this is not possible. The softdevice does not pass this information on to the application.

 

Best regards,

Håkon

[yes]

I apologize for reopening this issue

Following the fact that SD does not pass BLE version (4.0 / 4.2 / 5.0) and fallbacks to client version, is there a way to use service / characteristics security or encryption flags and force failure if connection is below 4.2 

e.g. messages' length in data link layer which is maximum 20 bytes (4.0) while 4.2 allows almost 254 bytes message length

or use one of the advance security features of 4.2

Thanks in advance

[yes]

Can we use ECDH which is only supported at 4.2 as mention here? If yes, how it can be implemented?

[Einar Thorsrud]

Hi,

yes said:

Following the fact that SD does not pass BLE version (4.0 / 4.2 / 5.0) and fallbacks to client version, is there a way to use service / characteristics security or encryption flags and force failure if connection is below 4.2 

e.g. messages' length in data link layer which is maximum 20 bytes (4.0) while 4.2 allows almost 254 bytes message length

or use one of the advance security features of 4.2

What exactly do you mean? You can use security with lower versions as well, but then legacy pairing is the only option. Why do care about the BL version of the other device? Almost all features since 4.0 are optional, so it is better to act based upon weather the peer supports the features you need or not. If it does not, you can choose to disconnect.

yes said:

Can we use ECDH which is only supported at 4.2 as mention here? If yes, how it can be implemented?

LESC only works when both peers support LESC. But you can still have your device support both LESC and legacy pairing, so that LESC is used if the peer support it, or legacy pairing if not. That is up to you, and what makes most sense depends on the security requirements (etc.) of your product.

[yes]

Einar Thorsrud said:

If it does not, you can choose to disconnect.

Due to regulation mater we were required to make sure that only BLE 4.2 connection shall be established and client which sopports only 4.0 shall be rejected or atleast application layer shall be notified.

Can we use LESC for that? Does it fallbacks or connection failed? Can our application be notified?

Thanks

[Einar Thorsrud]

yes said:

Due to regulation mater we were required to make sure that only BLE 4.2 connection shall be established and client which sopports only 4.0 shall be rejected or atleast application layer shall be notified.

Strange. What regulation affects this?

yes said:

Can we use LESC for that? Does it fallbacks or connection failed? Can our application be notified?

Not really. You can choose to always require LESC bonding, and the application can disconnect if the peer does not support LESC. However, it is perfectly legal for a BLE device which is 4.2 compliant (or even higher) to not support LESC, since this is an optional feature. So it is not a foolproof way to distinguish between Bluetooth version. (as mentioned before, Bluetooth versions are almost irrelevant, since virtually all features added after 4.0 are optional).