326

(1 replies, posted in wolfMQTT)

Hello Gil,

Thank you for contacting wolfSSL Support. Is your application based on the wolfMQTT example from Microchip? Have you reviewed the latest version from the Harmony 3 Content Manager?

It looks like there were a number of changes to address initialization (and uninit) using the "Net_Glue" component.

Without having seen the whole execution loop, I can't say for sure. In the snippet you provided I don't see in where the state is being reset.

Thanks,
Eric @ wolfSSL Support

EDIT: I see the state reset, now. But without seeing the rest of the application loop I don't know if it is being reinitialized.

327

(5 replies, posted in wolfSSL)

Good to hear that you were able to resolve the issue.

Thanks again for contacting wolfSSL and best of luck with your project!

328

(7 replies, posted in wolfSSL)

Hi Okba,

The callbacks are generally used for setting up a hardware based encryption engine. Could you tell us more about your project? Please feel free to use support@wolfssl.com if you'd prefer to keep the thread private.

Kind regards,

Eric Blankenhorn
wolfSSL Support

329

(5 replies, posted in wolfSSL)

Hello @I_AM_MAD

Thank you for contacting wolfSSL Support. What are are you minimum requirements, both in terms of functionality and ROM/RAM size?

We have a comprehensive guide to optimizing the wolfSSL library:
https://www.wolfssl.com/docs/tuning-guide/

If you still have questions please feel free to ask here or at support@wolfssl.com

Kind regards,

Eric Blankenhorn
wolfSSL Support

330

(2 replies, posted in wolfSSL)

Hi Kamal,

Thanks for reaching out to wolfSSL.

We have a bare-metal example for the older KEIL software packs but I'm unsure if they would work out of the box for the MDK4 on LPC3250.

You can have a look at the following link:
https://github.com/wolfSSL/wolfssl/tree … DE/MDK-ARM

Please let us know if it works for you.

Best Regards,
Eric Blankenhorn
wolfSSL Support

Hi Ben,

That's great news on the config settings!

The cipher suites we support are static NTRU ones. So what we currently support is an option of RSA or NTRU, but not both. The use of both at the same time can only be done currently with QSH, which is an extension to add some random data to the pms using NTRU.

More about QSH:
https://www.wolfssl.com/quantum-safe-wolfssl-2/

Kind regards,
Eric
wolfSSL Support

Hello @Benon

Thank you for contacting wolfSSL support. Could you post the actual settings header file you are using?

Thanks,
Eric
wolfSSL Support

Hi @niemilkm,

I see some similar problems when searching for this issue:
https://stackoverflow.com/questions/422 … -directory

Thanks,
Eric
wolfSSL Support

Hi Gil,

Thank you for providing more information. The "connect" API is outside of the wolfMQTT library. Can you reproduce this problem with any of the other Harmony network examples?

Thanks,
Eric Blankenhorn
wolfSSL Support

Hi Gil,

Thanks for contacting wolfSSL support. I see that there was a bugfix that may pertain to the issue you are having:
https://github.com/wolfSSL/wolfMQTT/issues/88

Could you check and see if this fixes the issue of MqttClient_NetConnect() returning rc == MQTT_CODE_CONTINUE forever ?

Thanks,
Eric Blankenhorn
wolfSSL Support

336

(5 replies, posted in wolfMQTT)

Hi Peter,

I fixed the issue you reported with MqttClient_Publish_ex. You can review the update in https://github.com/wolfSSL/wolfMQTT/pull/95

Thanks,
Eric Blankenhorn
wolfSSL Support

337

(5 replies, posted in wolfMQTT)

Hi Peter,

I'm glad you had an opportunity to test the changes and thank you for your feedback. I will have a look into the return value from MqttClient_Publish_ex. I think your suspicion is correct regarding the publish throughput.

Thanks,
Eric Blankenhorn
wolfSSL Support

338

(5 replies, posted in wolfMQTT)

Hi PeterL,

The new methods for publishing are available to review in https://github.com/wolfSSL/wolfMQTT/pull/92

This update adds two methods: A callback that is executed from the new MqttClient_Publish_ex API; and it is now possible to simply call MqttClient_Publish successively when the payload buffer size is smaller than the total payload size as set in the MqttPublish structure parameter. The example for the client firmware push was modified to use the new publish callback.

Best regards,
Eric Blankenhorn,
wolfSSL Support

There was some existing code to handle the device serial number OID, but it was missing from the structures you were attempting to use. I added serial number elements to the Cert and DecodedCert structures, and modified the internal methods to support these. You can review these changes in https://github.com/wolfSSL/wolfssl/pull/1826

Thanks,
Eric B
wolfSSL Support

340

(6 replies, posted in wolfSSL)

Hi @KamKon,

Great to hear that you have the library working correctly now. Do you have any further questions or issues?

