MTU change issue (GATT_INVALID_PDU)

[nikname]

I am getting the following exception when trying to change the MTU

com.juul.kable.GattStatusException: OnMtuChanged(mtu=23, status=GATT_INVALID_PDU(4))
        at com.juul.kable.AndroidPeripheral.requestMtu(Peripheral.kt:403)
        at com.juul.kable.AndroidPeripheral$requestMtu$1.invokeSuspend(Unknown Source:12)
        at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
        at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:106)
        at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.kt:571)
        at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.executeTask(CoroutineScheduler.kt:750)
        at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker(CoroutineScheduler.kt:678)
        at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:665)

This is how I am trying to do that

override suspend fun connect() {
    peripheral.connect()
    try {
        (peripheral as AndroidPeripheral).requestMtu(23)
    } catch (e: GattStatusException) {
        Log.d(TAG, e.stackTraceToString())
    }
    isReady.emit(State.Connected)
}

Am I doing somthing wrong?

[twyatt]

What you're doing looks correct.

Quick Google search indicates that MTU can only be requested once per connection. Kable does not make any MTU requests internally, so that shouldn't be a problem here.

Do you get the same failure when requesting a different MTU (e.g. 128 or 512)?

I'll try to find some time soon to test/reproduce on my side.

[nikname]

I have found that I was connecting multiple times so that is the cause of the exception.
Requesting higher MTU makes no difference (it remains 23).

If I write 23 bytes of data a characteristic using Kable I get an error result. If I write the same 23 bytes of data using nRFConnect I get a success result. With Kable I get a success result only if I write a maximum of 15 bytes of data

[nikname]

Finally I have solved the problem by passing WriteType.WithResponse to the write method.
I do not know if this is the correct behavior. For me the issue can be closed

[twyatt]

Thanks for following up with what works for you!

You don't happen to know if nRF Connect is writing with response?

(trying to see if this issue needs further investigation, if nRF Connect is doing write without response then I might try to determine why there is a difference of the max MTU you can obtain)