DNS issues when roaming when using multi-IMSI SIM

Hi - I have encountered an issue that occurs when roaming and using a multi-IMSI SIM card. 

Everything seems to work fine when using a local network (ex: Rogers here in Canada). 

Things also work most of the time (for weeks) when using an IoT Connectivity partner with a multi-IMSI SIM card. Note that when using this multi-IMSI SIM card, I am roaming using a IMSI from an EU Operator. After a few weeks of operation, we develop an issue where we can not connect to AWS. 

When this occurs, we can tell from the Wireshark logs (from our connectivity supplier), we see that UE is sending the DNS requests for AWS and the DNS server responds BUT immediately after, the UE sends another DNS request. I am thinking that the timeout for DNS requests is too short?  I was going to try to prove this OR test with longer DNS timeout but I don't see where I can make this change. 

Can you tell me if there is a way to increase the DNS timeout?

Note that in our application we are using the Nordic LTE Connection manager and the AWS libraries. I have also notice that the offloading of the sockets/networking is enabled in the prj.conf file with the following statements: 

# Network
CONFIG_NETWORKING=y
CONFIG_NET_NATIVE=n
CONFIG_NET_SOCKETS_OFFLOAD=y
CONFIG_NET_SOCKETS=y
CONFIG_NET_SOCKETS_POSIX_NAMES=y
CONFIG_NET_SOCKETS_CONNECT_TIMEOUT=10000
We are using SDK version 1.9.0 and considering upgrading to the latest version but would like to fix this fix to buy some development/integration time. 
I see from another ticket that a developer discovered that the DNS timeout is 1 second for the first try and then 3? seconds for subsequent retries.
I tried to dig into the nrf offload code but had find the source for nrf_getaddrinfo();

 Can you tell me: 
1) Any thoughts on this issue? Have you seen this before? 
2) Is there a way to change the DNS timeout in the nrf offloaded sockets solution?
3) Maybe a dumb question but why I can't find the source for nrf_getaddrinfo() ? I see the calls to it from nrf91_sockets.c but I can't find the source for nrf_getaddrinfo. 
Note: I am a unclear why the previous developer decided to use sockets_offload but I am afraid to disable it without having any history on this aspect of the system. 
Thanks in advance. 
  • Due to holiday season (Easter) in Norway, we are a bit low in staff. The expert who could answer this is OoO and will be back after Easter. Sorry for the delays and thanks for your patience in advance. Happy Easter.
  • It's too bad that the SME wasn't able to comment on this ticket before going OoO. We have lost a week on this issue that  is impacting our field trials and deployment. I ask that when the Engineer returns from OoO that he/she look at the question ASAP. 

    Thanks

  • Hello,

    Could you tell me the modem FW version as well?

    I am consulting the experts on the main question currently, but I can answer question 3) now at least:

    3) Maybe a dumb question but why I can't find the source for nrf_getaddrinfo() ? I see the calls to it from nrf91_sockets.c but I can't find the source for nrf_getaddrinfo. 

    It is a part of the modem library which is only distributed as a closed-source compiled library.

    Best regards,

    Michal

  • We are using modem firmware version 1.3.1 and SDK version 1.9.0

    I was guessing that the code for the offloaded sockets was in binary only and perhaps resides in the modem firmware. I couldn't figure out how those symbols got resolved for the linker but obviously you guys do. 

    I am wondering if I should use the standard networking sockets stack instead of the offloaded version. Is there any documentation on pros and cons of either implementation? 

    I am also wondering if the our code calls aws_iot_connect() multiple times, would the AWS code  also perform multiple DNS requests ? I am looking to see if we have a bug in our application where multiple aws_iot_connects() are called when trying to restore service after a disconnect. 

    If aws_iot_connect() statefull then I wouldn't expect multiple DNS requests to be performed. 

Related