Issue with connection with specific SIM Card | Telit Cinterion IoT Developer Community
December 30, 2021 - 9:20pm, 4527 views
Hi,
I have one issue with a specific scenario here with the APP I developed.
The app basically executes these steps:
1 - setup the connection via AT commands;
2 - execute a Ping test to validate the connection;
3 - initalize the DSS qapi connection;
4 - starts the DSS qapi via qapi_Start_Datacall();
5 - starts the MQTT Qapi connection;
6 - starts the publish/subscribe;
I have two different SIM Cards at hand here:
1 - SIM Card A: which is from an IoT Broker;
2 - SIM Card B: which is my personal smartphone sim card.
The issue:
If I use the SIM Card A, my APP works up to step (4) above.
If I use the SIM Card B, my APP works fine until step (6) above.
Looking at the source code, it is returining the NOCONN state when using QAPI functions.
The code is very similar to the one in SDK/examples/mqtt/mqtt.c in the steps about how to start a data call using the QAPI DSS functions.
The callback when the DSS is started is informing that there is NOCONN, although the AT commands are telling me that the APP is working fine (and pinging to 8.8.8.8 google).
Here are the logs when I run the APP using SIM Card A:
0:00:13:284 CRIT:dss.c,661: (((dss_init)))
00:00:13:287 CRIT:dss.c,143: dss_apn_install)--->
]0:00:13:289 CRIT:at_hdl.c,106: writting 26, =[AT^SGAUTH=1,1,******,*****
00:00:13:301 CRIT:at_hdl.c,138: Received 6, =[
OK
]
00:00:13:303 CRIT:at_hdl.c,146: @@@ MATCH
]0:00:13:306 CRIT:at_hdl.c,106: writting 41, =[AT+CGDCONT=1,"IPV4V6","******"
00:00:13:316 CRIT:at_hdl.c,138: Received 6, =[
OK
]
00:00:13:318 CRIT:at_hdl.c,146: @@@ MATCH
]0:00:13:320 CRIT:at_hdl.c,106: writting 24, =[AT^SGAUTH=2,1,*****,******
00:00:13:331 CRIT:at_hdl.c,138: Received 6, =[
OK
]
00:00:13:333 CRIT:at_hdl.c,146: @@@ MATCH
]0:00:13:335 CRIT:at_hdl.c,106: writting 40, =[AT+CGDCONT=2,"IPV4V6","******X"
00:00:13:345 CRIT:at_hdl.c,138: Received 6, =[
OK
]
00:00:13:347 CRIT:at_hdl.c,146: @@@ MATCH
]0:00:13:351 CRIT:at_hdl.c,106: writting 14, =[AT^SXRAT=12,7
00:00:13:378 CRIT:at_hdl.c,138: Received 6, =[
OK
]
00:00:13:381 CRIT:at_hdl.c,146: @@@ MATCH
00:00:13:383 CRIT:dss.c,574: dss_init_autoconnect)--->
]0:00:13:412 CRIT:at_hdl.c,106: writting 10, =[AT+COPS=2
00:00:13:956 CRIT:at_hdl.c,138: Received 6, =[
OK
]
00:00:13:959 CRIT:at_hdl.c,146: @@@ MATCH
]0:00:13:961 CRIT:at_hdl.c,106: writting 14, =[AT^SXRAT=12,7
00:00:13:987 CRIT:at_hdl.c,138: Received 6, =[
OK
]
00:00:13:989 CRIT:at_hdl.c,146: @@@ MATCH
00:00:13:991 CRIT:dss.c,366: dss_cops_zero)--->
]0:00:13:994 CRIT:at_hdl.c,106: writting 10, =[AT+COPS=0
00:00:15:375 CRIT:at_hdl.c,138: Received 6, =[
OK
]
00:00:15:377 CRIT:at_hdl.c,146: @@@ MATCH
00:00:15:379 CRIT:dss.c,515: dss_smoni)--->
]0:00:15:382 CRIT:at_hdl.c,106: writting 9, =[AT^SMONI
00:00:15:506 CRIT:at_hdl.c,138: Received 81, =[
^SMONI: Cat.M1,9610,28,-,FDD,******X,******,******,******,******,--,-78,-10,CONN,-4
OK
]
00:00:15:508 CRIT:at_hdl.c,146: @@@ MATCH
00:00:15:510 CRIT:dss.c,425: dss_smoni_parse_status)--->
00:00:15:513 CRIT:dss.c,446: STATE CONN CAT M1
00:00:15:515 CRIT:dss.c,475: CONN ANCHOR
00:00:15:517 CRIT:dss.c,279: dss_sica)--->
]0:00:15:519 CRIT:at_hdl.c,106: writting 12, =[AT^SICA=1,1
00:00:17:548 CRIT:at_hdl.c,138: Received 6, =[
OK
]
00:00:17:551 CRIT:at_hdl.c,146: @@@ MATCH
00:00:17:553 CRIT:dss.c,610: .
00:00:17:555 CRIT:dss.c,317: dss_ping)--->
]0:00:20:585 CRIT:at_hdl.c,106: writting 34, =[AT^SISX="Ping",1,"8.8.8.8",1,5000
00:00:20:690 CRIT:at_hdl.c,138: Received 95, =[
^SISX: "Ping",1,1,"8.8.8.8",93
^SISX: "Ping",2,1,1,1,0,0
^SISX: "Ping",3,1,93,93,93
OK
]
00:00:20:692 CRIT:at_hdl.c,146: @@@ MATCH
00:00:20:695 CRIT:dss.c,617: .
00:00:20:697 CRIT:dss.c,627: dss_netctrl_init)--->
00:00:20:699 CRIT:dss.c,171: dss_set_pdp_params)--->
00:00:20:702 CRIT:mod.c,106: (((STATE DSS CONNECT)))
00:00:20:704 CRIT:dss.c,699: dss_start_datacall)--->
00:00:20:711 CRIT:mod.c,149: (((STATE CHECK EVENTS)))
00:00:20:788 CRIT:dss.c,50: FLAG SET CONN_SIG_EVT_NOCONN_EVENT
00:00:20:788 CRIT:dss.c,53: Event IS NO NET
00:00:20:795 CRIT:events.c,55: NOCONN_EVENT
00:00:20:797 CRIT:mod.c,115: (((STATE DSS FAILED CONNECT)))
00:00:20:799 CRIT:dss.c,712: dss_stop_datacall)--->
Hello,
please just let me know what is FW version of the module you are using?
You can check that with ATI1 command.
Then, please check after AT^SISX=ping the following command:
AT+CGCONTRDP
I will also dig into the example and check if I can reproduce this problem.
BR
Tymek
Hello, here is the requested information:
And, adding the AT+CGCONTRDP command after the PING in the APP:
This was ran with the SIM Card A.
I've also tried with SIM Card B:
And actually, this is odd because SIM Card B should not be using the APN "virtueyes.com.br".
SIM Card B is a regular SIM Card for personal use (my personal smartphone) and I would not expect it to be working with the "virtueyes.com.br" APN.
Instead, it should be using the "vivo.com.br" APN.
To give you more information, what I am doing at the beginning of the APP is to install all the known APNs we are going to use (in this example, two only), here are the logs:
As you can see, we configure two APNs.
Hello,
And which APN have you configured in your application? Are you sure that it is correct for the SIM which is failing?
If it is please also try not to use SICA and SISX before starting the MQTT connection.
BR,
Bartłomiej
I ran a clean test using only AT commands on bom SIM Card A and Sim Card B.
Here is the logs of the execution on SIM Card A:
Here is the execution on SIM Card B I noticed something weird when I was manually configuring the APN, if I try to configure the APN as "vivo.com.br" it returns error. But if I try to configure APN as "virtueyes.com.br" then it returns OK:
But then, if I change the index, I can insert "vivo.com.br" as the APN:
Then, if I try to connect to the MQTT via AT:
I get this above error.
Then, I followed the steps on the Documentation (EXS82-W AT Command Specification):
Same error occurs.
You probably weren't able to set your "virtueyes.com.br" APN for CID1 because it was already configured for CID2 before. Please check AT+CGDCONT? output, delete "virtueyes.com.br" from any other CID and try again.
CID1 is used for LTE connection. So anyway it looks like the proper APN was auto-configured in LTE attach.
If you can successfully connect to the broker with the other SIM, it is strange. Form the error messages I'm not sure whether the broker is unreachable or it rejects the connection.
Please check if you can PING the broker.
Hello BARTŁOMIEJ GEMA... I could only remove the SGAUTH entries, but I could not remove the CGDCONT entries, how can I do that?
BARTŁOMIEJ GEMA... also, I didn't clearly understand your sentence:
"CID1 is used for LTE connection. So anyway it looks like the proper APN was auto-configured in LTE attach."
The idea behind our APP is that we register the most common APNs known in our country (or at least in the region we are releasing the modules) so the module can automatically connect to the network, that is why as of now we are registering the APN "virtueyes", "vivo", "claro" and "tim" (although in the above examples we are only registering "virtueyes" and "vivo" in this scenario).
Hello, now using SIM Card A I could remove the "virtueyes.com.br" and make sure that I cannot connect.
So, I reached the expected result which is:
- SIM Card A should not be able to connect using APN "vivo.com.br"
Following, I did a similar test with SIM Card B, configuring with the correct APN (vivo), and then trying to PING the Mosquitto Broker, and it fails, but pinging any other open networks (8.8.8.8) it works:
When the AT^SISO=1,2 is executed, the Mosquitto Broker logs the following error:
Then, I download my APP into the same module, and run it, and I can connect fine in the Mosquitto MQTT:
And, Mosquitto logs that new user has been connected successfully:
Pages