Socket API weirdness in my app.

[fly135]

Been using the posix socket api instead of the lwip API and generally it seems to work fine. However, I have been experiencing a issue that seems like a problem. When I use sockets to talk to a HTTP server to handle a transaction I have no issues. I am using SSL, but my issue occurred when not using it as well. Here's my problem...

I'd like to make a request to the HTTP server and wait for a response that may not come for minutes. This is what I'm doing when talking to Pubnub. I have a socket set up with a recv timeout of less than 5 minutes, which is the timeout period for Pubnub. The issue is that after about 20 secs of inactivity I don't get any more messages from pubnub unless I disconnect and reconnect. I don't think the issue is caused by pubnub.

I know that the first question is let's see some code. I'd have to write a server on a PC and a client on the ESP32 to really back up what I'm seeing. What I'm looking for is if anyone has written code that is sitting in a socket recv function with a long timeout waiting for data. And if they have experienced anything like I am seeing. Or if they aren't, and maybe using lwip api instead of posix API.

If nobody can confirm this is happening to them, then I will write a simple server/client to investigate independent of pubnub.

John A

[fly135]

Just wrote a simple tcp client app on esp32 with 90 sec timeout on recv. I also wrote a simple server app on windows that sends "ABCD", then delays for an amount of seconds that increments each send. Starts at 1 sec and increments the delay by 1 sec on each send. The esp32 stops printing out the "ABCD" after 6-10 recvs, then waits for the remainder of the timeout period and has an EAGAIN error.

I guess the next step is to rewrite the test using lwip api instead of posix. There is also a "netconn" api, which I know nothing much about but could try as well. Can't help but think that this is a bug in the api. I've written a fair amount of socket stuff in the past. Things like an RTSP server or terminal servers for PTZ cameras that wait for data with timeouts. This is the first time I've encountered this problem.

John A

[fly135]

Changed my server to just send packets at 1 sec intervals. The ESP32 still hangs on the recv after a while. When it does I see TCP retransmissions from the server. It appears that there is something really wrong with the socket api.

John A

[fly135]

Anyone know what underlying socket api that mbedtls uses? I need encryption, so just using lwip or netconn isn't going to work if I can't put encryption on top.

John A

[ESP_Angus]

Hi John,

Are you able to please share some test code which exhibits the problem? Ideally something that's ready to drop in a project and compile.

Anyone know what underlying socket api that mbedtls uses? I need encryption, so just using lwip or netconn isn't going to work if I can't put encryption on top.

BSD sockets API. The socket layer code is port-specific, can be found here: https://github.com/espressif/esp-idf/bl ... _sockets.c

Angus

[fly135]

I'm going to recompile my test client with a later sdk version. If it still doesn't work I'll share the source.

John A

[fly135]

I rebuilt it with a recent sdk (ESP-IDF v3.2-dev-141-ga3c43251-dirty) and the behavior seemed much better. It took longer before it hung. I need to go back and recompile with the old and make sure.

I have attached a zip file with a windows exe for the server and a folder for the esp32 client. It's just a slight modified example, so use make menuconfig to set the wifi ssid/pwd. The readme gives info. You have to modify main.cpp to use the ip of your windows computer. Then run the exe in a command window. I use wireshark to sniff the packets. It will run for a while and then the esp32 stops acking packets resulting in retransmissions from the server. The recv socket on the esp32 times out in 20 secs. But I don't think it makes any difference how long you wait.

John

[fly135]

Wireshark capture pic (107 is the esp32)

[fly135]

I decided to test this on a devkit board from Amazon instead of our own hardware and am seeing no errors right now. I am a tendency to announce my discoveries prematurely. But if the devkit is solid then we need to focus on our design, which uses an ext antenna as opposed to the devkit with the internal antenna.

So now I went back to our board and it is working with no issues. This morning I run my tests. Using the latest IDF and the older one and everything is working. Now I need to look into wifi activity and strength to see if it is impacting my results.

John A