Hello,
To preface (My setup):
- nRF9151DK
- Modem firmware: mfw_nrf91x1_2.0.2
- nRF Connect SDK / Toolchain: 2.9.0
- Terminal app: PuTTY
- Application: HTTPS Client Sample: docs.nordicsemi.com/.../README.html
- Carrier: Verizon
I have a Verizon CAT-1 SIM that oddly works in my nRF9151DK. However, I just activated service on a Verizon CAT-M SIM and attempted to use it. It registers on the network fine (+CEREG: 1) but every time I attempt to open a socket I receive error 116.
Thus, I went back to basics and loaded the HTTPS Client sample linked above. The sample won't work with my SIM either. See log below:
*** Booting nRF Connect SDK v2.9.0-7787b2649840 *** *** Using Zephyr OS v3.7.99-1f8f3dc29142 *** HTTPS client sample started Bringing network interface up Provisioning certificate Certificate match Connecting to the network +CGEV: EXCE STATUS 0 +CEREG: 2,"9B01","025EC901",7 %MDMEV: PRACH CE-LEVEL 0 %MDMEV: PRACH CE-LEVEL 1 +CSCON: 1 +CGEV: ME PDN ACT 0 %MDMEV: SEARCH STATUS 2 +CEREG: 1,"9B01","025EC901",7,0,18,"11100000","11100000" [00:00:06.764,770] <wrn> lte_lc: Registration rejected, EMM cause: 18, Cell ID: 39766273, Tracking area: 39681, LTE mode: 7 Network connectivity established and IP address assigned Looking up example.com +CGEV: IPV6 0 Resolved 23.215.0.138 (AF_INET) Connecting to example.com:443 connect() failed, err: 111 +CEREG: 0 +CGEV: ME DETACH +CSCON: 0 Network connectivity lost Disconnected from the network
Per C:\ncs\toolchains\b620d30767\opt\zephyr-sdk\arm-zephyr-eabi\arm-zephyr-eabi\include\sys\errno.h, error code 111 means
ECONNREFUSED: Connection refused
This got me thinking maybe it was related to this sample using an IPV6 address. In the example log output provided here: docs.nordicsemi.com/.../README.html
I see the following:
... Resolved 93.184.215.14 (AF_INET) Connecting to example.com:443 ...
It is using an IPV4 address.
So now, I tried adding ".ai_family = AF_INET," to the 'hints' structure:
static void send_http_request(void) { int err; int fd; char *p; int bytes; size_t off; struct addrinfo *res; struct addrinfo hints = { .ai_family = AF_INET, <---------------------------------------- ADDED THIS .ai_flags = AI_NUMERICSERV, /* Let getaddrinfo() set port */ .ai_socktype = SOCK_STREAM, };
Now I receive error 116 (ETIMEDOUT: Connection timed out) which matches the behavior I am seeing in my custom application as seen below:
*** Booting nRF Connect SDK v2.9.0-7787b2649840 *** *** Using Zephyr OS v3.7.99-1f8f3dc29142 *** HTTPS client sample started Bringing network interface up Provisioning certificate Certificate match Connecting to the network +CGEV: EXCE STATUS 0 +CEREG: 2,"9B01","025ECB03",7 %MDMEV: PRACH CE-LEVEL 0 %MDMEV: PRACH CE-LEVEL 1 +CSCON: 1 +CGEV: ME PDN ACT 0 %MDMEV: SEARCH STATUS 2 +CEREG: 1,"9B01","025ECB03",7,0,18,"11100000","11100000" [00:00:04.368,835] <wrn> lte_lc: Registration rejected, EMM cause: 18, Cell ID: 39766787, Tracking area: 39681, LTE mode: 7 Network connectivity established and IP address assigned Looking up example.com +CGEV: IPV6 0 Resolved 96.7.128.198 (AF_INET) Connecting to example.com:443 +CSCON: 0 %MDMEV: PRACH CE-LEVEL 0 %MDMEV: PRACH CE-LEVEL 1 +CSCON: 1 connect() failed, err: 116 +CEREG: 0 +CGEV: ME DETACH +CSCON: 0 Network connectivity lost Disconnected from the network
Here is a modem trace log of the HTTPS Client sample with the IPV4 modification as highlighted above:
HTTPS Client sample log with modem trace enabled (Captured in parallel with trace file above):
*** Booting nRF Connect SDK v2.9.0-7787b2649840 *** *** Using Zephyr OS v3.7.99-1f8f3dc29142 *** HTTPS client sample started Bringing network interface up [00:00:00.552,276] <inf> nrf_modem_lib_trace: Trace thread ready [00:00:00.560,333] <inf> nrf_modem_lib_trace: Trace level override: 2 Provisioning certificate Certificate match Connecting to the network +CGEV: EXCE STATUS 0 +CEREG: 2,"9B01","025ECB03",7 %MDMEV: PRACH CE-LEVEL 0 +CSCON: 1 +CGEV: ME PDN ACT 0 %MDMEV: SEARCH STATUS 2 +CEREG: 1,"9B01","025ECB03",7,0,18,"11100000","11100000" [00:00:02.873,870] <wrn> lte_lc: Registration rejected, EMM cause: 18, Cell ID: 39766787, Tracking area: 39681, LTE mode: 7 Network connectivity established and IP address assigned Looking up example.com +CGEV: IPV6 0 Resolved 23.215.0.136 (AF_INET) Connecting to example.com:443 connect() failed, err: 111 +CEREG: 0 +CGEV: ME DETACH +CSCON: 0 Network connectivity lost Disconnected from the network [00:00:05.829,833] <inf> nrf_modem_lib_trace: Modem was turned off, no more traces
Questions
1. What am I doing wrong or missing when using a Verizon SIM?
2. Do I need to do anything special when using a Verizon CAT-M SIM? Should it "just work"?
Example: Do I need to add LWM2M for the samples to work, or is LWM2M only required for certification?
3. My understanding and experience with Telit modems is that Verizon expects that context ID 3 be used for the data APN. However, when I query the APN's, I only see "vzwadmin". Is context ID 3 used for Verizon on Nordic modems?
For example, when I query AT+CGDCONT? on my Telit modem using this SIM I see:
> at+cgdcont?
+CGDCONT: 1,"IPV4V6","ims","",0,0,0,0
+CGDCONT: 2,"IPV4V6","vzwadmin","",0,0,0,0
+CGDCONT: 3,"IPV4V6","REDACTED","",0,0,0,0
+CGDCONT: 4,"IPV4V6","vzwapp","",0,0,0,0
+CGDCONT: 5,"IPV4V6","","",0,0,0,1
+CGDCONT: 6,"IPV4V6","vzwclass6","",0,0,0,0
+CGDCONT: 1,"IPV4V6","ims","",0,0,0,0
+CGDCONT: 2,"IPV4V6","vzwadmin","",0,0,0,0
+CGDCONT: 3,"IPV4V6","REDACTED","",0,0,0,0
+CGDCONT: 4,"IPV4V6","vzwapp","",0,0,0,0
+CGDCONT: 5,"IPV4V6","","",0,0,0,1
+CGDCONT: 6,"IPV4V6","vzwclass6","",0,0,0,0
When I execute the same command running the AT Client sample on the Nordic modem I see:
+CGDCONT: 0,"IPV4V6","vzwadmin","10.129.48.244 2600:1004:F007:DF0A:0000:0046:5761:3101",0,0
+CGDCONT: 1,"IPV4V6","vzwadmin","10.129.48.244 2600:1004:F007:DF0A:0000:0046:5761:3101",0,0
OK
+CGDCONT: 1,"IPV4V6","vzwadmin","10.129.48.244 2600:1004:F007:DF0A:0000:0046:5761:3101",0,0
OK
Why the difference?
Edit: I don't know why, but the DevZone isn't respecting my newlines "\r\n" between the text above so everything is smashed together and not neatly formatted, sorry!
Thanks,
Derek