BLE MTU is no longer negotiated when ESP client forms a connection

[JHedgesBartec]

Answers checklist

• I have read the documentation ESP-AT Programming Guide and the issue is not addressed there.
• I have used the latest released firmware or have updated my ESP-AT branch (master or release) to the latest version and checked that the issue is present there.
• I have searched the issue tracker for a similar issue and not found a similar issue.

AT+GMR

AT version:4.2.0.0-dev(s-ae87b55 - ESP32 - Mar 3 2026 09:05:26)
SDK version:v5.4.1-643-g8ad0d3d8f2-dirty
compile time(ed86344):Mar 9 2026 16:12:28
Bin version:v5.0.0.0(WROOM-32)

ESP-AT Firmware Source

Built from github using commit ed86344
Features modified to disable OTA and enable BTC.

Hardware Information

ESP32-WROOM, also confirmed using ESP32 DevKitc v4

Power Supply used

External 3.3V

What is the expected behavior?

When the client (esp32) forms a connection to the server (any) the MTU is automatically negotiated and reported using the BLECFGMTU event.
Any writes using AT+BLEGATTCWR would be allowed to be above MTU-3 and module would internally manage this.

What is the actual behavior?

MTU negotiation is no longer done and writing to characteristics now fail if the write is larger than MTU-3.

Probability of recurrence

100%

AT+SYSRAM?

N/A

Steps to reproduce

1. Initialise as BLE client
2. Form a connection to a server
3. MTU is not reported
4. Attempt to write to characteristic

AT command port output

****** Previously working commit (102d512) *****
AT+BLESCANPARAM=0,0,0,100,50 

OK
AT+BLESCAN=1,10
<data omitted>
OK 
AT+BLESCAN=0

OK
AT+BLECONN=0,"F8:8A:5E:0D:20:BC",0
+BLESCANDONE
+BLECFGMTU:0,247
+BLECONN:0,"f8:8a:5e:0d:20:bc"

OK
AT+BLEGATTCWR=0,2,2,1,1

OK
AT+BLEGATTCWR=0,3,2,,496
<data omitted>
OK


***** commit ed86344 *****
AT+BLESCANPARAM=0,0,0,100,50 

OK
AT+BLESCAN=1,10
<data omitted>
OK 
AT+BLESCAN=0

OK
AT+BLECONN=0,"F8:8A:5E:0D:20:BC",0
+BLESCANDONE
+BLECONN:0,"f8:8a:5e:0d:20:bc"

OK
AT+BLEGATTCWR=0,2,2,1,1

OK
AT+BLEGATTCWR=0,3,2,,496

ERROR

AT log port output

Silenced due to binary size.

More Information.

No response

[XionHsieh1025]

I have re-tested the version you mentioned and failed to reproduce the issue. I'd like to confirm with you:

Did the ERROR return immediately after you entered the command, or did you first see the '>' character, and then the ERROR appeared only after you finished entering 496 bytes of data?

[JHedgesBartec]

Hi @XionHsieh1025

ERROR is returned before the data is input.

Did you check your MTU was less than the number of bytes you were transmitting? AT+BLECFGMTU?
I think the root of the issue is that we see the MTU negotiation is no longer automatically performed when a connection is made, the +BLECFGMTU message is no longer seen.

Here is our factory image.
esp_wroom_32_at_factory_5_0_0_0.zip

[XionHsieh1025]

Hi @JHedgesBartec

Thank you for providing the firmware. I have conducted the corresponding tests with the firmware you supplied, and no issues were detected during testing. The attached screenshots illustrate the complete workflow of my test.

The peer device runs the official example from ESP-IDF:

• esp-idf/examples/bluetooth/bluedroid/ble/gatt_server_service_table

Regarding the MTU size issue, there should be no problem, as the AT firmware implements automatic packet fragmentation internally. Based on the symptoms you described, I believe the root cause is more likely that the service discovery command was not invoked after the connection was established.

[JHedgesBartec]

@XionHsieh1025

Have you tested where the peer device is not an Espressif device using ESP-IDF?

We are seeing the issue with a Silicon Labs based device, this device has not changed between the two firmware versions provided so we know the change is in ESP-AT behavior.

For now we have worked around by manually triggering the MTU negotiation.

[XionHsieh1025]

I haven’t performed hardware testing with Silicon Labs because I don’t have the relevant hardware on hand. Do you have a packet capture card? If you do, you can verify from the packet capture logs whether we sent out the first packet. Even if the MTU is not updated, the data will definitely be fragmented for transmission — this behavior is consistent across all versions.

[oumayma-ba]

I'm having the same issue. When I try to connect and disconnect from the ESP32-C6, in some cases the MTU is not negotiated and remains set to the default value.

[XionHsieh1025]

I'm having the same issue. When I try to connect and disconnect from the ESP32-C6, in some cases the MTU is not negotiated and remains set to the default value.

We previously saw an issue where the MTU event was reported before the connection event. From your description, that ordering could explain what you are seeing. That issue has since been fixed, and the fix should be included in the latest master branch.

I have not been able to reproduce this locally. Could you retest with the current master build and let us know whether the behavior persists?