nRF9160: not retrieving DNS servers with IPV6

RE: nRF9160: not retrieving DNS servers with IPV6

aldras — Mon, 01 Feb 2021 12:47:46 GMT

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!

RE: nRF9160: not retrieving DNS servers with IPV6

Didrik Rokhaug — Fri, 15 Jan 2021 15:20:45 GMT

[quote user="aldras"]I have identified two APNs from the iPhone, do you see the APN information in the trace?[/quote]

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).

RE: nRF9160: not retrieving DNS servers with IPV6

aldras — Wed, 13 Jan 2021 17:50:06 GMT

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.

RE: nRF9160: not retrieving DNS servers with IPV6

Didrik Rokhaug — Wed, 13 Jan 2021 14:35:49 GMT

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:

RE: nRF9160: not retrieving DNS servers with IPV6

aldras — Tue, 12 Jan 2021 19:15:14 GMT

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.www.drassal.net/.../trace-2021-01-12T19-09-49.821Z.bin

RE: nRF9160: not retrieving DNS servers with IPV6

aldras — Tue, 12 Jan 2021 18:17:27 GMT

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

RE: nRF9160: not retrieving DNS servers with IPV6

aldras — Tue, 12 Jan 2021 17:43:14 GMT

I am not sure what is going on with by build, it is not outputting a trace it seems, do you have a prebuilt hex file that I can upload to it? Also please tell me which modem firmware I should run to match with it. I was on 1.2.3, downgraded to 1.2.2 to see if that was the issue. I have tried SDK 1.4.1 and 1.4.99 with the same results, here is the prj.conf file for the applications/serial_lte_modem application that I used to build with. Any recommendations? A different application perhaps?

If you can just provide me with a verified working hex file it should get things going also. Please tell me which modem firmware version I should use with it.

#
# Copyright (c) 2020 Nordic Semiconductor ASA
#
# SPDX-License-Identifier: LicenseRef-BSD-5-Clause-Nordic
#
# General config
CONFIG_LOG=y
CONFIG_LOG_DEFAULT_LEVEL=3
CONFIG_STACK_SENTINEL=y
CONFIG_NEWLIB_LIBC=y
CONFIG_NEWLIB_LIBC_FLOAT_PRINTF=y
CONFIG_RING_BUFFER=y

# Segger RTT
CONFIG_USE_SEGGER_RTT=y
CONFIG_RTT_CONSOLE=y
CONFIG_UART_CONSOLE=n
CONFIG_LOG_BACKEND_RTT=y
CONFIG_LOG_BACKEND_UART=n

# Network
CONFIG_NETWORKING=y
CONFIG_NET_SOCKETS=y
CONFIG_NET_NATIVE=n

# BSD library
CONFIG_BSD_LIBRARY=y
# Align the max FD entry to BSD_MAX_SOCKET_COUNT(8)
CONFIG_POSIX_MAX_FDS=8
# Enable below for modem trace
CONFIG_BSD_LIBRARY_TRACE_ENABLED=y

# Use GPIO
CONFIG_GPIO=y
CONFIG_GPIO_NRFX=y
CONFIG_GPIO_NRF_P0=y

# UART interface
CONFIG_SERIAL=y
CONFIG_UART_ASYNC_API=y
CONFIG_NRFX_TIMER2=y

# LTE link control
CONFIG_LTE_LINK_CONTROL=y
CONFIG_LTE_AUTO_INIT_AND_CONNECT=n

# Stacks and heaps
CONFIG_MAIN_STACK_SIZE=4096
CONFIG_HEAP_MEM_POOL_SIZE=16384
CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=8192

# AT_CMD
# Enable AT_CMD debug for details
CONFIG_AT_CMD_LOG_LEVEL_DBG=y

# Device power management
CONFIG_DEVICE_POWER_MANAGEMENT=y

# Enable SUPL client support
#CONFIG_SUPL_CLIENT_LIB=y

# FOTA
CONFIG_HTTP_PARSER_URL=y
CONFIG_FOTA_DOWNLOAD=y
CONFIG_FOTA_DOWNLOAD_PROGRESS_EVT=y
CONFIG_DFU_TARGET=y
CONFIG_DOWNLOAD_CLIENT=y
CONFIG_DOWNLOAD_CLIENT_STACK_SIZE=4096
CONFIG_BOOTLOADER_MCUBOOT=y
CONFIG_IMG_MANAGER=y
CONFIG_FLASH=y
CONFIG_IMG_ERASE_PROGRESSIVELY=y

#
# SLM-specific configurations
#
CONFIG_SLM_LOG_LEVEL_INF=y
# Enable GPIO wakeup if sleep is expected
#CONFIG_SLM_GPIO_WAKEUP=y
# Use UART_0 (when working with PC terminal)
CONFIG_UART_0_NRF_HW_ASYNC_TIMER=2
# Use UART_2 (when working with external MCU)
#CONFIG_SLM_CONNECT_UART_2=y
#CONFIG_UART_2_NRF_HW_ASYNC_TIMER=2

