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]

Hi Didrik,

Thank you for the quick reply.

I seem to have forgotten to copy some information, here is the output of AT+CGDCONT along with the others listed above.

%XSYSTEMMODE: 1,0,1,0
+CGDCONT: 0,"IPV6","ims","0000:0000:0000:0000:0000:000F:3752:C101",0,0
+CGPADDR: 0,"0000:0000:0000:0000:0000:000F:3752:C101"
+CGCONTRDP: 0,,"ims","","",,,,,,,1500

With the SYSTEMMODE response, it appears to be in LTE-M1 mode.

Should I be able to connect to an IPV4 address if I received an IPV6 address? Will DNS resolutions work correctly?

Are IPV4 and IPV6 DNS servers the same?

I may have to modify the SLM application to provide a way to add DNS addresses by hand.

One more concern, it appears the three dev kit boards I received are engineering samples, I am not sure where the company purchased them from.  Digikey was out of stock and they found another source.  DIgikey is back in stock now though.
The markings on the SiP are as follows:
nRF9160-SCA
BAA-E2.1.5
11LKK

Can you confirm this? I was able to update the firmware to 1.2.3 so it seems to be okay as long as there are no issues in the silicon for this hardware version.  I also have an Actinius Icarus IoT board here, it should have something more recent in it:
nRF9160-SCA
B0
2013E7

Thank you for your assistance!

