ESP8266WiFi SSL Support

[wickwire]

Hi,

I've finally had the time to start fiddling with my Oaks and Acorns and I'm trying to use the MQTT messaging protocol with the Oak.

So far I've been successful in writing up a basic sketch that connects the Oak to CloudMQTT and writes to a given topic in a loop, using PubSubClient.

I then decided to go MQTT and SSL, a feature which CloudMQTT supplies and I've also used with success recently, but with a regular ESP8266-12 module running the NodeMCU firmware.

Back to Oak, I began my investigation at PubSubClient by looking at WiFiClientSecure and if correct, I would then need to also include a self-signed certificate for the encryption to work - which I have done already.

At this point I realized that the latest OakCore release 1.0.6 seems to be based on Arduino Core 2.0.0, and it also seems that the functions WiFiClientSecure::setCertificate and WiFiClientSecure::setPrivateKey I should use to set the certificates, aren't available in [email protected].

So I decided to try and bump up the Arduino Core base on OakCore from 2.0.0 to 2.3.0, at which point I got stuck.

Finally and hopefully with some help, could someone clarify if any of the assumptions made above is correct, if the conclusion would be the correct way to go, and any known limitations currently on achieving my end goal?
If on the other hand I'm completely missing the mark here, could someone point me in the right direction?

My ultimate goal is to get the Oaks to talk MQTT through CloudMQTT and use them with Crouton, the IoT Dashboard - which is already happening, but not via MQTT with SSL.

Thank you for your time!

[wickwire]

Actually it seems that the setCertificate and setPrivateKey were introduced at 2.1.0 so I might get away with bumping the oak core just to 2.1.0

[wickwire]

Still not working for the Oak - but it is working for a generic ESP8266-01 running Arduino ESP8266 2.0.0 and the fingerprint method.

I used the following commands to obtain cloudmqtt's fingerprint hash:

$ echo -n | openssl s_client -connect m11.cloudmqtt.com:22002 > cloudmqtt.pem
$ openssl x509 -noout -in cloudmqtt.pem -fingerprint -sha1

SHA1 Fingerprint=A5:02:FF:13:99:9F:8B:39:8E:F1:83:4F:11:23:65:0B:32:36:FC:07

I then used a simple sketch to connect the ESP to cloudmqtt and it worked properly.

Trying to do it on the Oak however, resulted in a kernel panic and the ax_port_malloc error. I tried from version 1.0.2 all the way up to 1.0.6 and the result is always the same.

In order to either rule out or justify any issues with the code I'm using, I'm attaching two files: the ESP version and the Oak version, so if anyone manages to figure out why isn't the Oak working like the ESP is, please let me know.

generic_esp8266_mqtt_secure.txt
oak_mqtt_secure.txt

[joeycortez42]

@wickwire I was trying to do the same at release, but took a few months off to let the Oak get more stable. I'm going to look into what you did over the holiday break and hopefully provide some insight.

[eiannone]

Hi, I have the same problem with WiFiClientSecure. I get the following error when calling connect() method:

Panic /oakCore/cores/oak/ESP8266WiFi/src/WiFiClientSecure.cpp:387 ax_port_malloc

Has anyone managed to solve this?

[wickwire]

Hi, I guess it is still in the same state as before, at least by looking at the current repo state (fairly unchanged since last year).

It could be something solvable by poking into memory management, but I can't say for sure. Aside from that, using the regular method i.e. without WiFi secure, it works.

Maybe this thread can help esp8266/Arduino#1159

[wickwire]

Just a quick update on this issue:

This week I had the time to fiddle with the Oak once more and by replacing the original Oak firmware with ESP8266 Arduino I was able to use my Oak to publish recurring messages to the CloudMQTT broker, over SSL:

ESP8266 Arduino 2.3.0
PubSubClient 2.6.0

Instructions: http://nog3.net/2017/06/05/removing-particle-from-oak/

So at least, this would confirm that the hardware is capable and that quite possibly there is something going on with the Oak firmware itself.