Need help using NanoSSL in MQX

[ARQuattr]

I am trying to integrate Mocana NanoSSL into a MCF52259 project to connect to an HTTPS server but I'm not making any progress.

I purchased the NanoSSL/SSH license and installed it in Codewarrior 10.0 (with MQX 3.6.2) and I have been reviewing the 'NanoSSL Client for Freescale MQX RTOS User's Guide, rev. 1'. In it there are references to code, such as 'src/common/mocana.h' etc. I don't see these files on the system; where can I get these?

I also tried following the Quick Start Guide for NanoSSH/NanoSSL and this didn't help either. I then looked in the 'NanoSSL Secure HTTP webpage to Serial_Lab1_JPW_Final.pdf' and it shows this step 7 “Unzip Freescale NanoSSL/NanoSSH client project to desired directory.” Again, I can't find any of the referenced files. The same lab document later refers to <Mocana Install Dir>\MSS\... I've searched through the entire drive and haven't found anything like this. The only files I've found related to Mocana are in the ProcessorExpert folder in CW, but it only contains PRG files.

I don't use Processor Expert, and the project I'm looking to install SSL in is not using PE. I'm hoping NanoSSL can be added to non-PE projects, but I'm finding the documentation very poor in instructing on how to use it.

I did find AN4363SW.zip containing some example code by Andrey Butok, which seems to do what I'm looking for, as well as 'NanoSSH - NanoSSL V1-0-01.zip' which has some more demo code, but these both reference headers such as “moptions.h”, “mocana.h”, etc. and as I noted these files don't appear anywhere on my system.

Can anyone please help me see what I'm missing in porting this module?

Thank you

[jlash]

Finally got back to this after a couple of months of fire fighting and have some additional info to capture. 

First, my device actually has the MCF5328, not the 29 as I said in my OP.  I must have been trying to use the 29 because the NanoSSL bean didnt show up when I selected the 28 - could be because the 28 does not have a crypto acceleration unit (CAU).  The lack of CAU does explain the crash I initially saw when the code tried to initialize the CAU.

I discovered that the status bar of the Bean Selector dialog has a Filter which says "for MCF5328 only".  I click the text and it removes the filter allowing the NanoSSL bean to show up in the list.  Generating code seemed to work better if I actually removed the CPU bean, added the NanoSSL bean then added the 5328 CPU bean.

After generating code for the bean, I loaded my real project into CW and dragged the Generated_Code folder from the bean project tree to the real project tree and renamed to nanossl.  I then did a clean and make on the real project.  I get about 60 warnings in the NanoSSL code, most about implicit conversion of data types.

The NanoSSL package has a demo directory but the contents are anything but a simple, straight forward example.  Here is what I did to get something basic working.  Obviously this is not complete or ready to compile, but it all comes from the mms_common.c/.h and mms_ssl_client.c/.h in the demo folder.

            _ssl_init()

{

            MOCANA_initMocana()

            MOCANA_initLog( param )

            SSL_init( 0, 5 )

mss_ssl_ca_mgmt_init_upcalls()

}

            _ssl_connect()

            {

                        // resolve host name as necessary

                        mms_rtcs_connect_socket( &sock, ipaddr, port)

                                    // create socket

                                    // set send timeout, okay at 5000ms

                                    // set recv timeout, okay at 5000ms

                                    // set connect timeout, okay at 30000ms

                                    // don’t seem to need set tx/rx buff sizes

                                    // setup sockaddr_in struct

// call connect()

                        conn = SSL_connect( sock … )              // get connection instance

                        SSL_ioctl( SSL_SET_VERSION )

                        SSL_negotiateConnection( conn )

}

            _ssl_getpage()

            {

                        msg = “GET /index.html HTTP/1.0\n\n”;

                        SSL_send( conn, msg, msglen )

                        while( receiving )

                        {

                                    result = SSL_recv( conn, buff, buffsize, &bytes )

                                    if( result >= 0 )

                                    {

                                                // do something with buff and bytes

                                    }else

                                    {

                                                receiving = 0

                                    }

                        }

}

            _ssl_close()

            {

                        SSL_closeConnection( conn )

                        if( sock != RTCS_SOCKET_ERROR )

                        {

                                    shutdown( sock, FLAG_ABORT_CONNECTION )

                        }

}

            _ssl_cleanup()

            {

                        MOCANA_freeMocana()

}

          _ssl_test()

          {

               _ssl_init()

               while( true == runtest )

               {

                    _ssl_connect()

                    _ssl_getpage()

                    _ssl_close()    

               }

               _ssl_cleanup()

          }

This is working pretty well with two caveats:

