Closed javic-elec closed 2 years ago
This issue seems to be that somehow, the ssl handshake timeout is set to 0 after the first message.
A temporary fix that worked for me was to change line 266 in the ssl_client.cpp (in the WiFiClientSecure library) file from:
if((millis()-handshake_start_time)>ssl_client->handshake_timeout)
to:
if((millis()-handshake_start_time)>(ssl_client->handshake_timeout != 0?ssl_client->handshake_timeout:120000))
(So I manually set a timeout if the handshake_timeout is zero.)
I ran into this problem, and came with my work-around, which was to keep the channel open by deleting this line (at the cost of memory perhaps)
client->stop();
But then I saw @ndaneil comment .... and added to it. Rather than dig into ssl_client.cpp, you can add this line before the client->connect in the library.
client -> setHandshakeTimeout(120000);
int x = client->connect(HOST, SSL_PORT);
You would have to add that setHandshakeTimeout before every one of these lines:
if (!client->connect(HOST, SSL_PORT)) {
The 120000 is milli-seconds or ??? But it comes from this source:
sslclient->handshake_timeout = 120000;
You might also have to make this change to stop using Client and switch everything to WiFiClientSecure to get access to these calls (in the .h and .cpp)
UniversalTelegramBot(String token, WiFiClientSecure &client);
//UniversalTelegramBot(String token, Client &client);
This is a simpler solution / work-around. You still have to replace Cliient.h with WiFiClientSecure.h
Did you post this bug over in esp32-arduino issues?
void UniversalTelegramBot::closeClient() {
if (client->connected()) {
#ifdef _debug
Serial.println(F("Closing client"));
#endif
client->stop();
client -> setHandshakeTimeout(120000);
}
}
I found an open issue with the problem in the esp32-arduino repo: https://github.com/espressif/arduino-esp32/issues/6077
Seeing as the client is passed into the library, you should be able to set the timeout in the client from your sketch. This would save the need for modifying the library.
I assume it only needs to be set once per instance of the client.
On Mon 3 Jan 2022, 17:58 ndaneil, @.***> wrote:
I found an open issue with the problem in the esp32-arduino https://github.com/espressif/arduino-esp32/issues repo: espressif/arduino-esp32#6077 https://github.com/espressif/arduino-esp32/issues/6077
— Reply to this email directly, view it on GitHub https://github.com/witnessmenow/Universal-Arduino-Telegram-Bot/issues/270#issuecomment-1004258138, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAL5PQVBBNXXZYRUI4YM6EDUUHPTVANCNFSM5KVR5RWQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you are subscribed to this thread.Message ID: <witnessmenow/Universal-Arduino-Telegram-Bot/issues/270/1004258138@ github.com>
Hi,
So I was testing my Telegram bot code after a long time since the last time I used it. I updated the ESP32 core to 2.0.2 (how lucky, just released 10 hours ago...), the UniversalTelegramBot to 1.3.0 and the ArduinoJson to 6.18.5. Testing either example codes or my own code, the bot just manages to send one message, but not more. It always gets stuck after the first sent message.
I have spent nearly an hour trying to figure out what was the problem, I even tried creating a new bot. As a last option, I just downgraded the ESP32 core to 2.0.1 and it worked perfectly.
So, if someone just runs with the same issue, downgrade to ESP32 core 2.0.1 (or just don't update it). I hope I can save someone's time.
Cheers.