Skip to content

WiFiClientSecure::setTimeout() inconsistency with WiFiClient::setTimeout() #6429

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

Closed
1 task done
gonzabrusco opened this issue Mar 14, 2022 · 3 comments · Fixed by #6562
Closed
1 task done

WiFiClientSecure::setTimeout() inconsistency with WiFiClient::setTimeout() #6429

gonzabrusco opened this issue Mar 14, 2022 · 3 comments · Fixed by #6562
Labels
Area: BT&Wifi BT & Wifi related issues Status: Solved

Comments

@gonzabrusco
Copy link
Contributor

gonzabrusco commented Mar 14, 2022

Board

ESP32 Dev Module

Device Description

ESP32 Dev Module

Hardware Configuration

ESP32 Dev Module

Version

latest master

IDE Name

PlatformIO

Operating System

Windows 10

Flash frequency

40Mhz

PSRAM enabled

no

Upload speed

115200

Description

This is not a bug per se, but an inconsistency I have noticed.

WiFiClientSecure::setTimeout() does nothing.

int setTimeout(uint32_t seconds){ return 0; }

but WiFiClient::setTimeout() actually sets the timeout.

int WiFiClient::setTimeout(uint32_t seconds)

Also, this inconsistency extends to other parts of the core. For example this:

client.setTimeout(12000 / 1000); // timeout argument is defined in seconds for setTimeout

Here it is using setTimeout on a WiFiClientSecure because "Reading data over SSL may be slow, use an adequate timeout". But in reality it does just nothing...

The HTTPClient code also uses the setTimeout function, but it ignores if the WiFiClient passed is a WiFiClient object or a WiFiClientSecure object (thus, setting the timeout incorrectly on the second case).

_client->setTimeout((_tcpTimeout + 500) / 1000);

_client->setTimeout((timeout + 500) / 1000);

Shouldn't both method do the "same"? (not the same as "the same code" but as the "same spirit"). I guess the setTimeout method in WiFiClientSecure should call some mbedtls funcion to set the timeout? This is just a guess, that part of the core kind of exceeds my knowledge.

Sketch

No sketch

Debug Message

No message.

Other Steps to Reproduce

No response

I have checked existing issues, online documentation and the Troubleshooting Guide

  • I confirm I have checked existing issues, online documentation and Troubleshooting guide.
@gonzabrusco gonzabrusco added the Status: Awaiting triage Issue is waiting for triage label Mar 14, 2022
@VojtechBartoska VojtechBartoska added Area: BT&Wifi BT & Wifi related issues and removed Status: Awaiting triage Issue is waiting for triage labels Apr 11, 2022
@VojtechBartoska
Copy link
Contributor

Hello, are you able to test this on Arduino core esp32 v2.0.3-rc1? Thanks!

@gonzabrusco
Copy link
Contributor Author

Hello, are you able to test this on Arduino core esp32 v2.0.3-rc1? Thanks!

Yes this remains the same on current master. I just filled a PR (#6562)

@VojtechBartoska
Copy link
Contributor

Thanks for the PR!

Repository owner moved this from In Progress to Done in Arduino ESP32 Core Project Roadmap Apr 26, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area: BT&Wifi BT & Wifi related issues Status: Solved
Projects
Development

Successfully merging a pull request may close this issue.

2 participants