@hirotakaster I just checked your mbedtls includes in the mqtt-tls lib on github to see how it is different from what I am using. I noticed that in config.h the
My point is mainly that with the library version that operates with the defines I listed above, one can lower the RAM footprint which in our small particle world is a big deal. Perhaps you did this in another way and I missed it?
I’m curious as to where your RAM footprints are landing with this client? I’ve used the WolfSSL TLS 1.2 client in past Particle iterations for AWS-IoT endpoints and wondered how this stacked up in comparison??
OUT_CONTENT_LEN, IN_CONTENT_LEN can use on 2.13.x version.
You could change the MBEDTLS_SSL_MAX_CONTENT_LEN on 2.7.x.
I can’t decide about the which mbedTLS version could good for this library and developers in 2.8.x/2.7.x/2.1.x version released.
But 2.8.x-2.13.x is released for latest features(IN/OUT_CONTENT_LEN…etc) version, 2.7.x/2.1.x become maintenance release version in this year.
Here is mbedTLS release comments. Mbed TLS 2.7.6 and 2.1.15 are maintenance releases, and intentionally do not contain new features to avoid changing the library interface and allow users to change library versions easily.
So I will update MQTT-TLS/TlsTcpClient mbedTLS version to 2.13(or 2.14?) in sometime soon
@hirotakaster, re-reading the MBEDTLS release notes and your comments I understand now that 2.7.x and 2.1.x are previous versions of the library that have seen security upgrades but no feature upgrades (pretty messy to new comers).
So I upgraded MQTT-TLS to 2.12 a few months ago with minimal effort, it was really a small change with respect to a time() call if I remember correctly. It did give me the possibility to change the buffer sizes which was important in my app which uses lots of RAM for data analysis. So my input/output buffer sizes are 4K/2K which works well with AWS IoT. I also tested pretty much all options in the config.h files for the minimal set needed to connect to AWS.
Still tricky is the startup of the library during which it consumes much more memory and depletes the stack rather rapidly. But I am not going to tinker with MBEDTLS itself outside the config.h file (though my fingers are tickling to do it!). It will be good to see you upgrade to 2.13, thanks again for the nice MQTT library!
I can second this, I had to move a lot of static variables to **const** to reduce memory footprint to get a connection/start.
eg.
const int syncTimeRate = 60*60;
Currently this allows it to boot and results in System.freeMemory() returning a value of: 48832
I was finding anything lower than 35-40k was causing instability.
I’m also using a lot of Strings (@ScruffR would say that is a no no and I should use Chars, but finding it difficult to swap between chars and strings when dealing with cloud return variables). I think the memory foot print changes quite a lot as the code goes through different functions/timed events.
You can almost always work with char* and never touch String.
If you have a specific example, I may be able to show you how.
e.g.
// docs for Particle.function() state the callback needs to look like
int someFn(String args);
// but this works just the same
int someFn(const char* args);
So I was able to reduce the RAM footprint of the library by 12KB with two config changes. The first one is a no-brainer if you have the space in ROM, as you lose absolutely nothing.
With default config: Free RAM 16024
In ‘lib/MQTT-TLS/src/mbedtls/config.h’:
With MBEDTLS_AES_ROM_TABLES enabled (this moves an 8KB table from RAM to ROM. This pushed my code to the ROM limit, but I was able to remove some old code and get it to work) Free RAM 24128
Reducing MBEDTLS_SSL_MAX_CONTENT_LEN (With MBEDTLS_SSL_MAX_FRAGMENT_LENGTH enabled per default) to 6144 (4096 couldn’t connect for me). Handshake seems to work fine, was able to send ~2k payload (my max Len) over the connection with no issues. Keep in mind that this can be server dependent, so this may not apply outside of aws iot, and this may eventually not be sufficient if they change something on the server side. Free RAM 28248
Thanks to @joost for the suggestion to mess with the buffer, and to @hirotakaster for making and maintaining this library - it’s been super helpful!
Edit: With these changes, the total approximate observed continuous RAM impact of the library is 24KB instead of 28.5KB ( though still requiring an extra 7KB dynamically during handshake per my previous post so requiring a minimum of ~30KB instead of 35KB Free RAM for a handshake ).
Edit 2: Here’s a post with some deeper optimization possibilities, though these may be risky on AWS IOT since we don’t really control the server here. Someone with more knowledge of TLS / SSL may be able use these to optimize though. https://tls.mbed.org/kb/how-to/reduce-mbedtls-memory-and-storage-footprint
this is an awesome library and i really want to use it. can someone explain to me where i’m supposed to download my Cert files from amazon iot to? where should these be saved (in particle device im assuming?) but how do you do this?
MQTT-TLS seems to only use SHA256, so removing the other two hash libraries saves a ton of ROM flash space. @hirotakaster, might be worth adding this config change to your next release. There are some static function instances that are created with this define, so they don’t get compiler-optimized away, seemingly.
I think SHA algorithm is a little hard problem. Some servers use SHA-1 fingerprint certificate, and some servers use SHA-384 fingerprint certificate. So I set SHA-[1|256|512] algorithm on MQTT-TLS.
As you comments mbedTLS can easy to change cipher algorithm on the config.h, I hope it’s better that developer change the cipher algorithm by own server&client environments.
Interesting, commenting out the SHA-256 algorithm results in a compile error, but neither of the other two do. Regardless, looks like I misinterpreted how those were getting called. Thanks for clarifying!
Either way, for AWS-IOT use cases specifically, removing support for SHA-1 & SHA-512/384 appears to be fine. Per their docs
To use AWS IoT certificates, clients must support all of the following in their TLS implementation:
TLS 1.2.
SHA-256 RSA certificate signature validation.
One of the cipher suites from the TLS cipher suite support section.
Is this still working with the latest stable firmware on Photon (1.1) ?
I am using the a2-example.ino, replacing the certificates, private key, and aws endpoint, but it doesn’t get passed ‘tls enable’ in the serial monitor - ie there is no connection to the broker.
I tried using the certificates, private key, and endpoint in a separate mqtt client, and it work s fine for both publishing and subscribing to AWS. This suggests that my AWS policy (basically wildcards for any topic) is fine, and so are my credentials.
I’ve yet only barely to get AWS Iot to work on the photon due to memory constraints.
That said, that Serial Print line should always get executed within a few seconds even if something fails. Either something is crashing or you aren’t connected to wifi. Try with System Thread enabled? Can you describe the state of your device in general?
Is the certificate arn associated with your private key and public cert attached to your thing? Unless you gave your device blanket permissions in an unusual fashion, your thing name should usually be the same as your clientid, testparticle. Your certificate needs to be attached and a policy with appropriate permissions also needs to be attached.
Let’s triple check that you are connected to the network before attempting to connect. if (!WiFi.ready()) Serial.println("Error, wifi not connected");
Make sure enabling TLS succeeds, aka the formatting of your pkey and certs are correct. Also check to see if your connect attempt succeeds and if not what the error code is.
int ret;
if ( (ret = client.enableTls(AUTH::amazonIoTRootCaPem, strlen(AUTH::amazonIoTRootCaPem)+1,
AUTH::clientKeyCrtPem, strlen(AUTH::clientKeyCrtPem)+1,
AUTH::clientKeyPem, strlen(AUTH::clientKeyPem)+1)) < 0) {
Serial.printlnf("client.enableTls failed with code: %d", ret);
}
if ( (ret >= 0) && ((ret = client.connect(MQTT_ID)) < 0) ) { // if client enable tls succeeded, attempt connect. Can block for up to 60 seconds
Serial.printlnf("client.connect failed with code: %d", ret);
}
If you get an error code, convert it to a signed hex value and search in the mbedtls library for it, or just post it here and I’ll tell you what it means.
Thanks very much for all your help. I am really struggling here…
I confirm that the certifcate arn is associated with the private key and cert. I also confirm that the cert is attached with a policy that has appropriate permissions. I am quite confident that all this works because I tested with a windows based Mqtt client and it can pub/sub to AWS IoT (using client id, CA cert, client cert, priv key, aws endpoint). I also managed to get a huzzah esp32 to connect using these credentials!
I tried your recommendations and confirm that Wifi is working and the device remains connected.
I also tried printing out the pkey and certs in serial,
Finally, I tried your suggestion of printing out the TLS connection code, but only got 0.
I am out of ideas because I know the certs and pkey work with other clients, I know the photon is connected to wifi, I have tried other photons and argons…
Would you mind if I sent you my .ino file? perhaps there is something very obvious I am doing wrong… I want to make this work so we can use to make alarms for our earthquake early-warning system !
My apologies - enableTls returns an int but connect returns a bool. So you seeing a 0 means that it is in fact unable to connect at the connection call. If enableTls is returning 0 before this (aka succeeding), it means that you likely have a permissions problem.
You can get the error code for the connection attempt by enabling debug output in MQTT-TLS.h:
make sure debug_tls is defined as below (just copy paste this below the section where it currently is defined.
This will give debug output from the ssl handshake result and a few other things. I don’t want to take over this thread so feel free to PM me the result and we can follow up on this thread once we’ve figured it all out.