EG916Q-GL SSL Handshake Timeout (Error 579) on all endpoints despite valid TCP and DNS

IoT Modules LTE Standard Module
1

1. Module Information

  • Model: EG916Q-GL
  • Firmware Revision: EG916QGLLGR01A05M04
  • Network Status: Registered (Roaming), CSQ 15, PDP Context Active.

2. Problem Description

We are experiencing a persistent SSL Handshake Timeout (Error 579) when attempting to open secure sockets via AT+QSSLOPEN. The issue occurs across multiple endpoints, including AWS IoT Core and public servers like Google.

Key observations from the logs:

  • TCP Connectivity is OK: AT+QIOPEN on port 443 to www.google.com succeeds immediately (+QIOPEN: 11,0).
  • DNS is OK: The modem successfully resolves the AWS and Google endpoints.
  • Network Latency is acceptable: Ping tests show an average RTT of ~280ms–330ms.
  • Handshake fails even with Security Level 0: Even when seclevel is set to 0 (no certificate validation) and sni is enabled, the modem returns +QSSLOPEN: 0,579.
  • Cross-Verification: An openssl s_client test from a host machine on the same network confirms the AWS endpoint is reachable and providing a valid TLS v1.2 certificate chain.

3. Steps Taken to Troubleshoot

  1. Synchronized modem clock via AT+CCLK.
  2. Verified/Re-uploaded certificates to UFS.
  3. Tested with seclevel 0, 1, and 2.
  4. Enabled SNI (AT+QSSLCFG="sni",1,1).
    5
    at_cmd.txt (2.6 KB)
    endpoint_verification.txt (1.6 KB)
    . Flashed fresh PDP context and cleared all existing SSL configurations.

4. Request

Despite a stable TCP connection, the SSL engine consistently fails to complete the handshake. We suspect a potential issue with the internal SSL stack handling large certificate chains or a specific timeout setting not accessible via current AT commands.

Could you please provide:

  1. Clarification on why Error 579 persists when TCP is successful.
  2. Any specific configuration for AT+QSSLCFG that can increase the internal handshake timeout or fragment size for this firmware revision.
  3. Recommendation on whether a firmware update is required to resolve TLS 1.2 handshake stability.

Supporting Log Attachment

(Attach your raw logs here, ensuring the following sequence is highlighted for the engineer:)

  1. The TCP Success: AT+QIOPEN=1,11,"TCP","www.google.com",443,0,0 → +QIOPEN: 11,0
  2. The SSL Failure: AT+QSSLOPEN=1,1,0,"www.google.com",443,0 → +QSSLOPEN: 0,579
  3. The Firmware Version: EG916QGLLGR01A05M04
  4. The OpenSSL success from your laptop (to prove the server side is fine).
2

Dear Customer,

After checking, this seems firmware level TLS malfunction as experienced by previous customer, I will send you latest firmware through your email.

Thank you for sending detailed information. I really appreciate it.

Regards,
Fazrul Redzuan