Is there a way to bound/timeout nrf_getaddrinfo() DNS resolution on nRF91?

[Peter Horauer]

SDK / HW info:
- nRF Connect SDK v3.3.0 (migrating to 3.4.0_LTS soon)
- Modem firmware: mfw_nrf91x1_2.0.4
- Boards: nRF9151 DK + custom nrf9151 board which uses a very similar skimmed devicetree to nrf9151dk (both .../nrf9151/ns)

What we're trying to do: A UART-to-cellular gateway where each command carries a single caller-supplied timeout (1–180s) 
meant to bound the whole operation (resolve → connect → send/recv) end-to-end. send()/recv() are correctly bounded via 
SO_SNDTIMEO/SO_RCVTIMEO. The DNS step (getaddrinfo(), offloaded via nrf9x_socket_offload_getaddrinfo() straight into 
nrf_getaddrinfo()) has no such bound.

As getaddrinfo() is used to create a socket it is logical that a SO*TIMEO is not usable.

Questions:

1. Any supported way (AT command / nrf_setsockopt() option / Kconfig) to bound nrf_getaddrinfo()'s worst-case blocking time?
2. If not, a documented/typical worst-case to design around?
3. If genuinely unbounded today, is a timeout option planned, or is app-level work-queue + watchdog (accepting the modem 
   call itself can't be cancelled) the recommended pattern?

Current workaround: run it on our own work queue with a generous task-watchdog backstop purely to catch a truly stuck call 
(reboot recovery) — not a real bound, since we can't cancel nrf_getaddrinfo() itself.

[Håkon Alseth]

Hi,

 

We follow the POSIX standard for socket operations, which includes getaddrinfo().

Your current workaround, ie. to run getaddrinfo() in a dedicated thread/priority, is the recommended overall workaround in general for a "non-blocking" operation specifically for DNS lookup.

 

What I can recommend is to monitor the network connection prior to starting the IP-related process, for instance by issuing AT%CONEVAL:

https://docs.nordicsemi.com/r/bundle/ref_at_commands_nrf91x1/page/ref/at_commands/mob_termination_ctrl_status/coneval.html

 

This will give a better overview of the conditions before any socket related operation.

 

Kind regards,

Håkon

[Peter Horauer]

Is there a maximum bound for the getaddrinfo to time out at all? For example it pushes the RRC into Connected and times out when Network timer is called and the RRC is set to idle?

Because breaking the non-blocking operation before it returned would still leave the modem core trying to fetch the DNS resolution even tough the Application just disregards it at that point.

[Håkon Alseth]

Hi,

 

Peter Horauer said:

Is there a maximum bound for the getaddrinfo to time out at all?

Not directly, no. If the network goes down or is no longer available, a return code of ENETDOWN will be returned for instance, but it shall not block indefinitely.

Peter Horauer said:

For example it pushes the RRC into Connected and times out when Network timer is called and the RRC is set to idle?

Any active socket operation that triggers a transmission will wake up the device from eDRX/DRX/PSM, and connect to the network.

You can in this scenario roam to a new cell tower if your device has moved a significant distance, and continue normal operation (given that the roaming handover in general was successful).

 

Peter Horauer said:

Because breaking the non-blocking operation before it returned would still leave the modem core trying to fetch the DNS resolution even tough the Application just disregards it at that point.

This is a sequential operation, meaning if the DNS has not returned anything; the overall connection is unable to continue. This will also be event driven in the socket offloading, so the only thread being blocked/waiting is the one where getaddrinfo() was called at that point.

Please note that if you plan to add timeout logic; you should remember that if getaddrinfo() returns successfully, a freeaddrinfo() shall be called to avoid leaking memory.

 

Kind regards,

Håkon