Calls to MQTT Library Hang Indefinitely

[ethanbarry]

I was going to open an issue, but the bug report template suggests opening a discussion first.

I have an application derived from the MQTT publisher example, and I'm using an nRF9160 cellular modem with the following config options:

CONFIG_MODEM_SOCKET=y
CONFIG_NET_SOCKETS_OFFLOAD=y

I reported this at Nordic's site, and they suggested asking here.

The problem is that occasionally a call inside the MQTT library will block indefinitely, and control never returns to my application. This is usually zsock_sendmsg(), called from mqtt_client_tls_write_msg(), but it can also be one of the other zsock_*() functions (I added log statements to check this).

If a socket does not receive a close signal, or encounters some similar issue, it would remain in a waiting state indefinitely according to the BSD sockets spec. However, this will never return control to the application, and in an environment where the network is guaranteed to be unreliable, this feels like an issue.

How can I avoid or reconfigure this?

[jukkar]

Cc: @rlubos

[rlubos]

To be fair I'm not so convinced the issue is on the library side. If I understand correctly, in your case it's one of the zsock_send() (which is part of MQTT connect) or zsock_sendmsg() calls that block. But as you're using socket offloading, the whole socket operation is delegated to 3rd party socket implementation (nRF91 sockets in this case), which is a black box, so I can't really tell what's happening inside. And send calls blocking indefinitely sounds very fishy, even in unreliable network, it's TCP underneath after all, the connection should be aborted if it can't send send any data (or get acknowledgment).

But anyway, the only thing I can think of to try to improve this on the library side is to configure TX timeout on the socket to some arbitrary value and see if it helps:

diff --git a/subsys/net/lib/mqtt/mqtt_transport_socket_tls.c b/subsys/net/lib/mqtt/mqtt_transport_socket_tls.c
index a33cee5aecf..b06adc0b1c9 100644
--- a/subsys/net/lib/mqtt/mqtt_transport_socket_tls.c
+++ b/subsys/net/lib/mqtt/mqtt_transport_socket_tls.c
@@ -106,6 +106,17 @@ int mqtt_client_tls_connect(struct mqtt_client *client)
                peer_addr_size = sizeof(struct sockaddr_in);
        }
 
+       struct timeval timeo_optval = {
+               .tv_sec = 30,
+               .tv_usec = 0,
+       };
+
+       ret = zsock_setsockopt(client->transport.tls.sock, SOL_SOCKET, SO_SNDTIMEO,
+                              &timeo_optval, sizeof(timeo_optval));
+       if (ret < 0) {
+               goto error;
+       }
+
        ret = zsock_connect(client->transport.tls.sock, client->broker,
                            peer_addr_size);
        if (ret < 0) {

If this works out we can add TX timeout configuration to the mqtt client, but if the socket still blocks after this, I would highly suspect it's rather something on the modem side.

[ethanbarry]

Funny you suggest that—setsockopt() was the first thing I tried. :D I also suspect it's the offloaded socket implementation causing issues. Nordic has a separate nrf_setsockopt() function, but I don't think I can access it in the library code. I'll give that a shot, or see whether I can get by without socket offloading somehow.

I'll take the issue back to Nordic now. Thanks for the help!