mfw_nrf9160_1.3.2.zip - behavior change on lost network?

[Achim Kraus]

I update a couple of device to mfw_nrf9160_1.3.2.zip.

Before that (1.3.1), my experience was to get a ENETDOWN, when calling "sendto" while the device has lost some the network. (It's a little more complicated. If the device is in PSM, the first call of "sendto" returns SUCCESS. Afterwards the modem wakesup and the tries to connect to the network. In some cases, when a "(re)-sendto" is then required, that fails with an error and in my experience.)

Now, with 1.3.2 it seems to report ESHUTDOWN.

Though this only happened in rare cases, I'm not sure, if this is an change, or I'm juts not aware of it with the 1.3.1.

I read the release_notes_modemfirmware but I can't find that mentioned.

Though testing of such rare exceptions isn't that easy, it would help a lot, if nordic provides a list of the possible reported error codes in the case of lost network connectivity.

(I also updated to ncs-2.0.0, before I used ncs-1.9.1, may be it's also a change there.)

[Hakon]

Hello,

I have asked the modem team to comment on this.

[Achim Kraus]

Thanks!

In the meantime I got also ENETUNREACH.

I'm not sure, if I tested the 1.3.1 too lazy (by the way, more then for 3 weeks with th3 1.3.1), or if that has changed.

[Hakon]

Modem team;

Changes are likely related to new modem library rather than new modem firmware.

ESHUTDOWN means - Modem was shutdown. That means, either the application shut down the modem or the modem has crashed.
ENETDOWN still means - PDN was deactivated. Socket must be destroyed and re-created (and optionally reconnected).

ESHUTDOWN return value is documented in the send()/sendto() function doxygen in the nrf_socket.h header.

[Achim Kraus]

Thanks for refer to "nrf_socket.h".

The diff between v1.9 branch and the v2.0 branch is:

v1.9

@return The number of bytes that were sent on success.
        -1 on error, and errno indicates the reason for failure.

v2.0

In addition, the function shall return -1 and set the following errno:
[NRF_ESHUTDOWN] Modem was shut down.

So the left question for me is, what are the users/developers considered to do on such an update. Trying to compare the documentation? Really?

[Hakon]

Modem team;

"Before that (1.3.1), my experience was to get a ENETDOWN, when calling "sendto" while the device has lost some the network"
This behavior is unchanged.

If the customer sees ESHUTDOWN is because of another reason, that is, the sendto() call was interrupted because the Modem was turned off by an application call to nrf_modem_lib_shutdown().

[Achim Kraus]

> So the left question for me is, what are the users/developers considered to do on such an update. Trying to compare the documentation? Really?

I'm only evaluating the nRF9160.

Anyway, the answer on how such updates should be handled by users is not that irrelevant. At least I consider the "network reconnect/search" as critical for products.

There are also related issues pointing into that direction:

How to recover a nRF9160 from sporadic ENETDOWN

LTE-M Reconnect after LoS

Maybe, there are better ideas than using the errno. If so, maybe they get documented

(Just mention: I know it's summer, and for now my stuff runs again. But maybe over the next month Nordic considers to document the ideas to implement such a "save reconnect".)

Other issues, caused by unaware changes with the update from 1.9.1 to 2.0.0:

upgrade sdk 1.9.1 to 2.0.0

So, I can only recommend, that the "change notes" may get more complete.