# Use optional GPS service
#CONFIG_SLM_GPS=y
# Use optional FTP client service
#CONFIG_SLM_FTPC=y
# Use optional MQTT client service
#CONFIG_SLM_MQTTC=y
# Use optional HTTP client service
CONFIG_SLM_HTTPC=y

RE: nRF9160: not retrieving DNS servers with IPV6

aldras — Tue, 12 Jan 2021 17:21:21 GMT

Hm, I ran the two commands below and restarted, the nRF9160 is in a restart loop somehow, I will try to enable some more debug options to see if I can find out why...

I only enabled CONFIG_BSD_LIBRARY_TRACE_ENABLED=y and then rebuilt, programmed.

I as soon as I did the two commands...

AT%XMODEMTRACE=1,2
AT+CFUN=0

I pressed the hardware reset key on the dev kit and now it just loops "Ready" about once a second, and I also checked the trace file, it is empty I think.

RE: nRF9160: not retrieving DNS servers with IPV6

aldras — Tue, 12 Jan 2021 17:14:00 GMT

Ah, ok I am going to try again, here is another attempt with the above options enabled.

I deleted the entire build folder and rebuilt with "west build -b nrf9160dk_nrf9160ns"

www.drassal.net/.../trace-2021-01-12T17-09-05.020Z.bin

RE: nRF9160: not retrieving DNS servers with IPV6

Didrik Rokhaug — Tue, 12 Jan 2021 16:57:55 GMT

Hi,

I've tried to decode both of your traces, but neither of them contains any information.

A valid trace is typically several hundred kilobytes large.

Did you enable modem traces in the application with CONFIG_BSD_LIBRARY_TRACE_ENABLED=y in your prj.conf (if you are building the application with SES, you must re-open the project or use Project->Run CMake for the changes to take effect).

In addition, you must use AT%XMODEMTRACE=1,2 to enable modem traces in the modem. You can then store the setting with AT+CFUN=0, so that the modem will output traces also after reboots. The %XMODEMTRACE AT command can only be used when the modem is offline (CFUN=0 or 4).

RE: nRF9160: not retrieving DNS servers with IPV6

aldras — Tue, 12 Jan 2021 07:48:17 GMT

Ah, I didn't attempt to connect in the first trace, here is another one where I attempted to connect with both the hostname and then with a direct IP, it froze after the direct IP attempt connect, hope the modem trace shows why.

www.drassal.net/.../trace-2021-01-12T07-43-28.792Z.bin

RE: nRF9160: not retrieving DNS servers with IPV6

aldras — Tue, 12 Jan 2021 07:41:43 GMT

Hi Didrik,

I am uploading a modem trace, it is with the 1.4.99-dev1 version of the SDK, serial_lte_modem application. This is the IPv6 SIM that does not retrieve DNS servers.

I hope this trace helps provide some insight.

Ah I can't find a way to upload a file, I will host it on my VPS server, it would be better if I could upload it so it is always available on these forms for alter use, did I just miss the upload feature?

www.drassal.net/.../trace-2021-01-12T07-30-20.914Z.bin

RE: nRF9160: not retrieving DNS servers with IPV6

Didrik Rokhaug — Mon, 11 Jan 2021 10:43:55 GMT

[quote user="aldras"]There is a v1.4.99-dev1 version, but because of the word "dev" it appears it is not yet stable and in development.[/quote]

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.

[quote user="aldras"]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[/quote]

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.

[quote user="aldras"]Is it possible that the APN is incorrect?[/quote]

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.

RE: nRF9160: not retrieving DNS servers with IPV6

aldras — Sat, 09 Jan 2021 14:14:40 GMT

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&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.

RE: nRF9160: not retrieving DNS servers with IPV6

Didrik Rokhaug — Fri, 08 Jan 2021 12:49:03 GMT

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.

[quote user="aldras"]Should I be able to connect to an IPV4 address if I received an IPV6 address? Will DNS resolutions work correctly?[/quote]

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.

[quote user="aldras"]it appears the three dev kit boards I received are engineering samples[/quote]

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.

RE: nRF9160: not retrieving DNS servers with IPV6

aldras — Thu, 07 Jan 2021 15:00:39 GMT

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

RE: nRF9160: not retrieving DNS servers with IPV6

aldras — Thu, 07 Jan 2021 14:57:51 GMT

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!

RE: nRF9160: not retrieving DNS servers with IPV6

Didrik Rokhaug — Thu, 07 Jan 2021 12:58:09 GMT

Hi,

[quote user=""]Is there a difference between these two commands? Does it result in the same build?[/quote]

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).

[quote user=""]It appears that this SIM only supports IPV6, is there such a thing?[/quote]

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?

[quote user=""]I found information that I can manually specify DNS servers, but I don't know how to do this with AT commands.[/quote]

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

Instead, you will have to modify the SLM application.

Best regards,

Didrik