Can't connect to AWS IOT

[tmcadam]

I'm having trouble connecting to AWS IOT. My best theory is that the device is not being set correctly to use TLS1.2, which is required by AWS (and possibly Azure). I saw this job posted on a freelancing site which seems to support this theory (although they may have got the idea from me posting in an issue on another repo).

Thought I would create another issue/thread to discuss this.

This is the post I saw:

[tmcadam]

My next course of action is to setup an Mosquitto server on a VPS somewhere and try and connect it. This should at least give me detailed logs on one end of the connection and hopefully tell me what TLS version is really being used for the connection. Having no feedback from the AT commands from the device and the AWS logs being pretty vague about failed connections, isn't helping matters.

If anyone has a better idea on this issue, let me know.

[CoolNamesAllTaken]

Interesting! That happens to be pretty much exactly what I'm working on, except that I'm trying to connect to Azure instead of aws. Do you have a link to their post?

I've forked TinyGSM's repository here. I'm working on the dev/jm/add-ssl branch to try to restructure the code to support TLS 1.2.

[tmcadam]

Tonight I set up a Mosquitto broker on Vultr with all the certs and keys for client cert authentication. I set the broker to require TLS v1.2 (like AWS and probably Azure is the same) and it worked fine when I set AT('+CSSLCFG="sslversion",0,3'). When I commented this line out, so defaulting back to TLS v1.0 the connection failed.

So basically the device seems to have no problem with TLS v1.2 connections.

I am going to try generating new device and keys in AWS and trying again.

[CoolNamesAllTaken]

Sounds like progress! Whenever I send stuff with AT+CASEND, I get two responses: AT+CADATAIND and AT+CASTATE. AT+CADATAIND seems to be the indicator for data being available in the modem buffer, but I can't find CASTATE anywhere in the docs. Do you know what it is, @tmcadam ? I'm using the CA-series of commands because I'm trying to build a generic client that will accept multiple protocols (http, mqtt, etc).

I also seem to have an error that occurs if I call AT+CARECV immediately after a successful AT+CASEND (AT+CARECV returns ERROR or times out instead of data, even after I receive the AT+CADATAIND notification. Is there any sort of indication that you know of for the CA-series commands that shows how many bytes to read with CARECV? Do we need to close and then open the connection after a successful send, before we can read data?

[tmcadam]

@CoolNamesAllTaken Sorry for the slow reply. I can't see anything about CASTATE and CADATAIND in the docs I'm afraid. There is an application note for a secure TCP exchange using the CA series of commands. I will try and attach it here.

I am starting to think that the issue with AWS could be the SIMCOMM MQTT application. I think everything to do with TLS is working as expected(version, ciphers, certificates).

I am guessing that using TinyGSM with pubsub library would be the next thing to try. So I'm guessing that TinyGSM doesn't support SSL yet, hence your fork? I was surprised to see SIM7000E supported at all, it wasn't when I started playing around with the module last year.

SIM7000_Series_SSL_Application_Note_V1.00.pdf SIM7000 Series_TCPIP_Application Note_V1.01.pdf

[CoolNamesAllTaken]

Thanks for the links! I did end up using those docs those earlier last week. I'm still working on my fork of TinyGSM (I'm gutting the SIM7000 header file and rebuilding it for SSL and non-SSL connections). I think we can configure the modem using all of the Simcom "TCP/UDP Application" commands, which start with AT+CA_ (AT+CARECV, AT+CASEND, etc). I think we can even do unsecured connections that way, since there is an unsecured example in the SSL doc. I won't have much time to work on this for a while since school just kicked off again, but I'll get back to it when I can.

I also resolved an issue using PubSubClient and TinyGSM: PubSubClient's max packet size is set to 128 bytes, which is too small for Azure IoT's SAS token used in the login packet. I've forked PubSubClient and upped the max packet size to 1280 bytes for testing--but if you're messing with PubSubClient and get the rc=-1 MQTT_DISCONNECTED error, beware!

On Tue, Apr 2, 2019 at 1:52 AM Tom McAdam notifications@github.com wrote:

@CoolNamesAllTaken https://github.com/CoolNamesAllTaken Sorry for the slow reply. I can't see anything about CASTATE and CADATAIND in the docs I'm afraid. There is an application note for a secure TCP exchange using the CA series of commands. I will try and attach it here.

