701

(5 replies, posted in wolfCrypt)

Hi olga,

I am looking into your question and will get back to you as soon as possible (hopefully tomorrow in the AM).


Best Regards,

Kaleb

Hi piotrp,

I've added following flags to cflags: -ggdb -feliminate-unused-debug-symbols -fdebug-types-section
and it ends with ld.exe: final link failed: Memory exhausted.

Have you tried using

-g1 -feliminate-unused-debug-symbols -fdebug-types-section

like steffen.mueller4 suggested?

Regards,

Kaleb

Hi cfarrin,

Unfortunately our JNI expert is out of the office this week.
I will try to find a solution for you in the meantime.

If I can not find a solution our expert will be back in the office Monday and I will alert him to your issue.


Regards,

Kaleb

Hi steffen.mueller4,

Thank you so much for this feedback. I will keep this in mind for anyone else having this issue and -fdebug-types-section alone does not work.

Best,

Kaleb

Hi tlkuester,

The control file for turning on and off supported ciphers is wolfssl/wolfssl/wolfcrypt/settings.h for working with TI-RTOS you will want to add any new defines to the section

#ifdef TIRTOS

If your servers support Elliptic Variants of Ephemeral Diffie Hellman you should be able to communicate with ECDHE suites.
To enable these suites add the following to the TIRTOS section in settings.h:

#define HAVE_ECC

ECDHE suites are widely supported but I am unsure of the configuration used by your endpoints.

If that does not work could you can send us a list of ciphers supported by your endpoints and we can gladly recommend features to turn on.

Best Regards,

Kaleb

Hi Kannan,

I will add this to our list of requested features / documentation.

-Kaleb

Hi lucadistefano, steffen.mueller4 and sungyun,

With the introduction of DWARF 4 .debug_info section on ubuntu can now grow extremely large.

Please add the following to your existing configure options:

./configure <existing_options> C_EXTRA_FLAGS="-fdebug-types-section"

This will put program specific debug information into it's own separate comdat section which allows the linker to remove duplicates and will greatly reduce the size of the debug and usually puts an end to the Memory Exhausted errors seen in ld.

To read more on this topic see: https://gcc.gnu.org/onlinedocs/gcc/Debu … tions.html


Best Regards,

Kaleb

708

(1 replies, posted in wolfSSL (formerly CyaSSL))

Hi bomellberg,

To view configure help use "./configure --help"

We have a setting there for enabling / disabling pic in the event autoconf needs some assistance in cross-compilation.
By default we attempt to use both:

Optional Packages:
  --with-PACKAGE[=ARG]    use PACKAGE [ARG=yes]
  --without-PACKAGE       do not use PACKAGE (same as --with-PACKAGE=no)
  --with-pic[=PKGS]       try to use only PIC/non-PIC objects [default=use
                          both]

Could you try using:

 --without-pic

and let us know your results?

Kind Regards,

Kaleb

Hi Mark,

config.h is only modified by ./autogen.sh which uses Makefile.am and various other files to generate ./configure script. You should never need to include this file... ever.

The output of the configure script is options.h only.

settings.h is for user to control which math libraries are used, whether to use fast or slow sha operations, and many other things to tweak how the crypto libraries work.
settings.h will allow you to increase or decrease performance and / or footprint size. One example would be "USE_SLOW_SHA" in settings.h will trade fast performance for small footprint (sha will take longer to run but take up less room on an embedded system).

<wolfssl_root>/wolfssl/options.h                 = configure script settings and output
<wolfssl_root>/wolfssl/wolfcrypt/settings.h  = more control over the crypto operations


Sincerest Regards,

Kaleb

Hi csg,

Glad you were able to get this working. If you have any other questions please contact us whenever. Sorry we missed helping you out on this one!

Kind Regards,

Kaleb

Hi csg,

The configure option you are looking for is

--enable-sslv3

We recently disabled this by default as it is vulnerable and a client could potentially
force a server to downgrade to SSL v3 as long as the server supports it and then use
known attacks against that SSL v3 connection.

I would instead suggest updating your curl version if possible (unless their newer versions no longer support Big Endian Architecture).

According to this Stack Exchange question http://unix.stackexchange.com/questions … v3-in-curl the gentleman notes that older versions of curl expect SSLv3 while in newer versions, they (like us) have disabled ssl v3 by default.

Begin Quote from Stack Exchange user ub3rst4r:

I contacted CloudFlare about this issue and they say its because cURL is trying to connect using SSLv3 and they disabled it because of the POODLE vulnerability. I'm able to connect with cURL v7.38.0 on FreeBSD 10 no problems, but not with cURL v7.29.0 on CentOS 6.5.

End Quote

Regards,

Kaleb

Hi sungyun,

