EG916Q MQTT with TLS problem

gsara · December 22, 2025, 10:26am

Hello everyone, I am trying to use MQTT with TLS using a EG916Q LTE Modem. I started first with evaluation board of EG916Q. I have uploaded the three certificates(cacert, publiccert and private key) to my device using the QCOM software. I could then open a TCP socket and use my MQTT application as intended. However, afterwards I want to use my prototype board to do the same exact thing. I knew that I shouldnt use the same certificates but for testing purpose I upload the same certificates but I cannot open the socket and it returns always +QMTOPEN 1,5. Everything is the same the sim cards, the module, the AT command sequence and the the MQTT broker(mosquiotto). Here are the logs of my tests. I will be appreciated to get a support on this issue. Thank you very much in advance.
------------------------------------Working example with the evaluation board-------------------------------------
[2025-12-16_16:08:29:346]AT
[2025-12-16_16:08:29:346]OK
[2025-12-16_16:08:29:554]AT+CGMR
[2025-12-16_16:08:29:554]EG916QGLLGR01A03M04

[2025-12-16_16:08:29:554]OK
[2025-12-16_16:08:29:762]AT+CEREG?
[2025-12-16_16:08:29:762]+CEREG: 0,5

[2025-12-16_16:08:29:762]OK
[2025-12-16_16:08:29:977]AT+CSQ
[2025-12-16_16:08:29:977]+CSQ: 16,99

[2025-12-16_16:08:29:977]OK
[2025-12-16_16:08:30:177]AT+COPS?
[2025-12-16_16:08:30:177]+COPS: 0,0,“Vodafone.de”,7

[2025-12-16_16:08:30:177]OK
[2025-12-16_16:08:30:384]AT+QIACT=1
[2025-12-16_16:08:30:384]OK
[2025-12-16_16:08:30:600]AT+QIACT?
[2025-12-16_16:08:30:600]+QIACT: 1,1,1,“100.86.157.16”

[2025-12-16_16:08:30:600]OK
[2025-12-16_16:08:30:799]AT+QMTCFG=“recv/mode”,1,0,1
[2025-12-16_16:08:30:799]OK
[2025-12-16_16:08:31:003]AT+QMTCFG=“ssl”,1,1,1
[2025-12-16_16:08:31:003]OK
[2025-12-16_16:08:31:205]AT+QSSLCFG=“cacert”,1,“UFS:cacert”
[2025-12-16_16:08:31:205]OK
[2025-12-16_16:08:31:407]AT+QSSLCFG=“clientcert”,1,“UFS:clientcert”
[2025-12-16_16:08:31:407]OK
[2025-12-16_16:08:31:610]AT+QSSLCFG=“clientkey”,1,“UFS:clientkey”
[2025-12-16_16:08:31:610]OK
[2025-12-16_16:08:31:814]AT+QSSLCFG=“seclevel”,1,2
[2025-12-16_16:08:31:814]OK
[2025-12-16_16:08:32:017]AT+QSSLCFG=“sslversion”,1,3
[2025-12-16_16:08:32:017]OK
[2025-12-16_16:08:32:218]AT+QSSLCFG=“ciphersuite”,1,0xFFFF
[2025-12-16_16:08:32:218]OK
[2025-12-16_16:08:32:421]AT+QSSLCFG=“ignorelocaltime”,1,1
[2025-12-16_16:08:32:421]OK
[2025-12-16_16:08:32:624]AT+QMTOPEN=1,“mqtttestserver”,8883
[2025-12-16_16:08:32:624]OK
[2025-12-16_16:08:41:656]
[2025-12-16_16:08:41:656]+QMTOPEN: 1,0
[2025-12-16_16:08:42:594]AT+QMTCONN=1,“gsara”
[2025-12-16_16:08:42:594]OK
[2025-12-16_16:08:42:784]
[2025-12-16_16:08:42:784]+QMTCONN: 1,0,0

------------------------------------Not functional example with the prototype board-------------------------------------
[I] << AT
[I] >> AT
[I] >> OK
[I] << ATE0
[I] >> ATE0
[I] >> OK
[I] << AT+CGMR
[I] >> EG916QGLLGR01A05M04
[I] >> OK
[I] << AT+CEREG?
[I] >> +CEREG: 0,5
[I] >> OK^M
[I] << AT+CSQ
[I] >> +CSQ: 18,99
[I] >> OK
[I] << AT+COPS?
[I] >> +COPS: 0,0,“vodafone.de”,7
[I] >> OK
[I] << AT+QIACT=1
[I] >> OK
[I] << AT+QIACT?
[I] >> +QIACT: 1,1,1,“100.86.158.237”
[I] >> OK
[I] << AT+QMTCFG=“recv/mode”,1,0,1
[I] >> OK
[I] << AT+QMTCFG=“ssl”,1,1,1
[I] >> OK
[I] << AT+QSSLCFG=“cacert”,1,“UFS:cacert.crt”
[I] >> OK
[I] << AT+QSSLCFG=“clientcert”,1,“UFS:clientcert.pem”
[I] >> OK
[I] << AT+QSSLCFG=“clientkey”,1,“UFS:clientkey.pem”
[I] >> OK
[I] << AT+QSSLCFG=“seclevel”,1,2
[I] >> OK
[I] << AT+QSSLCFG=“sslversion”,1,3
[I] >> OK
[I] << AT+QSSLCFG=“ciphersuite”,1,0xFFFF
[I] >> OK
[I] << AT+QSSLCFG=“ignorelocaltime”,1,1
[I] >> OK
[I] << AT+QMTOPEN=1,“mqtttestserver”,8883
[I] >> OK
[I] >> +QMTOPEN: 1,5
[I] << AT+QMTCONN=1,“gsara”
[I] >> ERROR

