Get more specific error when R/TX buffers are out of resource

[mohammad1603]

Description

• Type: Bug
• Priority: Minor

Target
K64F
Toolchain:
GCC_ARM

Toolchain version:
GCC 6

mbed-os sha:
latest tag

Expected behavior
More specific error when TX buffers go out of resources

explain:
in handshake flow, the "mbed_lwip_sendto()" function is called, when the flow reaches "k64f_low_level_output()" this function calls " osSemaphoreAcquire()" which returns osErrorResource which is translated by the lwip code to “ERR_BUFF – 0xfe” and by the higher level lwip code to
"NSAPI_ERROR_DEVICE_ERROR - 0xfffff43c"

The "NSAPI_ERROR_DEVICE_ERROR" is too generic in this case and we want more specific error for this case in order to be sure that waiting and calling the "mbed_lwip_sendto()" after resources are available can return with success.

We are trying to prevent a situation that we are in a loop and getting "NSAPI_ERROR_DEVICE_ERROR" from another reason.

Actual behavior
Getting more specific error value which say that the R/TX buffers are out of resource and the application can try again later after resources are available again.

Steps to reproduce
The issue happens during DTLS handshake in debug mode only.
attached the call stack:

[0xc0170]

cc @kjbracey-arm @hasnainvirk @mikaleppanen

[hasnainvirk]

This looks legit to me. I think, NSAPI_ERROR_NO_MEMORY should be returned here. NSAPI_ERROR_DEVICE_ERROR is supposed to cover hardware failure cases.

[kjbracey]

It's arguable that NO_MEMORY would be a better code, but there's lack of any proper standardisation of documentation in the abstraction layer on what error codes are hard ("not worth ever retrying on this socket") or soft ("do retry"). I guess things like "NO_SOCKET" or "CONNECTION_LOST" are definitely hard, but "DEVICE_ERROR". Not sure.... Seems kind of hard, but unfortunately I think a lot of code in various stacks has it as the default in error switch conversion tables, so you probably should assume soft.

I agree that turning ERR_BUF into NO_MEMORY would be an improvement, and suggest we make that patch, but I don't think your app should be handling DEVICE_ERROR any differently from that. Or indeed a packet being dropped with a success code, which is just as likely.

This is UDP - packets will get lost, both locally and remotely, due to congestion, buffer overflow etc. Soft errors should be handled by whatever general congestion control mechanism you have (and you do need one). Some sort of slow down and back off when you don't get an ack from where-ever you're sending to.

Basically there are so many potential stacks you could be dealing with here with so varying behaviour, trying to interpret return codes is going to probably not be the best idea. Back off, retry, and if that doesn't work after a while, tear and down and start again. That covers all basic problems, local and remote. (Including stuff you may not expect like your IP address changing, or firewalls and NATs messing you up).

[kjbracey]

Also note that many off-board stacks don't actually provide any meaningful codes at all. It may not even be technically possible to distinguish NO_MEMORY from any other error.

[mohammad1603]

since the error is "DEVICE_ERROR" it will make it hard to us to understand if it is a hard or a soft error.
also since it is kind of a generic error will make it harder cause it can translate a real hard error that retrying will not help.
I totally agree that in soft error we can retry and in hard as you said, not worth to retry.
This is why I asked to translate this case to explicit soft error, then our application will retry to send/receive again.

[mohammad1603]

accidentally closed .

[mikaleppanen]

Made pull request to change cause mapping: #5033

[0xc0170]

Made pull request to change cause mapping: #5033

@mikaleppanen @mohammad1603 Is this issue resolved?