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

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

Einar Thorsrud — Mon, 05 Aug 2019 12:20:06 GMT

[quote user="yes"]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.[/quote]

Strange. What regulation affects this?

[quote user="yes"]Can we use LESC for that? Does it fallbacks or connection failed? Can our application be notified?[/quote]

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).

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

yes — Mon, 05 Aug 2019 11:15:57 GMT

[quote userid="7377" url="~/f/nordic-q-a/37280/forcing-ble-4-2-and-above-connection---avoiding-fallback-to-ble-4-0/202390"]If it does not, you can choose to disconnect.[/quote]

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

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

Einar Thorsrud — Mon, 05 Aug 2019 11:02:29 GMT

Hi,

[quote user="yes"][/quote]

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.

[quote user="yes"]Can we use ECDH which is only supported at 4.2 as mention here? If yes, how it can be implemented?[/quote]

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.

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

yes — Sat, 03 Aug 2019 21:01:14 GMT

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

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

yes — Sat, 03 Aug 2019 20:53:11 GMT

I apologize for reopening this issue

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

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

Håkon Alseth — Thu, 09 Aug 2018 08:45:47 GMT

Hi,

[quote user=""]Can we force BLE 4.2 (and above) connection i.e BLE 4.0 device connection request shall be rejected?[/quote]

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

Best regards,

Håkon