Repository navigation
SSLClient terminating when flushing buffer #30
Description
I am trying to connect my ESP32 to my MQTT Broker (mosquitto on RaspberryPi) via WiFi.
My code is based on the EthernetMQTT example, but i exchanged the ethernet client for WiFi.
The esp32 succesfully connects to the Broker and publishes a first message, but afte that I get the errormessage:
(SSLClient)(SSL_WARN)(m_run_until): Terminating because the ssl engine closed
(SSLClient)(SSL_ERROR)(flush): Could not flush write buffer!
It seems that using the flush() function is crashing the sslClient, wich is unfortunate, because as described in #9, not using the flush() function after every write to the network results in an a stack overflow.
How do I go about this error? Is it possible to get a kind of stable connection?
My full code:
/**
A BLE client example that is rich in capabilities.
There is a lot new capabilities implemented.
author unknown
updated by chegewara
*/
#include <WiFi.h>
#include <PubSubClient.h>
//SSL
#include <SSLClient.h>
#include "certificates.h" // This file must be regenerated
const char my_cert[] = "FIXME";
const char my_key[] = "FIXME";
SSLClientParameters mTLS = SSLClientParameters::fromPEM(my_cert, sizeof my_cert, my_key, sizeof my_key);
// Setup Wifi
const char* ssid = "...";
const char* password = "...";
const char* mqtt_server = "192.168.2.105";
WiFiClient espClient;
SSLClient espClientSSL(espClient, TAs, (size_t)TAs_NUM, A5);
PubSubClient client(espClientSSL);
void setup_wifi() {
delay(10);
// We start by connecting to a WiFi network
WiFi.begin(ssid, password);
while (WiFi.status() != WL_CONNECTED) {
delay(500);
Serial.print(".");
}
Serial.println("");
Serial.println("WiFi connected");
}
void reconnect() {
// Loop until we're reconnected
while (!client.connected()) {
Serial.print("Attempting MQTT connection...");
// Attempt to connect
if (client.connect("ESP32Client")) {
Serial.println("connected");
// Once connected, publish an announcement...
client.publish("outTopic", "hello world");
// This is a workaround to address https://github.com/OPEnSLab-OSU/SSLClient/issues
Serial.print("calling flush() \n");
espClientSSL.flush();
Serial.print("flush() finished \n");
// Subscribe
//client.subscribe("testtopic/Win");
// This is a workaround to address https://github.com/OPEnSLab-OSU/SSLClient/issues
//espClientSSL.flush();
} else {
Serial.print("failed, rc=");
Serial.print(client.state());
Serial.println(" try again in 5 seconds");
// Wait 5 seconds before retrying
delay(5000);
}
}
}
void callback(char* topic, byte* payload, unsigned int length) {
Serial.print("Message arrived [");
Serial.print(topic);
Serial.print("] ");
for (int i = 0; i < length; i++) {
Serial.print((char)payload[i]);
}
Serial.println();
}
void setup() {
Serial.begin(115200);
while (!Serial);
// Enable mutual TLS with SSLClient
espClientSSL.setMutualAuthParams(mTLS);
//Connecting to Wifi and MQTT Broker
setup_wifi();
client.setServer(mqtt_server, 8883);
client.setCallback(callback);
}
void loop() {
//MQTT
if (!client.connected()) {
reconnect();
}
client.loop();
//Serial.print("Attempting MQTT hello there!");
client.publish("testtopic/ESP", "hello there!");
// This is a workaround to address https://github.com/OPEnSLab-OSU/SSLClient/issues
espClientSSL.flush();
delay(3000); // Delay a second between loops.
} // End of loop
longer serial output:
...
WiFi connected
Attempting MQTT connection...connected
calling flush()
(SSLClient)(SSL_WARN)(m_run_until): Terminating because the ssl engine closed
(SSLClient)(SSL_ERROR)(flush): Could not flush write buffer!
flush() finished
Attempting MQTT connection...connected
calling flush()
Serverside log:
1609262639: New connection from 192.168.2.73 on port 8883.
1609262639: New client connected from 192.168.2.73 as ESP32Client (p2, c1, k15).
1609262661: Client ESP32Client has exceeded timeout, disconnecting.
1609262662: New connection from 192.168.2.73 on port 8883.
1609262662: New client connected from 192.168.2.73 as ESP32Client (p2, c1, k15).
Activity
prototypicalpro commentedon Dec 29, 2020
Hello! This bug has been really nasty thus far and it's unfortunate that you're encountering it. Would you mind posting your device logs with the debug level set to
SSLClient::SSL_DUMP?Inkomidwastaken commentedon Dec 29, 2020
sure:
genotix commentedon Mar 19, 2021
I have been having the same issues here.
I'm using a TTGO T-CALL v1.4 with an ESP32 WROVER-B and using PubSubClient to connect to AWS IoT Core.
I have been very keen on closing char[] with a null terminator (which already helped a lot in sustaining the connection)
I also moved the majority of static strings / char arrays to PROGMEM.
Stack seems to overflow after about 2500 successful message transfers.
I will provide the SSL debug on my next post after I have applied some of the advices I found in another thread.
Note that I am running a slightly modified MQTT PubSubClient since the orginal one does have a (heap?) memory overflow (so this issue might as well be related to that Client!)
MQTT settings:
Publish Function
Stacktrace
prototypicalpro commentedon Mar 22, 2021
@Inkomidwastaken and @genotix sorry for the long delay but I believe I have fixed the issue. @Inkomidwastaken huge thanks for posting your code, with your example I was finally able to track this bug down to SSLClient occasionally attempting to send zero bytes which caused BearSSL to crash the ESP32. This bug should be fixes in
v1.6.11, and I've updated the examples to remove theclient->flush()workaround.@Inkomidwastaken note that you'll want to refactor your loop so that
client.loopis called more frequently to prevent timeouts:genotix commentedon Mar 22, 2021
You're kidding!
That is great!!! Thank you both!
I will run a test as soon as you have released 1.6.11
I am currently at 6000 messages (and counting) with the flush workaround.
michaelhwhitten commentedon Mar 22, 2021
Y'all, for what it's worth to you I've been running this code since yesterday, with the fix. No flushes. Yesterday it looked good. Today I removed some of my debug and have been letting it go. I'm currently at 57,313 publishes without an error. This on an esp32 sitting inside an M5Stack module. I think he's nailed it.
michaelhwhitten commentedon Mar 23, 2021
Ok, final checkin on this one from me. I'm now at 215,000+ publishes without an error. Nice job!