MTU negotiation problem

RE: MTU negotiation problem

Marco Pennacchietti — Thu, 04 Mar 2021 10:28:45 GMT

Hi,

for now I have resolved my problem, is not the best solution but all work now.

I have removed the MTU request from nordic after connection in "on_connected_evt".

In IOS:

I have tested all IOS version from IOS >=10 with bluetooth 4.0, 4.2 and 5.1. IOS always sends the MTU request (185 byte) and my application work good.

in Android:

The android phone don't send the MTU request, so I have insert this request in android application. This is possible only with android >= 5.0.

In this case I excluded the old android 4.4 from compatibility with my system

Marco

RE: MTU negotiation problem

dingari — Thu, 04 Mar 2021 09:51:13 GMT

Hi Simon,

Just wanted to let you know that there are two people answering this thread.

I've gone around this problem for now by simply not requesting an MTU update from the peripheral. If I have time, I'll check out your suggestions. Maybe it would be better for Marco Pennacchietti to start their own thread for this problem?

RE: MTU negotiation problem

Simonr — Thu, 04 Mar 2021 09:12:32 GMT

Okay, then the SoftDevice should handle this on its own. You should check how you're enabling notifications from your central. Where in your application do you do this?

Best regards,

Simon

RE: MTU negotiation problem

Marco Pennacchietti — Wed, 03 Mar 2021 08:00:22 GMT

Hi Simon,

my application derives from the ble_app_uart, the on_write function is in the place where nordic inserted it (ble_bas.c, ble_dfu.c, ble_nus.c and ble_conn_params.c) and I never touched the ble part.

Marco

RE: MTU negotiation problem

Simonr — Fri, 26 Feb 2021 13:57:04 GMT

Please try one more thing. There is an event you can call and wait for in order to check whether notifications are enabled as well. It might not be implemented in your application as it is characteristic specifig, but you can check the on_write() function in the ble_app_uart example for reference. The generated BLE_NUS_EVT_COMM_STARTED; will confirm that notifications are enabled here.

Please let us know how and where you enable notifications from your central device.

Best regards,

Simon

RE: MTU negotiation problem

Marco Pennacchietti — Fri, 26 Feb 2021 08:49:22 GMT