We do have a command line utility in development which currently can hash, encrypt, decrypt and benchmark. Development on X509 Certificate generation is next on the to-do list for the utility however is not yet completed. Keep an eye out on this branch: https://github.com/wolfSSL/wolfssl-exam … master/clu for a commit in the future stating X509 Certificate generation is working.

Unfortunately we do not have a time-frame for completion of X509 Certificate generation. It is however an ongoing effort.

Kind Regards,

Kaleb

Hi BKPatel,

Link time solution:
It appears if the errors do not occur at build time but rather at link time then perhaps the errors dealing with pvPortMalloc and vPortFree may be because the freeRTOS implementation is unknown to the linker. Where is the freeRTOS library installed and is it in the LD_LIBRARY_PATH? For example:

export LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:/usr/local/lib/freeRTOS"

Kind Regards,

Kaleb

Hi BKPatel,

Could you double check and ensure that by using "sudo ./configure" it is not restricting access to the resulting library IE making it sudo only?

If your autoconf and autoreconf are up to day there should be no need to tell it to read the configure script in shell (sudo sh). The only necessary commands should be as follows.

./autogen.sh
./configure <options here>
make
sudo make install

(We only have sudo here because default it targets /usr/local/lib which is restricted to sudo)
You can opt to do the following instead:

./configure <other options> --prefix=/home/user/my/custom/install/directory
make
make install

You can install the library where ever you want it so that it resides in a user accessible directory.
All of these options and more can be seen with

./configure --help

Kind Regards,

Kaleb

Hi FHDNS,

Since upgrading xcode have you run:  xcode-select --install

Failing to do so often causes issues with mac command line linking and autoconf.

As a side note:
Unfortunately we over-write CFLAGS in our configure script. Instead use C_EXTRA_FLAGS="-DSOMETHING -DWHATEVER" etc and LD_FLAGS=" ..." etc.

Regards,

Kaleb

Hi BKPatel,

Often times embedded platforms do not support directory structures. Or do not have dirent structure type available. To fix this we have included a pre-processor define NO_WOLFSSL_DIR. Could you try adding that to the pre-processor defines for your project to eliminate this error and let me know your results.

Kind Regards,

Kaleb

Hi BKPatel,

Here is what I have done so far:

Try:

arm-none-eabi-gcc --version

If it is not found do the following:

sudo apt-get install gcc-arm-none-eabi
sudo apt-get install libnewlib-arm-none-eabi

cd into wolfssl directory.
Edit

wolfssl/wolfcrypt/settings.h

by uncommenting

#define FREERTOS

and run the following:

./configure --host=arm-none-eabi C_EXTRA_FLAGS="-O3 -mthumb -mcpu=cortex-m4" LDFLAGS="-lc -lrdimon -specs=rdimon.specs" CC=arm-none-eabi-gcc-4.8.2 

(This assumes you are using cortex-m4, if the mcpu needs to be changed update it to your mcpu)

At this point you will need the project specific header files all in the relevant places. Which unfortunately I can not test as I don't have access to your project etc.

It is my hope that you can get it working from there. If you have any further questions please let us know.


Kind Regards,

Kaleb

Hi BKPatel,

I am getting close. I have the library compiling now but the make step is failing. As soon as I get this working I will send you a step-by-step on how I did it. Some of the steps may need to be modified for your particular board but should not be hard for you.

Expect an update soon.


Regards,

Kaleb

Hi BKPatel,

I am back in the office now. While I can not recommend you use the toolchain I sent previously as it is on github and I'm not sure what the licensing issues may be with that, I can suggest that cross compilation will need to be something along these lines:

./configure --host=arm-none-eabi

I don't believe arm-linux is the correct host to specify from compilation with Tiva C. I will look into this a little more today and see if I can't come up with a compile host platform that is fully supported on linux and/or Unix.

Regards,

Kaleb

Hi BKPatel,

While searching the TI forums for a toolchain to work with I found mention of this repository. I won't have time to test it before the 14th but may be helpful to you in the mean-time.

https://github.com/yuvadm/tiva-c

You'll notice he has tiva-c/third_party/FreeRTOS/

Regards,

Kaleb

Hi BKPatel,

Your issue is clear to me now. What is the problem with TI-RTOS that makes you want to use FREE-RTOS. In researching your questions I have found many questions asked about building freeRTOS with TivaC, most of which have little or no response and all mention this is not a well-documented process. What are the end-goals for your project and are there any deadlines?

I ask because I am leaving for vacation tonight after work and will be out of the office until Sept. 14th. That is when I would begin tracking down a solution / building a toolchain to cross-compile. I know you had not gotten any response from the Texas Instruments support but I would have to point you back their way if you are pressed for time.

The best way to contact TI in this regards is to use http://e2e.ti.com/support/development_tools/ and search for old cases or ask about tool chains for compiling an external c library on linux for use in CCS.

