MQX Software SolutionsのトピックRe: Kinetis NanoSSL support

Kinetis NanoSSL support

RoyAtRce — Fri, 18 May 2012 03:48:49 GMT

Does anyone have any information about when the Kinetis support for NanoSSL will be available? I really need an SSL solution.

Re: Kinetis NanoSSL support

jonny — Thu, 14 Jun 2012 20:43:59 GMT

Hi,

did you find an alternative ssl solution?

NanoSSL is supported for kinetis MQX 3.7 but not 3.8.

I shall be trying it to see if it still works soon and will post back here to let you know how I get on...

Thanks

Re: Kinetis NanoSSL support

RoyAtRce — Mon, 25 Jun 2012 19:38:48 GMT

At this point I do not believe NanoSSL is supported on any Kinetis part under any existing MQX release.

Re: Kinetis NanoSSL support

chrisc — Tue, 06 Nov 2012 23:36:39 GMT

Hi Roy,

I saw that you were looking for an alternate SSL implementation to NanoSSL. We recently finished a port of the CyaSSL embedded SSL library over to MQX/RTCS/MFS with support for Kinetis and the H/W RNGA as well. Please see my original post, here:

CyaSSL embedded SSL now available for MQX!

CyaSSL provides both SSL client and server functionality with standards support up to TLS 1.2 and DTLS. CyaSSL is dual licensed under both the GPLv2 as well as a standard commercial license.

Best Regards,

Chris

Re: Kinetis NanoSSL support

jonny — Thu, 10 Jan 2013 16:25:31 GMT

Hi Roy,

just to let you know we have nanossl working originally ported over to MQX 3.8 and is also working with MQX 4.0 (partially tested but looks good). It is however not supported so I would recommend CyaSSL.

If you do get the CyaSSL working I would be interested to compare memory usage...

Re: Kinetis NanoSSL support

ARQuattr — Fri, 01 Feb 2013 12:20:24 GMT

Hi Jonathan, I'm curious about your experience with SSL, in particular RAM usage. I have this running (somewhat) on the MCF52255 and I found it used about 24kB or RAM when performing a simple GET transaction. Is this consistent with your observations? Using this much RAM makes the 52255 a non-viable choice, so I'm considering using a Kinetis part but I'm not sure they are adequately supported by NanoSSL.

I'm also considering CyaSSL, but if it has a smaller RAM footprint I would like to stay with the 52255 except I'm not sure it is supported on that chip.

1. Are there compile or run-time options to reduce RAM usage of NanoSSL?

2. What is the typical RAM usage of CyaSSL, at least as compared to NanoSSL?

3. Is it possible to use CyaSSL on the MCF52255 (without major effort)?

Re: Kinetis NanoSSL support

jonny — Fri, 01 Feb 2013 16:21:28 GMT

Hi Angelo,

that ram usage does sound about right.

We have around 3kb to init the ssl and then 30kb when in use.

1. Im not aware of any options in the NanoSSL (but you could try setting all the rtcs options in mqx to minumum memory, especially the tx and rx windows.)

2. Ive not had a chance to try the CyaSSL with the K60 yet but I suspect the ram usage would be much better, I did have a link to benchmarks but I cant find it now.

and 3. I cant see that its supported specificaly but mqx is so I would assume so.

yaSLL are pretty keen to support. Id fire off these questions to them directly.

There's the chap below or here's the qustions/support page: yaSSL - Contact Us

The only downside is pricing (if your commercial)...

Here's the github account with latest cyassl code if it helps: cyassl/cyassl · GitHub

Post back with results if you remember to, if I get round to trying it myself ill do the same.

Re: Kinetis NanoSSL support

ARQuattr — Sun, 03 Feb 2013 04:42:39 GMT

Thank you Jonathan for your reply.

I tried setting the OPT_RBSIZE and OPT_TBSIZE as shown below (I think this is what you meant), but it made no difference. I'm not sure if I did it correctly however. I tried doing this before each of SSL_init(), mss_ssl_ca_mgmt_init_upcalls(), mss_rtcs_connect_socket(), SSL_connect(), SSL_ioctl(), and SSL_negotiateConnection() in mss_ssl_client(). None of these had any apparent effect. (I was checking the RAM highwater value before and after sending a transaction.)

uint_32 opt_value;

opt_value = 1108;

if (RTCS_OK != setsockopt(mySocket, SOL_TCP, OPT_RBSIZE, (void *)&opt_value, sizeof(opt_value))) {

printf("setsockopt OPT_RBSIZE failed\n");

}

if (RTCS_OK != setsockopt(mySocket, SOL_TCP, OPT_TBSIZE, (void *)&opt_value, sizeof(opt_value))) {

printf("setsockopt OPT_TBSIZE failed\n");

}

EDIT: Disregard the above question - after digging a little deeper I found that mss_rtcs_connect_socket() is actually already setting the send and receive buffer sizes. In fact it sets it down to 256 so I don't think I should go lower than that.

Re: Kinetis NanoSSL support

ARQuattr — Sun, 03 Feb 2013 21:29:54 GMT

Jonathan, I have another question that I hope you might be able to help with (there doesn't seem to be many people on the forum that have used NanoSSL, at least that are willing to discuss it).

With NanoSSL running I can send GET messages with no issue, but when I try to use a POST message, it gets stuck. Right after the 200 OK response comes back from the server, it sits waiting for a bout a minute before it times out. It seems as though it's waiting for me to send more data (which I tried to no avail), or send some indication that the transmission is complete.

Do you know what would be causing this?

Thanks,

Angelo

Re: Kinetis NanoSSL support

jonny — Tue, 05 Feb 2013 13:44:22 GMT

Afraid I cant help you there Angelo, we dont use POST in our application so ive never tried it...

Interesting info about the tx window being set so low by the ssl id not noticed that.