Eg915neaagr03a12m08 - +cme error: 716

IoT Modules LTE Standard Module
1

Hi guys,

I have code that has been running for a year now but suddenly seeing this errors on EG915NEAAGR03A12M08 that returns CME ERROR: 716 when HTTP POST is executed. Here are the logs:

11:11:57.587 → AT+GMR

11:11:57.587 → EG915NEAAGR03A12M08
11:11:57.587 →
11:11:57.587 → OK
11:12:05.606 → AT+QIACT?

11:12:05.606 → +QIACT: 1,1,1,“10.27.63.46”
11:12:05.606 →
11:12:05.606 → OK
11:12:17.066 → AT+QPING=1,“8.8.8.8”

11:12:17.066 → OK
11:12:21.072 →
11:12:21.072 → +QPING: 559
11:12:25.051 →
11:12:25.051 → +QPING: 559
11:12:29.065 →
11:12:29.065 → +QPING: 559
11:12:33.073 →
11:12:33.073 → +QPING: 559
11:12:33.073 →
11:12:33.073 → +QPING: 550
11:13:34.533 → AT+QSSLCFG=“sslversion”,0,4

11:13:34.533 → OK
11:13:42.156 → AT+QSSLCFG=“ciphersuite”,0,0xFFFF

11:13:42.156 → OK
11:13:48.186 → AT+QSSLCFG=“clientcert”,0

11:13:48.186 → OK
11:13:54.544 → AT+QSSLCFG=“cacert”,0

11:13:54.544 → OK
11:14:00.579 → AT+QSSLCFG=“clientkey”,0

11:14:00.579 → OK
11:14:06.574 → AT+QSSLCFG=“seclevel”,0,0

11:14:06.574 → OK
11:14:12.837 → AT+QSSLCFG=“sni”,0,1

11:14:12.837 → OK
11:16:10.406 → AT+QHTTPURL=28,80

11:16:10.406 → CONNECT
11:16:13.429 →
11:16:13.429 → OK
11:16:53.361 → AT+QHTTPPOST=1,60,15

11:17:08.948 → +CME ERROR: 716

What could be wrong here?

2

Forgot to mention that I have also tried using few other URL like the ones on Quectel examples as well but it always return CME ERROR 716.

3

To my surpise it is the SIM card. It is a non-roaming SIM that is active with data (you can see from the ping itself). But, this is very odd. What are the configuration on the SIM that would warrant such situation?

4

Hi,

Thank you for sharing the logs. We have reviewed them and would like to share our findings.

The +CME ERROR: 716 indicates an HTTP(S) socket connect error the module was unable to establish a TCP connection to the server. However, reviewing the full log, there is an earlier and more critical indicator: all four QPING probes to 8.8.8.8 returned error code 559 (socket read failed). This means the PDP context is active and an IP address has been assigned (10.27.63.46), but the module is not receiving any data back from the network. The 716 on HTTP POST is a downstream consequence of this.

To help us confirm the root cause, could you please run the following commands and share the output?

AT+CIMI
AT+COPS?
AT+CEREG?
AT+QCFG=“roamserviceex”
AT+QGDCNT?
AT+QICSGP=1

Here is what each command will tell us:

  • AT+CIMI returns the IMSI, which identifies the SIM’s home operator via the MCC/MNC prefix.
  • AT+COPS? returns the currently attached operator. Cross-referencing this against the IMSI will confirm whether the SIM is on its home network or has attached to a visited network.
  • AT+CEREG? directly reports the EPS registration state. A value of 1 means registered on home network; a value of 5 means roaming.
  • AT+QCFG=“roamserviceex” checks whether the module itself has been configured to disable data in roaming state. If this returns a value of 1 or 3, the module is blocking the data session at the application level due to a detected roaming condition.
  • AT+QGDCNT? shows the actual bytes sent and received. If bytes_recv is zero or not incrementing despite an active PDP session, data is being dropped at the network level.
  • AT+QICSGP=1 confirms the configured APN, which we would like to verify against your SIM’s provisioned APN.

Based on the symptom profile a SIM that has been working for a year, a PDP context that activates successfully, and traffic that is silently blocked this is consistent with a carrier-side policy change on the SIM’s APN, such as updated firewall rules, destination IP restrictions, or a data plan change. The non-roaming nature of the SIM is a relevant factor here, as some IoT SIM plans restrict traffic to specific destinations or ports