In the recent past we did a build of our libraries with freeRTOS using the Rowley Crossworks compiler. Without looking into it much further my best guess is that it will require something along those lines, but it may be too early to say for sure.

I am aware that the TivaC is typically flashed with a .aem4f formatted library which is abstracted above binary so I'm not sure the current approach of attempting to output a binary library will work on the TivaC processor. I am not 100% on that however. I would need to contact TI and see what they have to say on the matter.
See: http://www.ti.com/lit/ug/spru523i/spru523i.pdf

The file extensions for pre-built libraries provided with the NDK include the following:

.aem4 For Cortex-M4 targets (ELF format, little endian, TI compiler)
.am4g For Cortex-M4 targets (ELF format, little endian, GNU compiler)
.arm4 For Cortex-M4 targets (ELF format, little endian, IAR compiler)
.aem4f For Cortex-M4F floating point targets (ELF format, little endian, TI compiler)
.am4fg For Cortex-M4F floating point targets (ELF format, little endian, GNU compiler)
.arm4f For Cortex-M4F floating point targets (ELF format, little endian, IAR compiler)

Thank You for contacting us. I hope you can resolve this quickly. Otherwise I look forward to supporting you upon my return.

Kind Regards,

Kaleb

Hi delphiwolf,

If you look at this site here: http://www.qnx.com/developers/docs/660/ … andom.html you will see that QNX has both /dev/random and /dev/urandom available so there is no need to create your own random.

If you have any further questions please don't hesitate to ask us!


Regards,

Kaleb

Hi BKPatel,

For our curiousity here at wolfSSL could you give us some details about your project. What are the end goals of your project, how will it be used etc. We are always excited to hear how consumers are using our product!



I have a few questions pertaining to your post:

1. Is there a reason it has to be CyaSSL 3.0.0 and you can not upgrade to wolfSSL 3.3.3 or later?
    (wolfSSL 3.6.6 would be the most recent)
    I ask because while we have support for both, TI has quickly adopted our library with the name-changed to wolfSSL
    as of release wolfSSL 3.3.3
    TI has shifted their development efforts from CyaSSL to wolfSSL.

2. Are you developing in Code Composer Studio or some other IDE/Environment?
    If in CCS see the end of this response for possible solution.

3. Have you seen our quick-start Readme for TivaC and wolfSSL here:
    https://github.com/wolfSSL/wolfssl-exam … /README.md

4. Is there a reason you are trying to build a .lib instead of using the TivaC .aem4f format?



Possible solution if using CCS:

You can follow these steps from the quick-start guide on linking to the .aem4f library. That is the format expected by TivaC.

Right click on your project and select Properties (usually near the bottom)
Under Build -> ARM Linker -> File Search Path

In the browser window on the right under "Include library file or command file as input"
Click the add button and add this line "C:\wolfssl\tirtos\packages\ti\net\wolfssl\lib\wolfssl.aem4f"

In the browser window on the right under "Add dir to library search path"
Click the add button and add this line "C:\wolfssl\tirtos\packages\ti\net\wolfssl\lib"

Kind Regards,

Kaleb

724

(10 replies, posted in wolfSSL (formerly CyaSSL))

Hi Alexander79,

I had not heard back from you in a day or two. I was just checking in to see if you were able to get those example projects working. Let me know if there is anything else.

Kind Regards,

Kaleb

725

(10 replies, posted in wolfSSL (formerly CyaSSL))

Hi Alexander79,

But function wolfSSL_CTX_use_certificate_file() return error while trying parse file server-ecc.pem from WolfSSL library.
I looked inside this function, it's open and read file, but there is some error while parsing.

There are two potential reasons that function would return an error if you use the certificate in our libraries. Either the certificate is not in the correct location or it is expired. Check the dates on the certificate you're using and make sure today's date falls inbetween the ASN before and after date. For example today is Aug 31 2015 so a cert with the following dates is not expired. (Also ensure your computer has the correct date set as our libraries will use your systems date to check expiration on a certificate).

            Not Before: May  7 18:21:01 2015 GMT
            Not After : Jan 31 18:21:01 2018 GMT

Secondly you may have the certificate in a different location then I did. Make sure the path is correct.
This line in the file may need to have a different path then

../certs/server-ecc.pem

depending on where
your project is being built.

if (wolfSSL_CTX_use_certificate_file(ctx, "../certs/server-ecc.pem",

I updated the example this morning https://github.com/wolfSSL/wolfssl-exam … ls-ecdhe.c to allow for debugging also. If you add

DEBUG_WOLFSSL

to your pre-processor definitions you should get more meaningful error codes back. Error codes can be viewed in the following locations:

If your project returns an error between -100 and -300 see wolfssl/wolfssl/wolfcrypt/error-crypt.h
If project returns an error between -301 and -501 see wolfssl/wolfssl/error-ssl.h

Regards,

Kaleb