[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

[Didrik Rokhaug]

I looked through the SLM implementation, and it does not look like the TCP socket commands supports IPv6, but always assumes IPv4.

Could you try to use the HTTP commands instead, as they seem to handle IPv6 as well?

It that works, the problem is the missing IPv6 support in the TCP commands. If it still doesn't work, setting the DNS server might be necessary.

 

aldras said:

Should I be able to connect to an IPV4 address if I received an IPV6 address? Will DNS resolutions work correctly?

As far as I know, most networks supports routing of IPv4 packets over IPv6, so you should still be able to use IPv4 even if you have an IPv6 connection to the APN.

DNS also works over IPv6, so that should not be a problem.

But, in the TCP socket commands, they currently only handle IPv4 addresses, and if the address returned from the DNS lookup does not match an IPv4 address, it will be dropped.

 

aldras said:

it appears the three dev kit boards I received are engineering samples

 Yes, that is an engineering sample. You can find the erratas for that version here: nRF9160 Engineering A Errata.

Also, that means you have an old DK version, so you might be affected by this errata: nRF9160DK Errata

So the DK and SiP should not be used for any power or (especially GPS) performance measurements.

So the best would be to get a new DK.

But, while it is not really suitable for performance measurements, it should be fine to use it for developments.

[aldras]

Hi Didrik,

Thank you for the reply and the above answers.

I attempted the following commands first to the SIM that retrieves an IPv4 address, then to the SIM that retrieves an IPv6 address.

These are the commands that I used.

AT+CGMR
AT+CGPADDR
AT+CGDCONT?
AT+CGCONTRDP=0

AT#XHTTPCCON=1,"google.com",80
AT#XHTTPCREQ="GET","/get?foo1=bar1&foo2=bar2",""
AT#XHTTPCCON=0,"google.com",80

AT#XHTTPCCON=1,"172.217.161.196",80
AT#XHTTPCREQ="GET","/get?foo1=bar1&foo2=bar2",""
AT#XHTTPCCON=0,"172.217.161.196",80

Here are the results, first the IPv4 card, prefixed with some other network information.

AT+CGMR
mfw_nrf9160_1.2.3
OK
AT+CGPADDR
+CGPADDR: 0,"100.64.163.216"
OK
AT+CGDCONT?
+CGDCONT: 0,"IP","iijmio.jp","100.64.163.216",0,0
OK
AT+CGCONTRDP=0
+CGCONTRDP: 0,,"iijmio.jp","","","202.232.2.2","202.232.2.3",,,,,1500
OK
AT#XHTTPCCON=1,"google.com",80
#XHTTPCCON:1
OK
%CESQ: 61,3,19,2
%CESQ: 60,3,24,3
AT#XHTTPCREQ="GET","/get?foo1=bar1&foo2=bar2",""
OK
#XHTTPCREQ:0
#XHTTPCRSP:576,1
HTTP/1.1 301 Moved Permanently
Location: www.google.com/get
Content-Type: text/html; charset=UTF-8
X-Content-Type-Options: nosniff
Date: Sat, 09 Jan 2021 14:03:57 GMT
Expires: Sat, 09 Jan 2021 14:33:57 GMT
Cache-Control: public, max-age=1800
Server: sffe
Content-Length: 247
X-XSS-Protection: 0
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>301 Moved</TITLE></HEAD><BODY>
<H1>301 Moved</H1>
The document has moved
<A HREF="">www.google.com/get
</BODY></H#XHTTPCRSP:6,0
TML>
AT#XHTTPCCON=0,"google.com",80
#XHTTPCCON:0
OK
AT#XHTTPCCON=1,"172.217.161.196",80
#XHTTPCCON:1
OK
AT#XHTTPCREQ="GET","/get?foo1=bar1&foo2=bar2",""
OK
#XHTTPCREQ:0
#XHTTPCRSP:576,1
HTTP/1.1 404 Not Found
Content-Type: text/html; charset=UTF-8
X-Content-Type-Options: nosniff
Date: Sat, 09 Jan 2021 14:04:15 GMT
Server: sffe
Content-Length: 1588
X-XSS-Protection: 0
<!DOCTYPE html>
<html lang=en>
<meta charset=utf-8>
<meta name=viewport content="initial-scale=1, minimum-scale=1, width=device-width">
<title>Error 404 (Not Found)!!1</title>
<style>
*{margin:0;padding:0}html,code{font:15px/22px arial,sans-serif}html{background:#fff;color:#222;padding:15px}body{margin:7% auto 0;max-width:390px;min-height:180px;padding:30px 0 15px}* > #XHTTPCRSP:576,1
body{background:url(//www.google.com/images/errors/robot.png) 100% 5px no-repeat;padding-right:205px}p{margin:11px 0 22px;overflow:hidden}ins{color:#777;text-decoration:none}a img{border:0}@media screen and (max-width:772px){body{background:none;margin-top:0;max-width:none;padding-right:0}}#logo{background:url(//www.google.com/images/branding/googlelogo/1x/googlelogo_color_150x54dp.png) no-repeat;margin-left:-5px}@media only screen and (min-resolution:192dpi){#logo{background:url(//www.google.com/images/branding/googlelogo/2x/googlelogo_color_150x54dp.png) no-repeat 0% #XHTTPCRSP:576,1
0%/100% 100%;-moz-border-image:url(//www.google.com/images/branding/googlelogo/2x/googlelogo_color_150x54dp.png) 0}}@media only screen and (-webkit-min-device-pixel-ratio:2){#logo{background:url(//www.google.com/images/branding/googlelogo/2x/googlelogo_color_150x54dp.png) no-repeat;-webkit-background-size:100% 100%}}#logo{display:inline-block;height:54px;width:150px}
</style>
<a href=//www.google.com/><span id=logo aria-label=Google></span></a>
<p><b>404.</b> <ins>That’s an error.</ins>
<p>The requested URL <code>/get?foo1=bar1&amp;foo2=bar2</code> was not fou#XHTTPCRSP:53,0
nd on this server. <ins>That’s all we know.</ins>
AT#XHTTPCCON=0,"172.217.161.196",80
#XHTTPCCON:0
OK

Now the same commands with the IPv6 SIM card

AT+CGMR
mfw_nrf9160_1.2.3
OK
AT+CGPADDR
+CGPADDR: 0,"0000:0000:0000:0000:0000:0035:B7B2:D201"
OK
AT+CGDCONT?
+CGDCONT: 0,"IPV6","ims","0000:0000:0000:0000:0000:0035:B7B2:D201",0,0
OK
AT+CGCONTRDP=0
+CGCONTRDP: 0,,"ims","","",,,,,,,1500
OK
AT#XHTTPCCON=1,"google.com",80
#XHTTPCCON:0
ERROR
AT#XHTTPCREQ="GET","/get?foo1=bar1&foo2=bar2",""
ERROR
AT#XHTTPCCON=0,"google.com",80
ERROR
AT#XHTTPCCON=1,"172.217.161.196",80
%CESQ: 61,3,19,2

It this point the nRF9160 appears to hang and needs a hard reset to recover, that or it is waiting for something and not responsive to AT commands.  Even while it is hung the %CESQ: 61,3,19,2 continues to be sent from the nRF9160.

I is running the serial_lte_modem application, unmodified from the v1.4.1 SDK.
There is a v1.4.99-dev1 version, but because of the word "dev" it appears it is not yet stable and in development.

Is there any other information that I provide that might help troubleshoot this issue?

I would like to see what is going on inside the modem, is there a way to see a debug output of the modem during the connection process?  I found a "trace collector" but I can't make sense of is captured, it appears a binary dump of sorts.

Is it possible that the APN is incorrect?  The APN information appears to be stored in the nRF9160 since I do not have to enter it.  This is for the "KDDI by au" network in Japan.  Although this is an MVNO SIM chip, I am not sure of the MVNO company.  I can try to search on portions of the number printed on the SIM card, maybe a portion of that number specifies the MVNO company.

[Didrik Rokhaug]

aldras said:

There is a v1.4.99-dev1 version, but because of the word "dev" it appears it is not yet stable and in development.

 The dev tag is better tested than other commits on the master branch, but not as much as a "proper" release.

This dev tag is primarily for the nRF5340, and I don't think there are any changes that are relevant for us in this case.

 

aldras said:

I would like to see what is going on inside the modem, is there a way to see a debug output of the modem during the connection process?  I found a "trace collector" but I can't make sense of is captured, it appears a binary dump of sorts

 Unfortunately, that is not possible at the moment. We are working on a tool for our customers to gain some insight on what is happening on the modem side, but I cannot comment on when that will be available.

For now, you will have to send the traces to us for analysis.

 

aldras said:

Is it possible that the APN is incorrect?

 The network usually provides the APN, so I assume that it is correct. However, you could try to contact your network provider (those you got the SIM from), and ask.

---

As you weren't able to connect using the HTTP commands either, it doesn't seem to be just a IPv4 vs IPv6 problem.

Can you send me the modem trace you took?

That should tell us where it went wrong in both the DNS lookup, and the direct IP address cases.