How to reject/disconnect peer (smartphone) which tried to write huge data to service?

[Arthur_Melkumov]

How to reject/disconnect peer (smartphone) which tried to write huge data to service? For now in my project (based on ble_app_multperipheral project from SDK) if the smartphone is try to send more than 20 bytes - the connection is just frozen till GATT CONN Timeout. I want to disconnect the smartphone in such cases.

[Marjeris Romero]

Hi,

What is your MTU size? The default MTU size in the ble_app_multiperipheral example is 23 bytes, with 3 bytes for the ATT header it leaves you with 20 bytes payload.

Perhaps the smartphone is using Queue Writes in order to send a characteristic longer than 20 bytes, splitting the writing operation into more than a single packet. In that case you can get a GATT CONN timeout if the queue writes are not handle correctly by the peripheral. Have you modified the ble_app_multiperipheral example in some way? Perhaps try to check if  you are still initializing the QWR module, in the out-of-the-box example this module is initialized in the LED button service.

Best regards,

Marjeris

[Arthur_Melkumov]

Hmmm. I thought that the QWR module is one of the ways to write a big amount of data (more than 20 bytes) but not the only one.
And for now, in my code, I don't initialize this module and just by changing the NRF_SDH_BLE_GATT_MAX_MTU_SIZE from 23 to e.g. 40, I get the ability to write data more than 20 bytes (up to 37 bytes). And with that configuration, if the smartphone sends data of length <=37 bytes - nRF receives it and can operate this data. But if the smartphone sends data which length is more than 37 bytes - the connection freezes.
So to understand you clearly - the reason of such freezings is just not initialized QWR module? But when I write more than 20 bytes without initializing it and it works - why?

[Marjeris Romero]

If you don't have QWR module you will not be able to handle write requests from the Softdevice, such as BLE_GATTS_EVT_RW_AUTHORIZE_REQUEST if the client starts a queued write request, and this will soon or later result in timeout. You don't need to support long writes, but you should be able to handle the requests from the Softdevice.

You can try to increase the MTU_SIZE up to 247 so you can handle when the smartphone sends data with more than 37 bytes length.