nRF9160: not retrieving DNS servers with IPV6

[aldras]

I am currently working on a project with a nRF9160 and in the very early stages of evaluation.

I have a few, hope not too many questions that I hope can be answered here, if it is not too much trouble.
I am starting fresh with the nRF9120SK, but do have prior experience with the nRF51 and nRF52 chips, though it was several years ago, the development environments were quite different, especially with the added Zephyr libraries.  Ultimately this project might be implemented as a serial_lte_modem using another MCU that handles the main logic of the device.

I have been searching on these forums and internet search engines today and yesterday quite a bit and have a few unresolved questions.

Using a macOS Big Sur development environment, I can go into specifics but it is not related to the current question.
I am currently using the example at
/opt/nordic/ncs/v1.4.1/nrf/applications/serial_lte_modem

Built with the command
west build -b nrf9160_pca10090ns

Is there a difference between these two commands?  Does it result in the same build?
west build -b nrf9160_pca10090ns
west build -b nrf9160dk_nrf9160ns

I am using the SDK version v1.4.1, modem software version 1.2.3 (I had some trouble updating it, it was in a very early 0.6.x.x-alpha state when I received the PCB).
Following this guide
https://devzone.nordicsemi.com/f/nordic-q-a/53208/updating-nrf9160-modem-firmware-through-the-command-line
I was able to bring it up to date after a few hours of frustration.

If anyone is interested in how I brought this up to date I can share the procedure, but I had to use the python nrfjprog wrapper to do it.

I have a nRF9160DK and am using a MVNO SIM operating in Japan with KDDI by au.

I am going to provide the output of some commands so you can see the results.

It appears that this SIM only supports IPV6, is there such a thing?

Here is the output of some of the network information.

+CGPADDR: 0,"0000:0000:0000:0000:0000:004A:XXXX:9801" (removed some information for privacy)
+CGCONTRDP: 0,,"ims","","",,,,,,,1500

I have another SIM here (I have to manually set the APN) that retrieves an IPV4 address and DNS servers with the following output.

I have the following output with that SIM card, I have to use AT+CGDCONT=0,"IP","iijmio.jp" to set the APN before enabling the modem.

If you would like to add this SIM card to the list of automatically configured APNs please let me know, I am more than happy to provide details.

+CGDCONT: 0,"IP","iijmio.jp","XXX.XXX.123.XXX",0,0 (removed some information for privacy)
+CGCONTRDP: 0,,"iijmio.jp","","","202.232.2.2","202.232.2.3",,,,,1500

I am using this guide at 

https://developer.nordicsemi.com/nRF_Connect_SDK/doc/1.4.1/nrf/applications/serial_lte_modem/doc/slm_description.html

to test a connection to google.com.  I can connect fine with the second listed SIM card that retrieves an IPV4 address.

I can not connect with the first SIM that retrieves an IPV6 address, it has no DNS servers.

I found information that I can manually specify DNS servers, but I don't know how to do this with AT commands.

https://devzone.nordicsemi.com/f/nordic-q-a/50029/nrf9160-modem-firmware-v1-0-0-setting-custom-dns-server/235419#235419

[Didrik Rokhaug]

Hi,

 

Is there a difference between these two commands?  Does it result in the same build?

 The board name was changed from nrf9160_pca10090(ns) to nrf9160dk_nrf9160(ns).

For now, the two commands should be the same, but the old name (nrf9160_pca10090(ns)) will eventually be deprecated, so you should use nrf9160dk_nrf9160(ns).

 

It appears that this SIM only supports IPV6, is there such a thing?

 I can't remember hearing about such SIM at the moment, but it doesn't sound impossible. Your network provider should be able to answer the question.

What commands do you use to connect to google.com?

What is the response to AT+CGDCONT? when you use the "IPv6 SIM"?

Are you using LTE-M or NB-IoT?

 

I found information that I can manually specify DNS servers, but I don't know how to do this with AT commands.

 There are currently no way of doing this with AT commands.

Instead, you will have to modify the SLM application.

Best regards,

Didrik

[aldras]

I forgot to add the procedure I am using to connect to google.com, it is below, copied mostly from
https://devzone.nordicsemi.com/f/nordic-q-a/53208/updating-nrf9160-modem-firmware-through-the-command-line

AT#XSOCKET=1,1,0
#XSOCKET: 1, 1, 0, 6
OK

AT#XCONNECT="google.com",80
#XCONNECT: 1
OK
Send an HTTP request to the server.

AT#XSEND=1,"HEAD / HTTP/1.1"
#XSEND: 15
OK

AT#XSEND=0,"0D0A"
#XSEND: 2
OK

AT#XSEND=1,"Host: www.google.com:443"
#XSEND: 24
OK

AT#XSEND=0,"0D0A"
#XSEND: 2
OK

AT#XSEND=1,"Connection: close"
#XSEND: 17
OK

AT#XSEND=0,"0D0A0D0A"
#XSEND: 4
OK
Receive the response from the server.

AT#XRECV
HTTP/1.1 200 OK
Content-Type: text/html; charset=ISO-8859-1
[...]
#XRECV: 1, 576
OK

AT#XRECV
[...]
Connection: close
#XRECV: 1, 147
OK
Close the socket.

AT#XSOCKET=0
#XSOCKET: 0, closed
OK

[aldras]

Hi Didrik,

Ah, it occurred to me that perhaps the UART is not connected that is outputting the modem trace.

I was under the impression that there are three UARTs (uart0, uart1, uart2) on the nRF9160, but I only see UART1 and UART2 on the schematic for the nRF9160DK.  Which UART is the trace supposed to come out of?  I have not changed any jumpers or such on the board, but this is also an engineering sample version, perhaps there are some hardware differences?  I could not find detailed schematics for different board versions to compare.

