-
Notifications
You must be signed in to change notification settings - Fork 46
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SSLClient terminating when flushing buffer #30
Comments
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 |
sure:
|
I have been having the same issues here. I have been very keen on closing char[] with a null terminator (which already helped a lot in sustaining the connection) 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
|
@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 @Inkomidwastaken note that you'll want to refactor your loop so that unsigned long startTime = millis();
void loop() {
if (!client.connected()) {
reconnect();
}
if (millis() - startTime > 3000) {
// this is called every three seconds
Serial.print("Attempting MQTT hello there!");
bool success = client.publish("testtopic/ESP", "hello there!");
Serial.println(success);
Serial.println(client.state());
heap_caps_print_heap_info(MALLOC_CAP_DEFAULT);
}
// this is now called every loop() instead of once every 3 seconds
client.loop();
} |
You're kidding! 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. |
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. |
Ok, final checkin on this one from me. I'm now at 215,000+ publishes without an error. Nice job! |
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:
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:
longer serial output:
Serverside log:
The text was updated successfully, but these errors were encountered: