Depends what you are doing, as a WEB server I couldn’t send detailed web pages reliably at 115200, the FAVICON file wouldn’t get to the WEB Client fast enough and very really loaded. At 460800 it worked okay but still a bit patchy. 921600 and it would be acceptable.
Works much better If you can get the data throughput fast enough and will work with more than one connection. try at 230400 first
I’m using a Mbed TLS web socket connection to Google Firebase.
I had a similar issue two years ago and couldn’t get a resolve.
But this was on both Ethernet and WiFi, you say GSM and Ethernet is working okay so probably not a related issue.
So as a workaround I would try to send data, if it failed, reconnect the TLS socket and send again.
At that time I couldn’t find a method to test if the TLS connection was live.
I didn’t actually need permanent connection, I use Firebase as a central database go between for several devices.
That worked okay for me so left it at that.
I haven’t tried it recently, I might dig it out a see if anything has improved.
However, I’ve reluctantly moved over to the 16Mb Flash/4Mb PSRAM ESP32 for now, the built-in event driven WiFi works really well and we needed a sensible firmware ota update option, GSM and MQTT. This works out of the box on the ESP32, one tiny device add a modem and it does it all.
Dreadful IDE and not ARM cores.
But I wouldn’t say its perfect, I still have to test MQTT broker connection on GSM, the operators will drop a TCP connection after a while if there’s no traffic. The modem indicates its connected to cell however you can’t reach it.
This doesn’t happen on WiFi, we have continuous MQTT connections uninterrupted for months.