aghelan_loga · December 23, 2025, 2:28am

Dear @gsara ,

Thank you for reaching out.

From the MQTT Application Note, +QMTOPEN: 1,5 means “Network connection error” (i.e., the module could not complete the underlying connection establishment).

In your prototype log, PDP is already activated and has an IP (AT+QIACT? OK), so the failure is most likely happening during DNS / TCP connect / TLS handshake, not LTE registration.

To pinpoint and resolve the difference between EVB vs prototype, please check the following:

Certificate file name/path mismatch (most suspicious in your logs)
On EVB you configured UFS:cacert / UFS:clientcert / UFS:clientkey, but on the prototype you configured UFS:cacert.crt / UFS:clientcert.pem / UFS:clientkey.pem. Please make sure the certificates were uploaded to the prototype with exactly the same filenames as you reference in AT+QSSLCFG. (If the actual stored filenames differ, the TLS handshake can’t use the expected cert/key.)
Get the real root-cause code immediately after the failure
Right after +QMTOPEN: 1,5, please run AT+QIGETERROR to retrieve the detailed SSL/socket error reason. The SSL note recommends using AT+QIGETERROR to query the last SSL-related failure, and the returned codes will tell if it is DNS, socket connect timeout, etc.
DNS check (since you use a hostname)
Because the broker is configured as a domain name, please verify the DNS configuration is valid using AT+QIDNSCFG= or test once with the broker’s IP to rule out DNS issues.
Confirm server-side TLS requirements match your “seclevel=2” setup
With seclevel=2, the module performs server + client authentication. If the server is configured with something like “SSLVerifyClient required”, then CA + client cert + client key must be uploaded correctly (the SSL note explicitly calls this out).
Firmware difference between boards (for isolation)
Your EVB uses EG916Q…A03M04 but the prototype uses …A05M04. If the above checks don’t resolve it, please align both boards to the same firmware to eliminate any TLS stack differences as a variable.

If you can share the output of AT+QIGETERROR right after +QMTOPEN: 1,5, we can confirm whether it’s DNS (e.g., parse failure), TCP connect, or TLS negotiation.

Best Regards,
Aghelan

gsara · December 23, 2025, 5:41pm

Dear @aghelan_loga,
Thank you very much for your detailed response. I have tried everything you have mentioned but result did not change. Furthermore, AT+QIGETERROR command returns 0,operation successful. I have managed to retrieve wireshark packet captures to analyse it more but still confused about it. I am attaching the example that did not work.

Maybe these may help diagnose the issue.

Best regards,

aghelan_loga · December 24, 2025, 3:40am

Dear @gsara ,

Thank you for sharing the Wireshark capture, it clearly shows the failure point.

From the trace, the TCP connection is established, and the TLS handshake starts normally. The broker then sends CertificateRequest (client-certificate request for mTLS). Immediately after that, the client side closes the connection, and a fatal TLS alert follows. This indicates the TLS handshake is being aborted at the stage where the server requests a client certificate, which aligns with the module reporting +QMTOPEN: 1,5.

About AT+QIGETERROR=0: this can be expected here because AT+QMTOPEN returns an immediate OK when the command is accepted, while the actual connection result is reported later via the +QMTOPEN URC.

Please perform this confirmation test:

Set server-authentication only:
AT+QSSLCFG=“seclevel”,1,1
Retry:
AT+QMTOPEN=1,“mqtttestserver”,8883

If this succeeds, the issue is confirmed to be related to client certificate/private key handling on the prototype (UFS filename/path mismatch, cert/key mismatch, encrypted/unsupported key format, or upload corruption). In that case, please delete and re-upload the client cert/key, ensure the filenames referenced in AT+QSSLCFG=“clientcert”/“clientkey” match exactly, then restore AT+QSSLCFG=“seclevel”,1,2.

If it still fails with seclevel=1, please share the broker-side TLS logs (Mosquitto) so we can check CA chain / cipher policy / TLS settings.

Best regards,
Aghelan