Also I was not specific about which hex file I am programming, I am programming the merged.hex file, but that has never given me problems with the below command.

/usr/local/bin/nrfjprog -f NRF91 --program build/zephyr/merged.hex --sectorerase

[aldras]

Hi Didrik,

Ok I think I have a valid trace, this is modem firmware v1.2.3.

The problem I had is that the nRF Connect v3.6.1 - Trace Collector on MacOS does not connect to the correct serial device when "Auto device/port filter" is turned on.  I had to turn that off and manually connect to the third serial port.  Please let me know if this data is valid.

[Didrik Rokhaug]

Thanks. This last trace was valid.

It shows that the network doesn't provide a DNS address, which explains the failure when using the hostname.

The modem trace also shows that the modem tries to find neighboring routers with ICMPv6 router solicitation messages, but doesn't get any replies.

It also sends a TCP SYN packet to your server, but doesn't get any reply.

The TCP SYN packet is sent over IPv4. The modem uses the address 0.0.0.0, which indicates that it hasn't been provided with any IPv4 address by the network. This is probably why the server isn't able to respond, if the packet arrives at all.

Could you try to use the IPv6 address of the server, or use nrf_setdnsaddr() to set the DNS server manually?

The best place to add the call to nrf_setdnsaddr() is probably in start_execute(), right after the call to handle_bsd_lib_init_ret() in main.c.

---

I forgot to mention it in my last reply, but you should be able to upload files to devzone. You should find the option here:

[aldras]

Hi Didrik,

I'm glad that the trace data is valid, thank you for the insights.  You might mention to the team who takes care of the Trace Collector application on MacOS that it does not connect to the correct VCP device if "Auto device/port filter" is enabled.  I can also create a new ticket myself if that helps so it can be tracked in the ticket system.

I needed to manually select the third enumerated VCP device in order to collect the data.

I am doing more testing with this SIM card, and I am having similar trouble while testing in an iPhone, it does not retrieve an IP address.  We have a working phone at the office that successfully retrieves a valid IPv4 IP address, I don't know how it does it, I will have to look into it.

I am not sure what the IPv6 address of anything on the network is, I am not sure that the IPv6 address it is retrieving somehow is actually valid for anything, it might not even have a valid gateway, does it?

Since it retrieves an IPv4 address using the phone in the office (its a special use case Android based IoT smart phone) I am not sure that following this IPv6 is the correct route to resolve this issue.

I have identified two APNs from the iPhone, do you see the APN information in the trace?

These are the two APNs that I see, one is auto detected in the nRF9160.

This information was retrieved using the iPhone diagnonstics feature mentioned in this URL.

https://ios.gadgethacks.com/how-to/100-secret-dialer-codes-for-your-iphone-0161875/

Context 0 = uniz.au-net.ne.jp

Context 1 = IMS

Give me a little time to investigate and examine the working smart phone at the office and I will reply on this ticket within the next couple days.

Thank you for the assistance so far, it has been appreciated.  I am sure I am not the only one who might run into this issue with this specific SIM card so it would be good if we can trace the issue down and resolve it.

[Didrik Rokhaug]

aldras said:

I have identified two APNs from the iPhone, do you see the APN information in the trace?

 The trace shows that you are connected to ims:  +CGDCONT: 0,"IPV6","ims","0000:0000:0000:0000:0000:0027:5BE5:6E01",0,0\r\nOK\r\n

Note that the phone is using "regular" 4G LTE, while the nRF9160 is using LTE-M (Cat-M1).

[aldras]

Hi Didrik,

I finally got a hold of a device that works with the SIM chip in question above, of course it was an issue with the APN information.  Although I thought LTE did not require authentication, this SIM chip does, and so does another that I have.  Maybe authentication is still something used by providers in Japan?

It was not an IPv6 issue, this runs IPv4, and retrieves an IPv4 address.
For some reason the nRF9160 automatically retrieves the APN "ims" and that IPv6 address, I don't know why, but would be happy to share modem traces if you would like to try to track down the issue.  It is possible the network is providing this "ims" APN, but it is intentionally incorrect?

Anyway, for reference in addition to the AT+CGDCONT to set the APN, I also needed to use the AT+CGAUTH to set the authentication information.

Here is some information from the manual, I will copy here...

This is from this manual, I think it is not the current SDK, but this command appears to not have changed.
I changed a little of the information below, instead of using "PAP"/"CHAP" I put a 1 in place, and changed the CID number to 0.  I hope this information helps some other developers who run into needing to use authentication for their SIM chips.

infocenter.nordicsemi.com/.../nrf91_at_commands_v1.2.pdf

6.16 Define PDN connection authentication parameters
+CGAUTH
The +CGAUTH command specifies authentication parameters. For reference, see 3GPP 27.007 Ch. 10.1.31.
6.16.1 Set command
The set command specifies authentication parameters for a PDN connection specified by parameter <cid>.
Syntax:
+CGAUTH=<cid>[,<auth_prot>[,<userid>[,<password>]]]
The set command parameters and their defined values are the following:
<cid>
   0–11
<auth_prot>
   0 – None. Username and password are removed if they have been specified. 
   1 – PAP
   2 – CHAP
<userid>
   String
<password>
   String

The following command example sets authentication parameters for CID=0 context:
AT+CGAUTH=0,2,"username","password"

This resolves this issue, after all it was not a DNS issue, it was an issue of not supplying the correct APN information to the nRF9160.

It appears the nRF9160 can not automatically figure out these APN settings, if you would like to add this to the nRF9160 so it can correctly auto configure these devices please let me know and I will be more than happy to share information about the SIM chips that I run across during development.

I am leaving this case open for a little bit so this final message is seen, I will mark it as resolved soon.  

Thanks for all the support on this topic!