This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Why is BLE_GATTS_EVT_EXCHANGE_MTU_REQUEST coming from a GATT server?

Using nRF5 SDK 14.0.0 with Softdevice s132 v5.0.0 on nRF52832.

I've set up my nrf to be a GATT client (in central role), and I'm using bluez on my Linux desktop with a LairdTech BT831 dongle as a GATT server (in peripheral role).

I found that when the client connects to the server, the server sends an ATT EXCHANGE MTU REQUEST. This is received by the softdevice on the client and I get a BLE_GATTS_EVT_EXCHANGE_MTU_REQUEST event, which is very confusing to me -- the MTU is in the client_rx_mtu field, which makes no sense because the server is telling me its MTU.

Q1: I thought the BLE spec was that only the client could initiate an ATT exchange MTU request?

Q2: Why wouldn't the softdevice event be something like BLE_GATTC_EVT_EXCHANGE_MTU_REQUEST? (I know, this isn't in the header files, but it's an event for the client, not the nonexistent server).

Thanks!

--Rob

Parents
  • Hey all, I wanted to chime in here and share more about the problems this GATT implementation is causing, particularly with Apple products. On some Apple devices it causes two "didConnect" callbacks to occur. I've been able to recreate it reliably on a 2017 Macbook Pro and iPhone 11 Pro Max. When I comment out the Nordic peripheral's MTU request it resolves the issue. 

    I suspect there's a race condition in Apple's CoreBluetooth implementation that causes the behavior to occur irregularly across devices. Below is a capture from Wireshark using Nordic's sniffer tool. It captures an "offending transaction" in which both the Macbook and Nordic peripheral both send MTU requests. This particular transaction resulted in the Macbook executing two "didConnect" callbacks. 

    Here's the context for my setup:
    - Our Nordic-based product is acting as a BLE Peripheral w/ GATT server implementation exclusively
    - Using nRF5 SDK 15.0.0 and SoftDevice 132
    - The peripheral negotiates a 247 byte MTU

    I think I can comfortably remove the MTU request from my firmware as it's only using GATT server functionality.  My product connects to a specific App on iOS and Android.  On the iOS side, we can always assume that CoreBluetooth will send a client->server MTU request automatically right after connection.  When it comes to Android the Application layer has access to initiating an MTU request, so we'll just have to be sure to initiate that procedure in the Android App code.  

    I hope this helps someone who's in a similar boat using Nordic products with Apple. 

    -Ray

Reply
  • Hey all, I wanted to chime in here and share more about the problems this GATT implementation is causing, particularly with Apple products. On some Apple devices it causes two "didConnect" callbacks to occur. I've been able to recreate it reliably on a 2017 Macbook Pro and iPhone 11 Pro Max. When I comment out the Nordic peripheral's MTU request it resolves the issue. 

    I suspect there's a race condition in Apple's CoreBluetooth implementation that causes the behavior to occur irregularly across devices. Below is a capture from Wireshark using Nordic's sniffer tool. It captures an "offending transaction" in which both the Macbook and Nordic peripheral both send MTU requests. This particular transaction resulted in the Macbook executing two "didConnect" callbacks. 

    Here's the context for my setup:
    - Our Nordic-based product is acting as a BLE Peripheral w/ GATT server implementation exclusively
    - Using nRF5 SDK 15.0.0 and SoftDevice 132
    - The peripheral negotiates a 247 byte MTU

    I think I can comfortably remove the MTU request from my firmware as it's only using GATT server functionality.  My product connects to a specific App on iOS and Android.  On the iOS side, we can always assume that CoreBluetooth will send a client->server MTU request automatically right after connection.  When it comes to Android the Application layer has access to initiating an MTU request, so we'll just have to be sure to initiate that procedure in the Android App code.  

    I hope this helps someone who's in a similar boat using Nordic products with Apple. 

    -Ray

Children
No Data
Related