This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

NRF modem 1.1.1 firmware, 1.2 SDK. Re-using sockets causes hang in nrf_connect.

I'm porting a working app from SDK 1.1 to 1.2, and have noted that when I make an mqtt connection close it, and re-open (to a different mqtt server) that the call to nrf_connect hangs indefinitely.

The socket number is the same, which makes me think that when the first connection closes, it leaves something in a bad state.

The two separate mqtt connections work fine in isolation from each other, just not when the connections are made sequentially. (open, close, open)

Also, I've noted that when I modify the code to make both connections one after the other, forcing the use of another "new" socket for the second connection, things work fine.

This worked fine with modem firmware 1.1.1 and SDK 1.1, so it seems like it might be a new SDK 1.2 bug.

Parents
  • Thanks for the traces.

    , the modem trace is indeed valid this time, and it does look like we are seeing the same problem.

    , I could not see any signs of the error in your trace. Are you certain the trace captured the error?

    We are still working on identifying the source of the error, but it seems like it was introduced in bsdlib v6.1.

    If I use v6.0 instead, the error does not occur for me.

    You can revert to v6.0 by replacing the 1.2.0 revision of nrfxlib on line 72 in <ncs>/nrf/west.yml with 3e381d09f1d305e230435f5b6e4c9ef928b6a697, and running "west update".

  • This works fine, but I'm wondering when a proper fix will be forthcoming?

  • Hi.

    We have identified a problem in the modem as the source of this bug.

    As the problem is caused by enabling TLS session caching, the workaround until the modem problem is fixed is to not use TLS session caching.

    The reason for this problem to surface in NCS v1.2.0 is that the newest version of bsdlib enables TLS session caching by default.

    You can therefore either use the previous version of bsdlib (0.6.0), or you can disable TLS session caching using socket options:

    #include <nrf_socket.h>
    
    nrf_sec_session_cache_t session_cache = 0;
    
    nrf_setsockopt(socket, NRF_SOL_SECURE,
    
            NRF_SO_SEC_SESSION_CACHE, &session_cache,
    
            sizeof(session_cache));

    We are working on solving the problem in the modem.

    Best regards,

    Didrik

Reply
  • Hi.

    We have identified a problem in the modem as the source of this bug.

    As the problem is caused by enabling TLS session caching, the workaround until the modem problem is fixed is to not use TLS session caching.

    The reason for this problem to surface in NCS v1.2.0 is that the newest version of bsdlib enables TLS session caching by default.

    You can therefore either use the previous version of bsdlib (0.6.0), or you can disable TLS session caching using socket options:

    #include <nrf_socket.h>
    
    nrf_sec_session_cache_t session_cache = 0;
    
    nrf_setsockopt(socket, NRF_SOL_SECURE,
    
            NRF_SO_SEC_SESSION_CACHE, &session_cache,
    
            sizeof(session_cache));

    We are working on solving the problem in the modem.

    Best regards,

    Didrik

Children
No Data
Related