The only 2 call are in the original file nrf_ble_gatt.c (in nrf_ble_gatt_on_ble_evt and on_connected_evt routine

Marco

RE: MTU negotiation problem

Simonr — Thu, 25 Feb 2021 10:22:03 GMT

Hi again

Can you check if you have an sd_ble_gattc_exchange_mtu_request() function somewhere else in your application, as an INVALID state from this function either means you've been disconnected (which does not seem to be the case) or that it an MTU request has already been sent, so it might be that this is called twice in your application for some reason.

Best regards,

Simon

RE: MTU negotiation problem

dingari — Wed, 24 Feb 2021 11:36:27 GMT

Hi Simon,

I understand. I just meant that the GATT module receives BLE_GAP_CONNECTED before my application.

Don't you think there's an imposed problem if both peripheral and central simultaneously initiate an MTU update request? If I don't request the MTU update from the peripheral, I never get in the strange state where my notifications fail with NRF_ERROR_INVALID_STATE.

RE: MTU negotiation problem

Simonr — Wed, 24 Feb 2021 09:41:25 GMT

I think we're still misunderstanding one another. The MTU request is not required by the Bluetooth specification, but we have opted to add this MTU request in our on_connected_evt. on_connected_evt is not called before the BLE_GAP_CONNECTED event, but rather called when this event is triggered (l497 in nrf_ble_gatt.c)

void nrf_ble_gatt_on_ble_evt(ble_evt_t const * p_ble_evt, void * p_context)
{
    nrf_ble_gatt_t * p_gatt      = (nrf_ble_gatt_t *)p_context;
    uint16_t         conn_handle = p_ble_evt->evt.common_evt.conn_handle;

    if (conn_handle >= NRF_BLE_GATT_LINK_COUNT)
    {
        return;
    }

    switch (p_ble_evt->header.evt_id)
    {
        case BLE_GAP_EVT_CONNECTED:
            on_connected_evt(p_gatt, p_ble_evt);
            break;

        case BLE_GAP_EVT_DISCONNECTED:
            on_disconnected_evt(p_gatt, p_ble_evt);
            break;

        case BLE_GATTC_EVT_EXCHANGE_MTU_RSP:
            on_exchange_mtu_rsp_evt(p_gatt, p_ble_evt);
            break;

        case BLE_GATTS_EVT_EXCHANGE_MTU_REQUEST:
            on_exchange_mtu_request_evt(p_gatt, p_ble_evt);
            break;

#if !defined (S112)
        case BLE_GAP_EVT_DATA_LENGTH_UPDATE:
            on_data_length_update_evt(p_gatt, p_ble_evt);
            break;

        case BLE_GAP_EVT_DATA_LENGTH_UPDATE_REQUEST:
            on_data_length_update_request_evt(p_gatt, p_ble_evt);
            break;
#endif // !defined (S112)

        default:
            break;
    }

Best regards,

Simon

RE: MTU negotiation problem

dingari — Tue, 23 Feb 2021 11:23:20 GMT

This is a bug in the SDK, then?

Because if you look at the on_connected_evt function in nrf_ble_gatt.c, you'll see that it will immediately request an MTU update upon connection (before the application even receives the BLE_GAP_CONNECTED event. Regardless of central/peripheral role.

The GATT module will handle an MTU update request from the central in any case (on_exchange_mtu_request_evt) and send a response. Is there a standard way to avoid/delay the request from the peripheral side without having to modify the SDK code?

RE: MTU negotiation problem

Simonr — Tue, 23 Feb 2021 11:17:17 GMT

[quote user="dingari"]It seems really logical that the event (0x3A) isn't received if the peripheral does not send a request.[/quote]

Correct.

a) It doesn't have to, but when the Mac requests a value it doesn't support (>251) the nRF52 will request a lower MTU.

Indeed, what Håkon says in that case still holds true in the Bluetooth spec. I'm sorry if I indicated that the MTU was required. I meant that the response will have to be handled if there is an MTU request.

Best regards,

Simon

RE: MTU negotiation problem

dingari — Mon, 22 Feb 2021 16:42:22 GMT

There seems to be a similar discussion going on here (the thread is 2+ years old).

Simonr what are your thoughts on this?

RE: MTU negotiation problem

dingari — Mon, 22 Feb 2021 10:54:33 GMT

Even if I'm waiting for the MTU response (0x3A) in my nRF52 code before doing anything, sometimes I do not get the event.

Also, like you can see in the macOS logs I provided in the original question, when it succeeds, the Mac sends a MTU request (515), then my nRF52 sends an MTU request (64), and then the Mac receives an MTU response (64).

My question is:

a) Does the nRF52 have to send an MTU request as a peripheral?
b) If so, why could it be that sometimes the nRF52 does not send an MTU request, then?

It seems really logical that the event (0x3A) isn't received if the peripheral does not send a request.

Edit: One more datapoint: If I simply just don't request the update from the nRF52 peripheral (return early from the on_connected_evt function), it seems to work fine every time. Could there be a timing issue between the nRF52 peripheral and the central sending simultaneous MTU update requests and the nRF52 get's in a confused state?

From nrf_ble_gatt.c:

/**@brief Handle a connected event.
 *
 * Begins an ATT MTU exchange procedure, followed by a data length update request as necessary.
 *
 * @param[in]   p_gatt      GATT structure.
 * @param[in]   p_ble_evt   Event received from the BLE stack.
 */
