RE: Unexpected and unhandled MTU exchange request from peripheral followed by unexpected packet fragmentation

dmerillat — Tue, 16 Feb 2021 08:53:41 GMT

I've spent some time looking into exactly this.

[quote userid="7761" url="~/f/nordic-q-a/65463/unexpected-and-unhandled-mtu-exchange-request-from-peripheral-followed-by-unexpected-packet-fragmentation/267509#267509"]Why are you confused about that? I however wonder why your Linux computer says "Request Not Supported", since it immediately after initiates its own ATT Exchange, which succeeds.[/quote]

The problem I'm seeing is that very few BLE libraries expect the peripheral to be sending an exchange MTU Request. Of course it's unsupported, they expect to send the request themselves and handle the response. The handlers are registered for Response, not Request.

The real fault here is this:

[quote userid="7761" url="~/f/nordic-q-a/65463/unexpected-and-unhandled-mtu-exchange-request-from-peripheral-followed-by-unexpected-packet-fragmentation/267681#267681"]If the Error Response is sent by the server with the error code set to Request
Not Supported, the Attribute Opcode is not supported and the default MTU
shall be used.[/quote]

When the softdevice (acting as server) receives Request Not Supported it appears to lock the MTU for that connection, even if the client sends an Exchange MTU Request of its own and gets a responsse that a larger MTU has been negotiated. Softdevice callback to the firmware stack reports that the data size is now 242, but when sending a notification only the first 20 bytes are actually transmitted.

At the very least you should reject the larger size, responding with 23. It would be preferable to simply accept the more standard client-initiated exchange and raise the MTU despite the client rejecting the first unexpected server-initated exchange.

I believe that would be valid according to the BLE spec, since it specifically says "If the Error Response is sent by the SERVER". I don't believe the server is required to ignore the client-initiated exchange, even if the client responded originally with Request Not Supported.