1. There seems to be some concurrency issues within the SSL_conect stuff.  My app keeps the host name/addr info, the socket and the connection instance in a thread-specific structure.   Despite this, I experienced a lot of failed SSL_negotiateConnection()s until I put a mutex around the call to _ssl_connect().
2. SSL_negotiateConnection() takes 6-11 seconds to complete.  The device completely hangs during that time.  I have not found anything that affects the length of delay (for better or worse).  I have traced into the NanoSSL and RTCS code without gaining much insight.  The delay seems to be during a call to recv() so it is entirely possible that the server is taking that long to respond.  I need to find a way to dig into this further.

Ill add more as I make progress.

Jay

[jlash]

Have not put any time into figuring out the delay during SSL handshake, but was able to get around it for the most part by enabling "persistent connections" for the HTTP.  I simply add an HTTP header "Connection: Keep-Alive" and set the KeepAliveTimeout value on the host to be longer than the time between messages sent by the device.

[jlash]

I opened a support ticket with Freescale to help me dug into the delay during SSL_negotiateConnection() and the device hang that I saw during the delay.  I traced the delay into the depths of the SSL code and found that it occurs at two points - one where the code is decrypting the certificate received from the server and the other when it is building the encryption key to be exchanged with the server.  The delay seems feasible - presumably there is some heavy math going on for both of those. 

The support engineer suggested that I change the scheduling flags for my threads that do network communications from FIFO to TIME_SLICE (i.e. round robin).  This took care of the other tasks stalling during the delay.  Adjusting thread priorities may have accomplished the same thing, but maybe not because some of the network stuff  is done by the RTCS ethernet task which runs at a much higher priority than any of my tasks.

[jlash]

Hello Angelo,

I am at the same place as you describe above only using CW7.2 and MCF5329.  I see another post where you were having a memory allocation problem so evidently you found how to get NanoSSL pulled into a project and building.  I wonder if you could share how you were able to do that.

Another thread here contained a Quick Start guide for NanoSSL on CW7.2.  It uses Processor Expert - which my project doesnt use so Im not sure how to transfer the steps.

Thank you for any help you can offer

Jay

[ARQuattr]

Hi Jay,

     After a lot of trial and error I managed to get it to compile using a procedure similar to the following.  I didn't record all my steps as I did it so I might have missed a detail here, but I think this should work.  Also, sorry this is for CW10 but I think you can probably adapt it for CW7.2.  Let me know if you still have problems.

1. Create a new bareboard project for your processor and enable Processor Expert.  (By the way, they don't list the MCF5329 as supported on the NanoSSL page so I'm not sure if there will be problems.)

2. Open the Components Library -> Categories -> SW -> User Components.

3. Right-click on NanoSSLclient and select Add to Project.

4. In the project panel, right-click ProcessorExpert.pe and select Generate Processor Expert Code.

5. In the project folder there should be a Generated_Code folder with the newly generated code files.  Copy this entire folder to your existing project.  I renamed this folder "SSL" and copied it to the project folder (the same folder as Sources is in).

6. Open the Properties configuration for the existing project.  Add the folder added in the previous step to the Compiler -> Input -> System Recursive Path.

7. Add the "cau_lib_v1.1.o" file to the Library Files section of the Linker -> Input settings.

Let me know how that works for you.  Also, I assume you have external RAM because 32kB won't be enough.

Angelo

[jlash]

Thank you for pointing out that my CPU is not specifically supported - someone didnt do enough research before deciding on NanoSSL.

Your instructions helped me get NanoSSL pulled into my project and building - thank you! 

To capture the information for someone else who may need it:

For my CW7.2, after adding the NanoSSLclient to the project in step 3, I had to add a CPU.  When I added my 5329 CPU the Processor Expert warned me that would not be able to build the necessary source code because NanoSSL was not licensed for my CPU type.  I chose a supported CPU from the same family as mine and the reset went smoothly. 

In step 5 it sounds like you copied the files from one project to the other from inside CW using the project trees.  I did the same from Windows - copied the <new project>\CODE folder to <target project>\nanossl folder.  I then added the entire nanossl to my project via drag/drop.  This set the paths correctly in the project properties | target | access paths.  (note: this is 300+ .c/.h file in 10 or so directories)

I also created <target project>\nanossl\lib and copied over <nanossl install dir>\CAU\cau_lib_v1.1.o.  I then added (via drag/drop) to the MQX Libraries group in the CW project.

NOTE: When I build my project there are 60+ warnings in the nanoSSL code.  All of them are about implicit conversion from an int to something smaller - either a char or a short.

The only thing I have had to change so far is to commented out a small chunk of assembler code (in common\mocana.c) that initializes the hardware Crypto Accellerator because it was causing a crash.  The data sheet says my CPU has a CAU but I have not dug into it any farther.  It could simply be that initialization is different between my CPU and the one I chose when creating the SSL code.

Im still working on getting one of the examples to connect but I dont think it has anything to do with the stack.  Ill provide an update as I go.

Thank you again Angelo.

Jay

[ARQuattr]

Thanks Jay, I'm glad to hear it helped.