Skip to content

HTTPS AT+SHCONN Issue (SIM7000A with ESP32-S2) #326

Open
Open
HTTPS AT+SHCONN Issue (SIM7000A with ESP32-S2)#326

Description

@lucienpeach
lucienpeach
opened on Nov 29, 2023

Hello,
I am trying to use an ESP32-S2-DevKitC-1 v1 Board to execute HTTPS communications with a SIM7000A module and a Hologram SIM card. I am under the impression that a secure connection is required for using Webhooks through Hologram, as HTTP POST requests to the Webhook URL I have generated (TCP, changing the beginning of the Webhook URL to http://dashboard.hologram.io) have resulted in status code 301 (Moved Permanently) as opposed to the expected status code 200. This is not surprising but confirms to me that HTTPS is necessary.

Surprisingly, even tests to establish SSL/TLS communications with sites such at httpbin.org have yielded ERROR at AT+SHCONN. After the standard initial setup messages, the AT command and reply messages in my serial monitor read as follows:

---> AT
<--- OK
---> AT+CNACT=0
<--- OK
---> AT+CNACT=1, "hologram"
<--- OK
<--- +APP PDP: ACTIVE
---> AT+CNACT?
<--- +CNACT: 1,"xx.xxx.xx.xxx"
<--- OK
---> AT+CSSLCFG="ignorertctime",1,1
<--- OK
---> AT+CSSLCFG="sslversion",1,3
<--- OK
---> AT+CSSLCFG="sni",1,"httpbin.org/"
<--- OK
---> AT+SHSSL=1,""
<--- OK
---> AT+SHCONF="BODYLEN",1024
<--- OK
---> AT+SHCONF="HEADERLEN",350
<--- OK
---> AT+SHCONF="URL", "https://httpbin.org"
<--- OK
---> AT+SHCONN
<--- ERROR

I have been following the instructions provided on this page, which was provided by user @baconcheese113 in a related issue (#156). Up until AT+SHCONN, it seems that the replies from the SIM7000A module are as anticipated, which is making this debugging process more difficult.

I am intending to use this SIM7000A module to send secure data and thus establishing this HTTPS connection is a necessity. If anyone has any ideas about where to begin with debugging this, please let me know!

Activity

  1. lucienpeach commented on Dec 7, 2023

    @lucienpeach
    lucienpeach
    on Dec 7, 2023
    Author

    Over the past week, I have made some progress on this front but am still not able to successfully use GET or POST requests with HTTPS. I realized that my firmware and drivers must not be up to date, as EFS Explorer was not properly recognizing the SIMCOM module. After proceeding with the setup steps found here and here, I resolved this issue and was able to ensure that the necessary certificates for SSL connections were saved to the "customer" folder in the alternate file system. The current status of my firmware is displayed below:

    ---> AT+CGMR
<--- Revision:1351B03SIM7000A
<--- OK

    This was the main modification that allowed AT+SHCONN to work for me, though I am now receiving status code 404 on attempts to execute GET requests with AT+SHREQ. Attached below is the snippet of the AT Commands I have used so that others may attempt to replicate this issue / potentially aid in debugging. I am using PuTTY to send AT Commands to the SIM7000A via serial connection.

    <--- +CFUN: 1
<--- +CPIN: READY
<--- SMS Ready
---> AT
<--- OK
---> AT+CNACT=1, "hologram"
<--- OK
<--- +APP PDP: ACTIVE
---> AT+CNACT?
<--- +CNACT: 1,"xx.xxx.xx.xxx"
<--- OK
---> AT+CSSLCFG="convert",2,"dweet.crt"
<--- OK
---> AT+CCLK?
<--- +CCLK: "80/01/06, 00:01:31-12"
<--- OK
---> AT+CCLK="22/12/25, 12:00:00-12"
<--- OK
---> AT+CMEE=2
<--- OK
---> AT+CSSLCFG="sni",1,"dweet.io"
<--- OK
---> AT+CSSLCFG="sslversion",0,3
<--- OK
---> AT+SHSSL=1,""
<--- OK
---> AT+SHCONF="HEADERLEN",350
<--- OK
---> AT+SHCONF="BODYLEN",1024
<--- OK
---> AT+SHCONF="URL","https://dweet.io"
<--- OK
---> AT+SHCONF?
<--- +SHCONF:
<--- URL: https://dweet.io:443
<--- TIMEOUT: 60
<--- BODYLEN: 1024
<--- HEADERLEN: 350
<--- POLLCNT: 15
<--- POLLINTMS: 500
<--- IPVER: 0
<--- OK
---> AT+SHCONN
<--- OK
---> AT+SHCHEAD
<--- OK
---> AT+SHAHEAD="Content-type","application/json"
<--- OK
---> AT+SHAHEAD="User-Agent","curl/7.47.0"
<--- OK
---> AT+SHAHEAD="Cache-control","no-cache"
<--- OK
---> AT+SHAHEAD="Connection","keep-alive"
<--- OK
---> AT+SHAHEAD="Accept","*/*"
<--- OK
---> AT+SHSTATE?
<--- +SHSTATE: 1
<--- OK
---> AT+SHREQ="https://dweet.io:443/get/latest/dweet/for/thingname",1
<--- OK
<--- +SHREQ: "GET", 404, 0
<--- +SHSTATE: 0

    I haven't seen others with issues about status code 404 when using AT+SHREQ, so I was hoping that someone may have some intuition on potential debugging approaches. Interestingly, AT+SHCONN does not work if I specify AT+SHSSL=1,"dweet.crt" in place of AT+SHSSL=1,"", making me think that there is still some issue with the certificate that is preventing me from successfully passing a GET request to dweet.io over HTTPS. But, given that I have only recently begun working with AT Commands and encryption security protocols, this could be totally off the mark.

    Would be interested to see what ideas people have to offer! And I hope that this may help someone with issues down the line. I will keep updating this thread until I get HTTPS working.

  2. milanbx commented on Mar 28, 2025

    @milanbx
    milanbx
    on Mar 28, 2025

    Hi, thanks for your answer and all the ideas, but I still did not manage to perform a HTTPS request. Here is, what I have done based on the SIM7000 Series_HTTP(S)_Application Note_V1.03.pdf guide and where it stopped working:

    AT+CMEE=2
OK

AT+GSV
SIMCOM_Ltd
SIMCOM_SIM7000E
Revision:1351B09SIM7000E
OK

AT+COPS?
+COPS: 0,0,"T-Mobile CZ KAKTUS",7
OK
Device is currently on "T-Mobile CZ KAKTUS" network.

AT+CPIN?
+CPIN: READY
OK
SIM is ready

AT+CREG?
+CREG: 0,1
OK
The device is registered in home network.

AT+CGREG?
+CGREG: 0,1
OK
The device is registered in home network.

AT+CSQ
+CSQ: 15,99
OK
Signal level is -83 dbm. Signal condition is good.The signal strength range is -53 dbm (Excellent) to -109 dbm (Marginal).

AT+CGNAPN
+CGNAPN: 1,"internet.t-mobile.cz"
OK
APN sent by the network is internet.t-mobile.cz

AT+CGDCONT=1,"IP","internet.t-mobile.cz"
OK
PDP Context list updated sucessfully

AT+CGDCONT?
+CGDCONT: 1,"IP","internet.t-mobile.cz","0.0.0.0",0,0,0,0
+CGDCONT: 13,"IP","","0.0.0.0",0,0,0,0
OK
Following connection profiles are available,
CID -> 1
PDP Type->IP
APN->internet.t-mobile.cz
PDP Address->0.0.0.0
Data Compression->0
Header Compression->0

CID-> 13
PDP Type->IP
APN->
PDP Address->0.0.0.0
Data Compression->0
Header Compression->0


AT+CGATT?
+CGATT: 1
OK
Device is attached to the network

AT+CNACT=1
OK
+APP PDP: DEACTIVE

AT+CNACT?
+CNACT: 0,"0.0.0.0"
OK

    No need to go any further, as the AT+CNACT=1 did not activated the PDP context and no connection was done. It is also strange, that runnign AT+CGDCONT=1,"IP","internet.t-mobile.cz" with number 1 leads to a resul, when the subsequent AT+CGDCONT? call shows the APN under number 13!?!
    Any ideas, what could be wrong?

  3. milanbx commented on Mar 29, 2025

    @milanbx
    milanbx
    on Mar 29, 2025

    I think I've tried and exhausted all options. The only functional connection I can get is with SAPBR and it uses the HTTP stack to perform GET and POST successfully. But when I want to use the HTTPS stack (CSSLCFG, SHSSL, SHCONN and SHREQ) in this connection, SHCONN ends with an error.
    And using a method other than SAPBR, i.e. APP PDP with AT+CNACT never returns ACTIVE. So I don't know what to do next...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions