Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
lucienpeach opened this issue Nov 29, 2023 · 1 comment
Open

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

lucienpeach opened this issue Nov 29, 2023 · 1 comment

Comments

@lucienpeach
Copy link

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!

@lucienpeach
Copy link
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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant