Nanostack: translate errors from sendmsg #10410

michalpasztamobica · 2019-04-16T07:37:54Z

Description

Translate errors to NSAPI_ERROR_*, instead of always returning NSAPI_ERROR_DEVICE_ERROR.

Originally, I only wanted to add the handling of -2 (out of memory) error, to fix the numerous SENDTO_REPEAT failures I can see in Nanostack, but while I was at it I though it is wise to translate the other errors as well, instead of just returning DEVICE_ERROR and loosing the information returned from sendmsg call.

Pull request type

[x] Fix
[ ] Refactor
[ ] Target update
[ ] Functionality change
[ ] Docs update
[ ] Test update
[ ] Breaking change

Reviewers

@SeppoTakalo
@kjbracey-arm
@KariHaapalehto
@VeijoPesonen

Release Notes

Nanostack send calls return a more accurate information in case of errors.

SeppoTakalo · 2019-04-16T07:59:39Z

features/nanostack/nanostack-interface/Nanostack.cpp

@@ -648,6 +648,18 @@ nsapi_size_or_error_t Nanostack::do_sendto(void *handle, const ns_address_t *add
     * */
    if (retcode == NS_EWOULDBLOCK) {
        ret = NSAPI_ERROR_WOULD_BLOCK;
+    } else if (retcode == -1) {
+        ret = NSAPI_ERROR_PARAMETER;


If we refer to Nanostack's socket API:

/** ... * Error returns: * * \return -1 Invalid socket ID. * \return -2 Socket memory allocation fail. * \return -3 TCP state not established or address scope not defined . * \return -4 Unknown interface. * \return -5 Socket not connected * \return -6 Packet too short (ICMP raw socket error). */ int16_t socket_sendmsg(int8_t socket, const ns_msghdr_t *msg, int flags);

then should -1 be NSAPI_ERROR_NO_SOCKET

This is how -1 is returned:

if (!msg) { return -1; }

Or here (I think this is the one they meant by "Invalid socket ID."):

if (!socket_ptr || !socket_ptr->inet_pcb) { tr_warn("Socket Id %i", sid); ret_val = -1; goto fail; }

Or here:

if (!socket_message_validate_iov(msg, &payload_length)) { return -1; }

Looks to me like -1 is returned if the input parameters are wrong.

OK. Then its clearly a parameter error.

Yes, -1 is generally "parameter error" in Nanostack, for the few socket functions that have multiple error returns. But the socket ID isn't distinguished from any other faulty parameter.

I would have thought there would be scope for NSAPI_ERROR_NO_SOCKET being generated in the wrapper, at least.

ciarmcom · 2019-04-16T09:00:44Z

@michalpasztamobica, thank you for your changes.
@KariHaapalehto @SeppoTakalo @kjbracey-arm @VeijoPesonen @ARMmbed/mbed-os-ipcore @ARMmbed/mbed-os-maintainers please review.

kjbracey · 2019-04-16T10:20:36Z

features/nanostack/nanostack-interface/Nanostack.cpp

@@ -648,6 +648,18 @@ nsapi_size_or_error_t Nanostack::do_sendto(void *handle, const ns_address_t *add
     * */
    if (retcode == NS_EWOULDBLOCK) {
        ret = NSAPI_ERROR_WOULD_BLOCK;
+    } else if (retcode == -1) {
+        ret = NSAPI_ERROR_PARAMETER;


Yes, -1 is generally "parameter error" in Nanostack, for the few socket functions that have multiple error returns. But the socket ID isn't distinguished from any other faulty parameter.

I would have thought there would be scope for NSAPI_ERROR_NO_SOCKET being generated in the wrapper, at least.

kjbracey · 2019-04-16T10:21:43Z

features/nanostack/nanostack-interface/Nanostack.cpp

@@ -648,6 +648,18 @@ nsapi_size_or_error_t Nanostack::do_sendto(void *handle, const ns_address_t *add
     * */
    if (retcode == NS_EWOULDBLOCK) {
        ret = NSAPI_ERROR_WOULD_BLOCK;
+    } else if (retcode == -1) {


Feels like this is getting to the point it should be a switch statement for the error cases, although I guess you still need an if for the < 0.

Yes, that's why I stayed with it if-else statements.

Just a tad wary that the compiler will end up doing all the comparisons in the order specified. Compilers are generally good at spotting how to break a switch up into ranges and figuring out when to do a branch table, and when to do binary chop, but I'm not sure how good they are at optimising an if-else chain on 1 variable.

At least make the non-error case the first, if going down this route, for speed.

It might be time to use a non-conventional if-else-switch control construct:

if (retcode >= 0) { ret = retcode; } else switch (retcode) { case -1: ret = NSAPI_ERROR_PARAMETER; break; ... default: tr_error(); ret = NSAPI_ERROR_DEVICE_ERROR; break; }

(Would look neater if Mbed OS style didn't insist on the extra switch indent).

kjbracey · 2019-04-16T11:47:24Z

features/nanostack/nanostack-interface/Nanostack.cpp

-        tr_error("socket_sendmsg: error=%d", retcode);
-        ret = NSAPI_ERROR_DEVICE_ERROR;
-    } else {
+    if (retcode >=0 ) {


Stray space that the formatter will likely complain about

Translate errors to NSAPI_ERROR_*, instead of always returning NSAPI_ERROR_DEVICE_ERROR

mbed-ci · 2019-04-17T11:25:35Z

Test run: FAILED

Summary: 1 of 11 test jobs failed
Build number : 2
Build artifacts

Failed test jobs:

jenkins-ci/mbed-os-ci_greentea-test

michalpasztamobica · 2019-04-17T11:29:05Z

Failures are in components-storage-blockdevice-component_sd-tests-* , rather irrelevant for this PR.

0xc0170 · 2019-04-17T11:33:55Z

Test restarted

adbridge · 2019-04-25T15:25:00Z

ci started

mbed-ci · 2019-04-26T02:58:54Z

Test run: SUCCESS

Summary: 11 of 11 test jobs passed
Build number : 3
Build artifacts

adbridge · 2019-04-26T10:17:12Z

Marking this for 5.13 as it looks like an interface change to me. @michalpasztamobica could you please also add a release notes section to the header explaining the impact to the user.

michalpasztamobica · 2019-04-26T11:02:05Z

@adbridge , I would say this is more of a fix - after all the function call looks the same and the return type does not change either. We only fix the code to return appropriate error values.

I will leave it up to you to decide - the Release Note is added.

adbridge · 2019-04-26T11:24:03Z

@michalpasztamobica My concern would be that if a user of the interface is just expecting to receive the one previous error code but now could get multiple different ones, their application could fail ?

michalpasztamobica · 2019-04-26T11:30:32Z

@adbridge , I misunderstood "interface change" to be a PR that will actually change the API (like add a new function, a parameter or change return type). But giving it a second thought - you are right: anything that can become an annoyance to the users better be communicated clearly in the release notes.

SeppoTakalo · 2019-04-29T09:31:19Z

Application that expects certain kind of errors, sound a bit unstable in a first place.

Being portable, application should be able to fail gracefully in any error, and work normally between all connectivities we offer.

To me this change brings clarify to Nanostack's error codes, but Anna's concern is valid, and we should therefore release this only in 5.13.

michalpasztamobica changed the title ~~Nanostak: translate errors from sendmsg~~ Nanostack: translate errors from sendmsg Apr 16, 2019

SeppoTakalo reviewed Apr 16, 2019

View reviewed changes

SeppoTakalo approved these changes Apr 16, 2019

View reviewed changes

ciarmcom requested review from KariHaapalehto, kjbracey, SeppoTakalo, VeijoPesonen and a team April 16, 2019 09:00

ciarmcom added the needs: review label Apr 16, 2019

kjbracey reviewed Apr 16, 2019

View reviewed changes

michalpasztamobica force-pushed the nanostack_translate_sendmsg_errors branch from 69083d4 to eb74e45 Compare April 16, 2019 11:44

kjbracey approved these changes Apr 16, 2019

View reviewed changes

Nanostack: translate errors from sendmsg

d1d0118

Translate errors to NSAPI_ERROR_*, instead of always returning NSAPI_ERROR_DEVICE_ERROR

michalpasztamobica force-pushed the nanostack_translate_sendmsg_errors branch from eb74e45 to d1d0118 Compare April 16, 2019 12:04

0xc0170 approved these changes Apr 18, 2019

View reviewed changes

adbridge added needs: CI and removed needs: review labels Apr 25, 2019

adbridge added ready for merge release-version: 5.13.0-rc1 and removed needs: CI labels Apr 26, 2019

adbridge merged commit 9f18456 into ARMmbed:master Apr 26, 2019

adbridge removed the ready for merge label Apr 26, 2019

michalpasztamobica deleted the nanostack_translate_sendmsg_errors branch September 16, 2019 14:00

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Nanostack: translate errors from sendmsg #10410

Nanostack: translate errors from sendmsg #10410

michalpasztamobica commented Apr 16, 2019 •

edited

Loading

SeppoTakalo Apr 16, 2019

michalpasztamobica Apr 16, 2019

SeppoTakalo Apr 16, 2019

kjbracey Apr 16, 2019

ciarmcom commented Apr 16, 2019

kjbracey Apr 16, 2019

kjbracey Apr 16, 2019

michalpasztamobica Apr 16, 2019

kjbracey Apr 16, 2019

michalpasztamobica Apr 16, 2019

kjbracey Apr 16, 2019

mbed-ci commented Apr 17, 2019

michalpasztamobica commented Apr 17, 2019

0xc0170 commented Apr 17, 2019

adbridge commented Apr 25, 2019

mbed-ci commented Apr 26, 2019

adbridge commented Apr 26, 2019

michalpasztamobica commented Apr 26, 2019

adbridge commented Apr 26, 2019

michalpasztamobica commented Apr 26, 2019

SeppoTakalo commented Apr 29, 2019

Nanostack: translate errors from sendmsg #10410

Nanostack: translate errors from sendmsg #10410

Conversation

michalpasztamobica commented Apr 16, 2019 • edited Loading

Description

Pull request type

Reviewers

Release Notes

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ciarmcom commented Apr 16, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mbed-ci commented Apr 17, 2019

michalpasztamobica commented Apr 17, 2019

0xc0170 commented Apr 17, 2019

adbridge commented Apr 25, 2019

mbed-ci commented Apr 26, 2019

adbridge commented Apr 26, 2019

michalpasztamobica commented Apr 26, 2019

adbridge commented Apr 26, 2019

michalpasztamobica commented Apr 26, 2019

SeppoTakalo commented Apr 29, 2019

michalpasztamobica commented Apr 16, 2019 •

edited

Loading