I am starting to think that the issue with AWS could be the SIMCOMM MQTT application. I think everything to do with TLS is working as expected(version, ciphers, certificates).

I am guessing that using TinyGSM with pubsub library would be the next thing to try. So I'm guessing that TinyGSM doesn't support SSL yet, hence your fork? I was surprised to see SIM7000E supported at all, it wasn't when I started playing around with the module last year.

SIM7000_Series_SSL_Application_Note_V1.00.pdf https://github.com/tmcadam/sim7000-tools/files/3033046/SIM7000_Series_SSL_Application_Note_V1.00.pdf SIM7000 Series_TCPIP_Application Note_V1.01.pdf https://github.com/tmcadam/sim7000-tools/files/3033050/SIM7000.Series_TCPIP_Application.Note_V1.01.pdf

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/tmcadam/sim7000-tools/issues/2#issuecomment-478904940, or mute the thread https://github.com/notifications/unsubscribe-auth/AIpMoSw6Q5NeG6pIGo3YimOSKqvZBuJgks5vcxpFgaJpZM4cNNEw .

[slipiduche]

Tonight I set up a Mosquitto broker on Vultr with all the certs and keys for client cert authentication. I set the broker to require TLS v1.2 (like AWS and probably Azure is the same) and it worked fine when I set AT('+CSSLCFG="sslversion",0,3'). When I commented this line out, so defaulting back to TLS v1.0 the connection failed.

So basically the device seems to have no problem with TLS v1.2 connections.

I am going to try generating new device and keys in AWS and trying again.

hi im trying with aws too, but doesn't connect. how is the configuration for mosquitto with tlsv1.2 and how you set the certificates, i only get a https connection with SH commands and SM commands and CA command does'nt work. if you can help me will be great.. thanks

[tmcadam]

Hi @slipiduche

This is the conf that I used for mosquitto to try and replicate AWS connection. The SIM7000 works fine with this setup, but not with AWS IoT.

listener 8883 cafile /etc/mosquitto/certs/ca.crt certfile /etc/mosquitto/certs/swb-01.crt keyfile /etc/mosquitto/certs/swb-01.key tls_version tlsv1.2 require_certificate true ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256

Obviously you need to generate some certs for this, I used the mosquitto-tls quide.

Please let me know if you have any success with AWS.

[slipiduche]

Hi, Well I achieve a connection with aws doing mosquitto broker a bridge. I mean your same configuration but adding the bridge configuration parameters.

I still trying,

Greetings

El vie., 3 de mayo de 2019 7:18 p. m., Tom McAdam notifications@github.com escribió:

Hi @slipiduche https://github.com/slipiduche

This is the conf that I used for mosquitto to try and replicate AWS connection. The SIM7000 works fine with this setup, but not with AWS IoT.

listener 8883 cafile /etc/mosquitto/certs/ca.crt certfile /etc/mosquitto/certs/swb-01.crt keyfile /etc/mosquitto/certs/swb-01.key tls_version tlsv1.2 require_certificate true ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256

Obviously you need to generate some certs for this, I used the mosquitto-tls https://mosquitto.org/man/mosquitto-tls-7.html quide.

Please let me know if you have any success with AWS.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/tmcadam/sim7000-tools/issues/2#issuecomment-489276084, or mute the thread https://github.com/notifications/unsubscribe-auth/ALUNRCJI5BXKNVCN7MGJ3WDPTTI5PANCNFSM4HBU2EYA .

[reydelleon]

Sounds like progress! Whenever I send stuff with AT+CASEND, I get two responses: AT+CADATAIND and AT+CASTATE. AT+CADATAIND seems to be the indicator for data being available in the modem buffer, but I can't find CASTATE anywhere in the docs. Do you know what it is, @tmcadam ? I'm using the CA-series of commands because I'm trying to build a generic client that will accept multiple protocols (http, mqtt, etc).

