Most recent activity
-
After lengthy experimentation with the SIM800 / SIM900 modules, I hit a wall in what the built-in TCPIP capabilities are able to provide. My goal is to connect to the AWS IoT service (MQTT and TLS) over GSM/GPRS.
I think what needs to happen is to use the SIM dial-up command (ATD*99#) along with a ppp / tcpip stack (and the existing TLS layer).
Am I missing something that would already do what I'm trying to accomplish? If not, what is the possibility of this being incorporated into the Espruino core? I've been looking at the lwIP/PPP stack as reference, but wanted to check in before going to far down this road.
On a side note: I discovered the SIM modules provide a FAT file system over AT API. They appear to have over a MB of storage that can be used - a nice feature to have available if you want to store things like ssl certificates and are low on flash space.
-
Good question. I'll run a few tests.
-
It appears the MQTT client connection is rejected by the server. The TLS connection has been made, but hasn't finished authenticating yet (sd->connecting is still false, but the connected event is emitted). The mqtt connect should not be called until the TLS client authentication process is completed/authorized by the server.
Here's the output without the delay and some notes:
Connecting with TLS... Loading the CA root certificate... Loading certificate file: "certs/rootCA.pem" Loading the Client certificate... Loading certificate file: "certs/cert.pem" Loading the Client Key... Loading certificate file: "certs/key.pem" Performing the SSL/TLS handshake... TLS connected ------------------->(logged in my TLS connected event handler) Client connected ----------------->(logged in MQTT module connected event) Verifying peer X.509 certificate... --->(logged ~line 530 of network.c) MQTT client disconnected --------->(logged in MQTT end event)Maybe add an authorized event that fires after the authentication process? Or delay the connected event in this scenario?
-
I just put in a pull request for the feature that reads from the file system. PEM files can be stored in the default format and the certificate/key data will be parsed, removing beginning, ending delimiters and newline characters.
Here's example code using the file paths instead of cert strings:
var eth; var connection; var options = url.parse("mqtt://A1123456789AA.iot.us-east-1.amazonaws.com:8883"); options.ca = 'certs/rootCA.pem'; options.cert = 'certs/cert.pem'; options.key = 'certs/key.pem'; var mqtt = require("MQTT").create(); mqtt.on("connected", function() { console.log("connected to AWS IoT Service..."); mqtt.subscribe("test/topic"); }); mqtt.on("publish", function (pub) { console.log("\nNew message received: "); console.log("topic: "+pub.topic); console.log("message: "+pub.message); }); function onInit() { SPI2.setup({mosi:B15,miso:B14,sck:B13,baud:1000000}); E.connectSDCard(SPI2,B1); SPI3.setup({ mosi:B5, miso:B4, sck:B3 }); eth = require("WIZnet").connect(SPI3, A0); eth.setIP(); require("tls").connect(options, function(res) { connection = res; console.log("tls connected"); setTimeout(function() { mqtt.connect(res); },2000); }); }The timeout is necessary to allow the certificate exchange and verification to complete before calling mqtt.connect. Maybe this can be event driven.
-
Fyi, I have a version working that reads the certs from the file system (sd card on Espruino). I modified the appropriate functions in network.c to attempt this if the ca/cert/key values are present, but shorter than 100 characters (assuming a path) and the USE_FILESYSTEM option is set. It fixes the memory issues and seems like a good option for many devices.
I can submit a PR if you would like to incorporate this feature into the main project.
It might be nice to have flash memory as option for those without a file system. I'll look at adding this soon.
-
Yeah, it seems like a really tricky one. I had to walk the commits between 1v82 and 1v83 to pinpoint the cause.
My guess is some indirect bitwise error caused by the enum value of the SPI devices changing, or an even more indirect effect from the device count going over 32 and the max value / power of 2 adjustment.
-
I'm having a similar issue with the rev 1v4 pico. SD Card access stopped working at commit a35b05c4a9f31d13aa8ee9b4bd4ba86c82760c0f for me. It seems to be related to the device type enumeration and the addition of the serial status items:
EV_SERIAL1_STATUS,
EV_SERIAL2_STATUS,
EV_SERIAL3_STATUS,
EV_SERIAL4_STATUS,
EV_SERIAL5_STATUS,
EV_SERIAL6_STATUS,
EV_SERIAL_STATUS_MAX = EV_SERIAL6_STATUS,I moved these down below the SPI devices and it appears to be working. There may be some remaining issues with the EV_DEVICE_MAX value.
Submitted pull request with a possible fix... or hopefully at least part of the fix.
-
It works!
I tried your suggestion of deleting the keys after initiating the connection.
Updated code example:
SPI3.setup({ mosi:B5, miso:B4, sck:B3 }); var eth = require("WIZnet").connect(SPI3, A8); eth.setIP(); eth.getIP(); var options = url.parse("mqtt://A1XXXXXXXXX9AA.iot.us-east-1.amazonaws.com:8883"); options.key = atob("MIIEow ... d4/IvHs"); options.cert = atob("MIIDWj ... +NrCQ=="); options.ca = atob("MIIE0z ... dao7WNq"); var mqtt = require("MQTT").create(); mqtt.on("connected", function() { console.log("connected to AWS IoT..."); mqtt.subscribe("test/topic"); }); mqtt.on("publish", function (pub) { console.log("\r\nnew message received: "); console.log("topic: "+pub.topic); console.log("message: "+pub.message); }); require("tls").connect(options, function(res) { console.log("tls connected"); mqtt.connect(res); }); delete options.key; delete options.cert; delete options.ca;And the results:
Connecting with TLS... Loading the CA root certificate... Loading the Client certificate... Loading the Client Key... Performing the SSL/TLS handshake... tls connected Client connected =undefined >Verifying peer X.509 certificate... MQTT connection accepted connected to AWS IoT... > new message received: topic: test/topic message: hello world!The 'hello world' message was published from another client application.
Exciting! Thanks for making this happen so quickly.
I see the 0x6d00 error is a public key mismatch. I didn't see the other error code, but I would guess it's related.
line #117 in libs/crypto/mbedtls/include/mbedtls/ssl.h
#define MBEDTLS_ERR_SSL_PK_TYPE_MISMATCH -0x6D00 /**< Public key type mismatch (eg, asked for RSA key exchange and presented EC key) */