static void on_connected_evt(nrf_ble_gatt_t * p_gatt, ble_evt_t const * p_ble_evt)
{
    ret_code_t            err_code;
    uint16_t              conn_handle = p_ble_evt->evt.common_evt.conn_handle;
    nrf_ble_gatt_link_t * p_link      = &p_gatt->links[conn_handle];

    // Update the link desired settings to reflect the current global settings.
#if !defined (S112)
    p_link->data_length_desired = p_gatt->data_length;
#endif // !defined (S112)

    switch (p_ble_evt->evt.gap_evt.params.connected.role)
    {
        case BLE_GAP_ROLE_PERIPH:
            p_link->att_mtu_desired = p_gatt->att_mtu_desired_periph;
            break;

#if !defined (S112)
        case BLE_GAP_ROLE_CENTRAL:
            p_link->att_mtu_desired = p_gatt->att_mtu_desired_central;
            break;
#endif // !defined (S112)

        default:
            // Ignore.
            break;
    }

    return;

    // Begin an ATT MTU exchange if necessary.
    if (p_link->att_mtu_desired > p_link->att_mtu_effective)
    {
        NRF_LOG_DEBUG("Requesting to update ATT MTU to %u bytes on connection 0x%x.",
                      p_link->att_mtu_desired, conn_handle);

        err_code = sd_ble_gattc_exchange_mtu_request(conn_handle, p_link->att_mtu_desired);

        if (err_code == NRF_SUCCESS)
        {
            p_link->att_mtu_exchange_requested = true;
        }
        else if (err_code == NRF_ERROR_BUSY)
        {
            p_link->att_mtu_exchange_pending = true;
            NRF_LOG_DEBUG("sd_ble_gattc_exchange_mtu_request()"
                          " on connection 0x%x returned busy, will retry.", conn_handle);
        }
        else
        {
            NRF_LOG_ERROR("sd_ble_gattc_exchange_mtu_request() returned %s.",
                          nrf_strerror_get(err_code));
        }
    }

#if !defined (S112)
    // Send a data length update request if necessary.
    if (p_link->data_length_desired > p_link->data_length_effective)
    {
        (void) data_length_update(conn_handle, p_link->data_length_desired);
    }
#endif // !defined (S112)
}

Or is there a standard way to delay the peripheral MTU request, if none is received from the central?

RE: MTU negotiation problem

Simonr — Fri, 19 Feb 2021 07:27:51 GMT

Please ensure that the nRF52 waits for the MTU response from the central device before moving on in the application.

Best regards,

Simon

RE: MTU negotiation problem

Marco Pennacchietti — Thu, 18 Feb 2021 14:28:50 GMT

I think that the problem is not IOS but is on the NORDIC chip.

Now I have done an interesting test with the same phone but with another device that does not use the Nordic chip.

It is always the phone that first sends the MTU request and the device responds. The connection in this case is always fine. I believe that the our problem may depend on the fact that in the connection an MTU request is sent too soon by the nrF52, indeed perhaps it should not be sent from the chip.

This is the situation:

RE: MTU negotiation problem

Marco Pennacchietti — Thu, 18 Feb 2021 13:45:38 GMT

I use IOS (IOS 14.2 iphone XSmax) as a central, connected with a device with nrF52832.

The application on IOS do not send back the ATT MTU response, so the device close the connection after 30 second and do not manage the "write request" from the phone.

i will try to follow your advice even if i work one level above the bt stack.

this is what happens in my situation, in the first a good connection in the second a bad connection:

Marco

RE: MTU negotiation problem

dingari — Thu, 18 Feb 2021 13:41:19 GMT

This happens on Windows also. I've tried both using a custom application to do connection / service discovery, but also going through the Audio Midi Setup application in macOS (this is a Bluetooth MIDI device I'm developing).

I'm using the nrf_ble_gatt module in the nRF52 SDK to handle the GATT MTU negotiations. I've tried making my nRF52 application wait for the MTU response, but then it just hangs indefinitely in the failure case.

In the success case, I see a request from the central, as well as a request from my peripheral. Is there a specific reason why we would need this second request from the peripheral?

RE: MTU negotiation problem

Simonr — Thu, 18 Feb 2021 12:20:05 GMT

Do these failures only occur when using a Mac as the central? What kind of application do you have running on your Mac? It seems liek the application doesn't wait for the ATT MTU update to complete and starts doing a BLE_GATTS_EVT_WRITE before the ATT MTU update response returns. How are you handling the ATT MTU update in both central and peripheral? Please make sure that you are waiting for a response before moving on to the next event/process in your application.

Best regards,

Simon

RE: MTU negotiation problem

Marco Pennacchietti — Wed, 17 Feb 2021 15:17:08 GMT

YES is the same, because in the example of success he receive the:

ATT MTU updated to 64 bytes on connection 0x1 (response)

in case of failed this packet is not present

Marco