Python example on BlueZ with nrf52840 stop connection after 30 seconds

[jean-marc]

Using the BlueZ Python example in BlueZ /test/example-gatt-server with the dongle nf52840 will fail with "Failed to call gattsExchangeMtuReply (NRF_ERROR_INVALID_PARAM)"

and then disconnect after 30 seconds.

With the phone it will not connect and stop connection after 30 seconds.

Using nRF Connect.

With other means it is connecting OK.

What could be wrong with Nordic?

[Håkon Alseth]

"Failed to call gattsExchangeMtuReply (NRF_ERROR_INVALID_PARAM)"

Are you using nRF connect, if yes; which OS are you running on?

 

With other means it is connecting OK.

What could be wrong with Nordic?

What other central devices have you used to connect to the bluez gatts example?

 

Kind regards,

Håkon

[jean-marc]

nRF connect 2.6.2

Using BT Tools from TI and a Windows LE Explorer.

Thank you for helping

[Håkon Alseth]

Sorry for the long wait. I had issues getting the example-gatt-server to properly work.

It seems that it works fine with the mobile app, while it fails with the error message that you post when tested with nRF Connect 2.6.2 for windows (with pca10040). 

The issue is related to the buffer size of the connectivity firmware (example-gatt-server asks for >247 bytes) that's running on the pca10040: https://devzone.nordicsemi.com/f/nordic-q-a/39496/nrf-connect-failed-to-call-gattsexchangemtureply-nrf_error_invalid_param

 

Best regards,

Håkon

[jean-marc]

I agree that we are running on a problem linked to the MTU size or MTU exchange at initialisation. But where do you see that example-gatt-server ask for >247 bytes.

I know that the bluetooth server without any GATT exchange MTU has 517bytes MTU. I can see it with my TI BTool. Cannot see where example-gatt-server manage this case. 

And what about the link you give me. Does Nordic will care about a fix?

Thank you so much for your help.

[Håkon Alseth]

jean-marc said:

But where do you see that example-gatt-server ask for >247 bytes.

I used wireshark to see the MTU. I do not have enough knowledge about bluez and its inner workings in order to tell where this value is overridden. 517 is likely the default unless otherwise stated on either the device (maybe hciconfig / btmgmt can override this?) or more likely: in the bluez gatts object.

jean-marc said:

And what about the link you give me. Does Nordic will care about a fix?

Thank you for reporting the issue back to us, and providing a way for us to recreate the scenario. I have added my .log to the internal bug report, and made the developers aware of this, and hopefully they will look into this soon.

 

Kind regards,

Håkon

[jean-marc]

OK I think we are looking at the right place. I will have to figure out when (probably on the connection time) the BlueZ app does the MTU request or related command. Anyway thank you for your answer.

[Håkon Alseth]

The bug on our side is that we seem to echo back the same MTU, ie 517 bytes, in the MTU REPLY. The developers are looking into if this originates from the PC application or the firmware running on the nRF side.

Kind regards,

Håkon