Best regards,

Eric Blankenhorn
wolfSSL Support

341

(6 replies, posted in wolfSSL)

Hi Kamil,

From the FreeRTOS reference for the FreeRTOS_recv() :

If a time out occurred before data could be received then 0 is returned.

The wolfSSL code is expecting more data at this point, but the OS has timed out waiting. You could try increasing the timeout for the TCP socket, or perhaps the server is not responding. The packet capture could provide some more insight.

Thanks,

Eric Blankenhorn
wolfSSL Support

342

(6 replies, posted in wolfSSL)

Hi Kamil,

I am looking into the issue you reported. Could you also send a packet capture of the two cases?

Best regards,

Eric Blankenhorn
wolfSSL Support

Hi @SamSam

This issue was due to a bug in the wolfSSL library. The code changes are available for you to review here:
https://github.com/wolfSSL/wolfssl/pull/1772

The two use cases are both passing now.

Please let us know when you have had an opportunity to test the changes.

Best regards,

Eric Blankenhorn
wolfSSL Support

Hi Sam Sam,

I am trying to reproduce the issues you have reported. For now I would like to try using only wolfSSL, we can add CURL in later.

I have configured wolfSSL using:

$ ./configure --enable-all

I am able to connect to the "www.tvnow.de" host using the example client:

$ ./examples/client/client -h 217.118.168.60 -p 443 -d -x -C -g -i
peer's cert info:
 issuer : /C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA
 subject: /OU=Domain Control Validated/OU=PositiveSSL Wildcard/CN=*.tvnow.de
 altname = tvnow.de
 altname = *.tvnow.de
 serial number:1c:6b:0d:e8:9a:44:80:03:c3:a1:0e:03:bd:8e:6a:92 
SSL version is TLSv1.2
SSL cipher suite is TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
SSL curve name is SECP256R1
Client Random : C70D72DD1A0B6FD211139FF47EF63367DB43A16D7A3AC3807CF5C8649B4B1021
SSL connect ok, sending GET...
HTTP/1.0 302 Found
Location: https://www.tvnow.de/index.html
Server: BigIP
C
onnection: close
Content-Length: 0

Also, I can specify the SSL version with the "-v <num>" option:

./examples/client/client -h 217.118.168.60 -p 443 -d -x -C -g -i -v 2
./examples/client/client -h 217.118.168.60 -p 443 -d -x -C -g -i -v 3

Only the values 2 and 3 for SSL version are successful with that host.

Does this match your results so far?

Thanks,
Eric Blankenhorn
wolfSSL Support

345

(2 replies, posted in wolfSSL)

Excellent. Thanks for your help.

346

(2 replies, posted in wolfSSL)

We have found a compiler error in "wolfSSL_X509_load_certificate_file" when building with the "NO_FILESYSTEM" define enabled.

os/networking/ssl/lite/src/ssl.c: In function 'wolfSSL_BIO_free':
os/networking/ssl/lite/src/ssl.c:5781:21: warning: implicit declaration of function 'close' [-Wimplicit-function-declaration]
os/networking/ssl/lite/src/ssl.c: In function 'wolfSSL_X509_load_certificate_file':
os/networking/ssl/lite/src/ssl.c:7187:5: error: unknown type name 'XFILE'
os/networking/ssl/lite/src/ssl.c:7198:5: warning: implicit declaration of function 'XFOPEN' [-Wimplicit-function-declaration]
os/networking/ssl/lite/src/ssl.c:7199:17: error: 'XBADFILE' undeclared (first use in this function)
os/networking/ssl/lite/src/ssl.c:7199:17: note: each undeclared identifier is reported only once for each function it appears in
os/networking/ssl/lite/src/ssl.c:7200:5: warning: implicit declaration of function 'XFSEEK' [-Wimplicit-function-declaration]
os/networking/ssl/lite/src/ssl.c:7200:21: error: 'XSEEK_END' undeclared (first use in this function)
os/networking/ssl/lite/src/ssl.c:7201:5: warning: implicit declaration of function 'XFTELL' [-Wimplicit-function-declaration]
os/networking/ssl/lite/src/ssl.c:7202:5: warning: implicit declaration of function 'XREWIND' [-Wimplicit-function-declaration]
os/networking/ssl/lite/src/ssl.c:7207:13: warning: implicit declaration of function 'XFCLOSE' [-Wimplicit-function-declaration]
os/networking/ssl/lite/src/ssl.c:7212:5: warning: implicit declaration of function 'XFREAD' [-Wimplicit-function-declaration]
make[2]: *** [output/csgnu_arm/at91sam9263ek/net_44/objs/os/networking/ssl/lite/src/ssl.o] Error 1

If I add the compiler conditional "#ifndef NO_FILESYSTEM" around "wolfSSL_X509_load_certificate_file" then the problem is resolved.