https long timeout tracked down to ssl_client.cpp and lwip

[spyder0069]

I am trying to post to a https page. Everything works but if you have a scenario where the unit cannot reach the page there is a long 18 second timeout. The timeout command do not affect this. If you change the url to http instead it works and fails immediately and continues. This only seems to affect https calls.

I tracked back through the code and it hangs in the ssl_client.cpp file at this line:

Code: Select all

if (lwip_connect(ssl_client->socket, (struct sockaddr *)&serv_addr, sizeof(serv_addr)) == 0) {

I am guessing that is where its trying to make connection to the server. However, there is no timeout being passed to this call so it must have its own timeout in the lwip_connect but its taking a long time.

In my case for testing I just turn on the parental block on my router for the esp device so that it can't reach the outside world.

Is there a way to adjust the timeout for the lwip_connect? How is this https use of this different from the http?

The 18 second block is too long for my application. Any advice would be appreciated.

[boarchuz]

Yeah if you're using the setConnectTimeout function then it won't have any effect on HTTPS. It's going to be using LWIP's internal backing-off algorithm for the TCP timeout, where it will retry about 6 times increasing the delay each time = ~18s total.
It's astonishing to me that LWIP still doesn't have a very simple TCP connect timeout but that's the case, unfortunately.
There are some LWIP config options in IDF to tweak but they don't do as much as I'd like (and will affect all LWIP connections), and on Arduino you don't really have anything to work with.
My suggestion would be to save yourself the headache of diving any deeper into it for now. See if there's some kind of ping library/function you can plug in and use that to test if the server is up before making the HTTP request.

[spyder0069]

Thanks for the reply and unfortunately I figured this was going to be the case. I have a different file that I read from the server using regular http so I suppose I could always read first and if it is successful then switch to https for the post. I don't think there is anything critical about the data being sent that it has to be https. It was more precautionary and one of my users requested it.