getaddrinfo in can block indefinitely after LTE connect

[jlangballeswift]

Hi,

I observed what appears to be the same issue as https://devzone.nordicsemi.com/f/nordic-q-a/51337/nrf9160-infinite-nrf_connect-blocking-behavior-post-lte-psm-wakeup/. In my use-case however, I am not using PSM and instead just switch the modem between offline (CFUN=4) and online (CFUN=1).

I'm using code copied from the mqtt_simple sample. First I switch the modem online, connect LTE, wait for the AT response indicating the connection was successful, and then I connect MQTT using the mqtt_simple code. Occasionally I will hang on the getaddrinfo call in broker_init.

I was wondering if there is any new information since the last devzone post I have linked or if there is another, safer way of initializing and connecting MQTT that won't hang.

Thanks,

Jeff

[johnwest]

Didrik Rokhaug

Didrik,

What is the timeout on getaddrinfo()?  Has a retry mechanism been added (lately) with a different timeout?  I suppose I could grep the zephyr codebase and find this someplace.  Is it possible the retry can deadlock?

Thanks,
John W.

[Didrik Rokhaug]

Hi John,

johnwest said:

What is the timeout on getaddrinfo()?

I am not quite sure myself, but you should be able to test this out yourself. With the Trace Collector V2 Preview, you should be able to inspect the IP traffic in a modem trace yourself.

We don't have any proper documentation for it yet (but it should be pretty self explanatory), but here is a guide on how to take a modem trace with the Trace Collector v1. It is the same steps on the device side. https://infocenter.nordicsemi.com/topic/ug_trace_collector/UG/trace_collector/intro.html 

johnwest said:

Has a retry mechanism been added (lately) with a different timeout?

I am not aware of any changes to getaddrinfo's behaviour.

johnwest said:

I suppose I could grep the zephyr codebase and find this someplace.

I expect that you are using the network stack in the modem, which is different from the one in Zephyr. So this will not give you anything useful.

johnwest said:

Is it possible the retry can deadlock?

Not that I am aware of. The modem FW has also been very thoroughly, so I would consider it unlikely.

Best regards,

Didrik

[Didrik Rokhaug]

Didrik Rokhaug said:

johnwest said:

What is the timeout on getaddrinfo()?

I am not quite sure myself, but you should be able to test this out yourself. With the Trace Collector V2 Preview, you should be able to inspect the IP traffic in a modem trace yourself.

I managed to stumble over the answer: "Modem has four re-transmissions for DNS query. Timeout for first DNS request is 1 second and timeout for second, third and fourth DNS request is 3 seconds."