Socket connect fails with ERRNO 113 with http client

[rahul.b.patel]

Hello,
I am facing issue with following mention scenario with http client used to download file to ESP32. I am using IDF2.1 currently.

1. Create socket and connect to server.
2. HTTP GET requests for chunk size of @1500 until all data has been received.
3. Parse and Store received payload into flash (4KB at a time).
4. if recv fails then close socket, create new socket and connect to server again and continue with remaining chunks of data.

Now, I am facing issue in this process after step 4, it does not connect to server and gives errno of 113. Also I have make sure all sockets in between are closing properly.

I have debug into it and found some strange thing as in the step 4 if I add suspending all tasks and resume all tasks immediately and then proceeds further for re-connection, issue is not re-producing.

I have tried suspending all task running currently in my system individually to isolate affecting task but as per the result no task which is accessible even from IDF is affecting it. (as low level wifi and lwip tasks are not accessible it can not be tested).

So anyone have any idea why this issue is coming and why suspending all task somehow resolved it.?
Let me know if more information is needed.

Thanks.

[Ritesh]

Hi ESP_Angus, WiFive & SDK Developers,

Do you guys have any idea regarding this issue? Because, We are in critical stage due to this issue as we have already provided few prototype products to customer for testing purpose.

So, We have right now work around regarding this issue to suspend all task and resume it for that but we don't know impact of this into overall system.

We have also tried to suspend and resume Application level tasks but didn't get any impact for that.

So, It will be good if you guys look this issue in details or let me know if need source code or example code from our side to reproduce this issue at you end.

[Ritesh]

Hi,

ESP_Angus, WiFive and SDK Developers,

Would you guys please look this issue in details as we have already provided few prototypes with workaround logic which is also getting failed sometimes with that 113 error?

So, Right now, We are in critical stage for that and we already had 10K QTY for that product in our hand.

So, It will good and appriciable if you guys will help to us for proper solution of that issue.

Let me or Rahul know if need any details or any information regarding that issue which will be helpful for you to validate at your end if needed.

[Ritesh]

Hi ESP_Angus, WiFive and SDK Developers,

Did you get chance to look issue with details? Do you have any update or any information regarding same?

Let us know if need any details or any information regarding same.

[WiFive]

I suggest you put pressure on your sales rep to get a fix backported to 2.1. I told you 100 times you would regret using older sdk versions.

[Ritesh]

I suggest you put pressure on your sales rep to get a fix backported to 2.1. I told you 100 times you would regret using older sdk versions.

Hi,

Sorry for continuous pinging for same issue.

We have tried same application with ESP32 IDF 3.1 SDK and didn't able to reproduce issue yet. But, Still, Testing is on going with ESP32 IDF 3.1.

But, We need to validate each and every test-cases to move from ESP32 IDF 2.1 to 3.1 before releasing to customer which is critical thing for us in this stage as we had already delivered few prototypes to them.

Still, Let me try from my side regarding same and will get back to you if need any help for same.

[ESP_Angus]

Hi Ritesh,

Updating to IDF V3.1 is certainly strongly recommended, if you can do this.

Regarding the error you're seeing in v2.1, it's hard to debug based on a high level description rather than code or packet captures, and I can't see any issue in the IDF history that suggests we fixed something exactly like what you describe, but I can provide some tips to help you debug at your end:

- Errno 113 is ECONNABORT which maps to ERR_ABRT in LWIP. Usually this state indicates that LWIP has called tcp_abort() on the connection PCB for some reason (lack of resources, bad state, etc.)

- As a debugging technique, try increasing the maximum socket limit in LWIP menuconfig and see if the problem takes longer to occur.

- Make sure your other task(s) are not starving out the LWIP task. (Particularly, writing to flash means other tasks are suspended so this will limit the LWIP task's opportunity to process its own data internally.) Try replacing any suspend/resume workarounds with a simple vTaskDelay(10) or similar and see if this also helps.

If you can put together a test project that builds, runs, and displays the problem, we can probably debug it in v2.1.1. However it may be easier for you to update to v3.1.

Angus

[Ritesh]

Hi Ritesh,

Updating to IDF V3.1 is certainly strongly recommended, if you can do this.

Regarding the error you're seeing in v2.1, it's hard to debug based on a high level description rather than code or packet captures, and I can't see any issue in the IDF history that suggests we fixed something exactly like what you describe, but I can provide some tips to help you debug at your end:

- Errno 113 is ECONNABORT which maps to ERR_ABRT in LWIP. Usually this state indicates that LWIP has called tcp_abort() on the connection PCB for some reason (lack of resources, bad state, etc.)

- As a debugging technique, try increasing the maximum socket limit in LWIP menuconfig and see if the problem takes longer to occur.

- Make sure your other task(s) are not starving out the LWIP task. (Particularly, writing to flash means other tasks are suspended so this will limit the LWIP task's opportunity to process its own data internally.) Try replacing any suspend/resume workarounds with a simple vTaskDelay(10) or similar and see if this also helps.

If you can put together a test project that builds, runs, and displays the problem, we can probably debug it in v2.1.1. However it may be easier for you to update to v3.1.

Angus

Hi ESP_Angus,

Thanks for providing useful information.

We have already tried by putting delay as you suggested before but still there is no any impact for that delay. We already enabled debug messages of LWIP and TCP Level from LWIP Component and found that server is not getting response of SYNC request from Client when problem occurs.

Rahul will provide few more details with log which we have captured at that time,

Let me prepare test project and steps for you to reproduce at your end if possible.

[ESP_Angus]

The other thing you can try, which is strongly recommended, is to checkout the "release/v2.1" branch (currently at commit c70a613127). Compared to updating to v3.x, this shouldn't require any code changes, but there are a number of fixes in that branch including fixes for problems writing to SPI flash.

(For an explanation of what a release branch represents, see here in the master branch docs).

[rahul.b.patel]

The other thing you can try, which is strongly recommended, is to checkout the "release/v2.1" branch (currently at commit c70a613127). Compared to updating to v3.x, this shouldn't require any code changes, but there are a number of fixes in that branch including fixes for problems writing to SPI flash.

(For an explanation of what a release branch represents, see here in the master branch docs).

Hello Angus,
Thanks for the suggestion. I have checkout "release/v2.1" branch which you have suggested. Looks like issue is not reproducing now. I have tested 10 times while earlier it was reproducing in 2-3 attempts. Still I will do regression testing then let you know.

Thanks