nrf9x_socket_offload_close not releasing context if nrf_close fails

[Nicholas Braaten]

I don't know if there is a bug in either nrf9x_socket_offload_close, nrf_close, or our usage of the modem.

It seems to be that if we power off the modem and deinitialise the modem-library, and afterwards reinitialise the modem and the libary there seems to be a problem if we in other parts of the application tries to close a socket.

When calling zsock_close, nrf9x_socket_offload_close will call nrf_close, but nrf_close returns -1 with errno=EBADFS. That results in nrf9x_socket_offload_close not releasing the context. The real problem with that happens afterwards when we open the socket again, but the socket events doesnt work. Currently we have a workaround by wrapping nrf_close to return 0 if errno=EBADFS.

Is that a bug or do we do something "illegal" in our implementation? Sometimes we restart the modem if we lose connect to the network, but that could probably be handled differently.

[Håkon Alseth]

Hi,

 

I don't know if there is a bug in either nrf9x_socket_offload_close, nrf_close, or our usage of the modem.

It seems to be that if we power off the modem and deinitialise the modem-library, and afterwards reinitialise the modem and the libary there seems to be a problem if we in other parts of the application tries to close a socket.

file descriptors are maintained by zvfs:

https://github.com/nrfconnect/sdk-nrf/blob/main/lib/nrf_modem_lib/nrf9x_sockets.c#L1135

If you do not close your sockets before de-initing the library, nrf_close() will return with non-zero after you've re-inited libmodem, and the zvfs socket is then leaked/not free'd.

 

I would recommend that you close your sockets before deiniting the modem/libraries, as a part of your shutdown routine.

 

Kind regards,

Håkon