I also seem to have an error that occurs if I call AT+CARECV immediately after a successful AT+CASEND (AT+CARECV returns ERROR or times out instead of data, even after I receive the AT+CADATAIND notification. Is there any sort of indication that you know of for the CA-series commands that shows how many bytes to read with CARECV? Do we need to close and then open the connection after a successful send, before we can read data?

@CoolNamesAllTaken Have you figured this out? I'm struggling with the same issue. I'm using the MQTT library, which tries to read the response as soon as it sends the CONNECT package, but I get error all the time as response for +CARECV. I see the +CASTATE URC too, but I can't find it's description anywhere.

I'm using SIM7000G.

[reydelleon]

Actually, @CoolNamesAllTaken I found a reference to CADATAIND: in the Manual v1.0.4. It states... After open a connection successfully, if module receives data, it will report "+CADATAIND: <cid>" to remind user to read data.

You can find it under the description of +CAOPEN.

[CoolNamesAllTaken]

Haha thanks Reydel! I haven't worked on this in a while, but the impression that I got is that you can ditch all the conventional HTTP commands and use the CA-prefixed commands for everything (CAOPEN, etc). I think the CA commands should be good enough to do everything from MQTT to HTTP to HTTPS, but I never got a chance to fully flesh that out.

On Tue, Jun 11, 2019 at 8:54 PM Reydel Leon Machado < notifications@github.com> wrote:

Actually, @CoolNamesAllTaken https://github.com/CoolNamesAllTaken I found a reference to CADDATAIND: in the Manual v1.0.4. It states...

After open a connection successfully, if module receives data, it will report "+CADATAIND: " to remind user to read data.

You can find it under the description of +CAOPEN.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/tmcadam/sim7000-tools/issues/2?email_source=notifications&email_token=ACFEZIKIOYVOQGATGVTUEC3P2BXQPA5CNFSM4HBU2EYKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXPFQ3A#issuecomment-501110892, or mute the thread https://github.com/notifications/unsubscribe-auth/ACFEZIIKYPHJZQVCWKYOVD3P2BXQPANCNFSM4HBU2EYA .

[pbn4]

Hi guys, did you find the description of +CASTATE anywhere?

[davegravy]

Did anyone ever resolve this? I am just starting on the same path (trying to use MQTT with AWS IoT) and seeing no activity/resolution for 1.5yrs is concerning. Wondering if I should try or switch modules.

[dalbert2]

I'm able to open TLS connections to azure-devices.net, with and without site authentication (the CA cert is here: https://baltimore-cybertrust-root.chain-demos.digicert.com/info/index.html). However, I'm not able to do 1-way authentication to my own server using its root CA cert, so I'm starting to think the SIMCom firmware (I'm using 1529B08SIM7000G) may have trouble with certain certificates or sites.

If you're having trouble, this sequence for connecting to azure with 1-way authentication seems to work (assumes you've already uploaded the certificate into the file system and named it rootCA.cer):

 AT+CMEE=2
 AT+CNACT=1
 AT+CACID=0
 AT+CSSLCFG="sslversion",0,3
 AT+CASSLCFG=0,ssl,1
 AT+CASSLCFG=0,crindex,0
 AT+CSSLCFG="convert",2,"rootCA.cer"
 AT+CASSLCFG=0,"cacert","rootCA.cer"
 AT+CAOPEN=0,"www.azure-devices.net",443
 AT+CARECV=0,100
 AT+CACLOSE=0

[RaphaelContato]

Hi everyone! I am trying to connect my SIM7000G on Mosquitto broker TLS (Ubuntu VPS) and just receive this error:

(To see errors) sudo tail -f /var/log/mosquitto/mosquitto.log New connection from XXX.XX.XXX.XX:xxxx on port 8883 OpenSSL Error[0]: error:0A000126:SSL routines::unexpected eof while reading Client disconnected: Protocol error.

Commands useds MQTT: AT+CSSLCFG="ignorertctime",0,1 AT+CSSLCFG=convert,2,"rootCA.cer" AT+CSSLCFG="sslversion",0,3 AT+CASSLCFG=0,"cacert","rootCA.cer" AT+SMSSL=1,rootCA.cer,cert.cer AT+SHSSL=1,""

Help me please!

[Sharjeel774748]

For the connection with mqtt on port 8883 (secure over ssl server signed certificate) just need to enable the ssl using at commands but manual does not have any specific one in case of sim 7000G..... i am also stuck in it