sdk11 NUS

RE: sdk11 NUS

Einar Thorsrud — Wed, 20 Sep 2023 10:07:08 GMT

You are working on the central side that is based on SDK 11, right? And the code in the other thread is relevant for the peripheral side as that has a newer SDK (which version?). The other thread was not fully concluded, and the suggesting there does not fully. make sense (as client_mtu = MIN(client_mtu, BLE_GATT_ATT_MTU_DEFAULT); would always be 23, which is BLE_GATT_ATT_MTU_DEFAULT, as that is the lowest possible.

I don't have a full oveview of what is happening though, so I think a sniffer trace is needed. If you could elaborate on what you see that could be relevant as well, with reference to the sniffer trace. Particularily: "When the customer units sends data to our unit over the NUS protocol all data after 20 bytes is missing" <- Is this data sent by the central, or is it not? Where/how is it lost? We need to understand this before we can consider how to fix or workaround the issue.

RE: sdk11 NUS

yuval — Mon, 18 Sep 2023 08:21:48 GMT

It will take time until i get a sniffer

however, i find other ticket:

https://devzone.nordicsemi.com/f/nordic-q-a/68320/ble-notifications-and-mtu-negotiation-on-bluetooth-4-0

which describes more or less the problem as mine.....

i will tell the other guys to change it to "MIN":

found in "on_exchange_mtu_request_evt" in "nrf_ble_gatt.c":

client_mtu = MAX(client_mtu, BLE_GATT_ATT_MTU_DEFAULT);

RE: sdk11 NUS

Einar Thorsrud — Thu, 14 Sep 2023 12:55:08 GMT

The MTU negotiation is encrypted, but as you have LESC set to 0 here that indicates you are using legacy pairing. And int that case the sniffer can decrypt everything as long as it listens in on the pairing procedure. See Sniffing the pairing procedure of a connection for more details.

RE: sdk11 NUS

yuval — Thu, 14 Sep 2023 10:16:04 GMT

The data which transfered netween the units is encrypted (BONDING and etc') from the very begining. do you know if the MTU negotiation is inside this encrypten or outside it?

This is the encryption we use:

#define SEC_PARAM_BOND 1 /**< Perform bonding. */
#define SEC_PARAM_MITM 0 /**< Man In The Middle protection not required. */
#define SEC_PARAM_LESC 0 /**< LE Secure Connections not enabled. */
#define SEC_PARAM_KEYPRESS 0 /**< Keypress notifications not enabled. */
#define SEC_PARAM_IO_CAPABILITIES BLE_GAP_IO_CAPS_NONE /**< No I/O capabilities. */
#define SEC_PARAM_OOB 0 /**< Out Of Band data not available. */
#define SEC_PARAM_MIN_KEY_SIZE 7 /**< Minimum encryption key size. */
#define SEC_PARAM_MAX_KEY_SIZE 16 /**< Maximum encryption key size. */

RE: sdk11 NUS

Einar Thorsrud — Thu, 14 Sep 2023 09:08:21 GMT

Hi,

I am not able to explain why without knowing more. Can you start with a sniffer trace of the connection showing everything from advertising and later? You can use nRF Sniffer for Bluetooth LE for that if you have an extra DK or dongle.

RE: sdk11 NUS

yuval — Thu, 14 Sep 2023 08:47:58 GMT

Hi,

I'm working with NRF52832 with S132 2.0.0 which came with SDK11 (CENTRAL)

The other party is working on NRF52833 (PHERIPHERAL) s140_nrf52_7.2.0_softdevice.hex

For an unknown reason the MTU is set to larger from 23 !

Can you explain why?

RE: sdk11 NUS

Einar Thorsrud — Wed, 13 Sep 2023 13:08:20 GMT

Hi Yuval,

Based on the description there seems to be a bug in your central implementation, as it accepts increasing the MTU without properly handling it.

Which SoftDevice version are you using? S132 2.0.0 that was part of SDK 11, or another version? I ask because configurable ATT MTU was first introduced in version 3.0.0 of the SoftDevice, so it should not be possible for the peripheral to perform a successful MTU exchange procedure, and the MTU should remain at the default (23). So it is possible that the issue here is in a misbehaving peripheral as well.

Do you have a sniffer trace of the communication so that we can get the full picture of what is going on on air (so that we can start by figuring out if the problem is within the central or the peripherals)?

[quote user=""]1) Can i force him (I'm the central) to stay in MTU size 23 when connected to me?[/quote]

Yes. The at the start of the connection, the MTU is always 23 by default, and it is only increased after a negotiation.

[quote user=""]2) if change the L2CAP size will it make any different?[/quote]

It should not matter, but we need to first understand what the problem really is.

[quote user=""]3) Is there another way (supported by both SDK) to split the data up to 20 bytes?[/quote]

This should be working out of the box. Any increase in MTU size or use of other new features compared to Bluetooth 4.0 should only be used after a negotiation, ensuring backwards compatibility. So there is an issue in one of the devices that prevents this that we need to find.

Br,

Einar