Switch to BearSSL

Continue with last week problem of PUT request failure after implementing SSL, I look through every line of the code again and again and search through every keyword I could think of on the web but did not find much useful information. Without a clue on how to proceed, I asked for help from Dr. Shawn. After trials and errors, we found that the PUT request does success when the file we are sending is less than 8kbyte, but any file that is larger than 8kbyte fail. Then we try to alter other configuration of the harmony or curl but none of that work. By tracking the package curl sent we found that when we are sending a big file, the size of each separate package we sent is 16kbyte by default. Even though we have yet found the fault, but I am really amazed by how determinative Dr. Shawn is when approaching a problem, he has got plan A, B, C, D ,E…. in his mind and the capability to conclude the results and come up with the new plan.
Although we have yet found the solution, but I will say that each try is a progressive and “successful” failure. Without his advice I was so lost and blind, don’t even know which direction to look at. That night I started to think “why?”, why did I get stuck? Was it because of the lack of relevant resources on the internet? No, that’s just an excuse. I was expecting someone on the internet has faced the same problem as I did and have the solution prepared right there waiting for me. That is how spoiled I am by the internet, there is something I am lacking. Thus I started to study the details of the basic of TCP/IP communication, the five layer software model which consist of Physical Layer, Data Link Layer, Network Layer, Transport Layer and Application Layer, their content, roles and relation to the slightest bit. Though still no clue on the fault I am facing, but it does resolve some misunderstanding I have that I was wasting time on. Then I found documentation on Maximum Fragment Length Negotiation Extention on TLS1.2 specified in RFC 6066 that the client can negotiate the maximum fragment size, which is 16kbyte by default, in extended client hello to mitigate the memory or bandwidth constraint. In wolfSSL, the desired maximum fragment size can be set via function wolfSSL_CTX_UseMaxFragment(), then the negotiation will be done for all SSL object created from this context. The problem is the “negotiation” can only be started by the client, the server can only accept because at that time, server are usually huge and the client is probably the one facing the memory limitation issue. But now we are building a board server, which means a server with memory constraint, yet we have no option to chose the fragment size. They should really reconsider about this as the time of IOT is already here, which means more and more tiny things are getting connected into the internet so memory constraint is a big issue.
Then I was assigned a task to write a firmware with only vanilla harmony network presentation framework and wolfSSL, without any other feature, and try to read large file from net in order to make sure the fault was not caused by other parts of the software or configuration as we were running FreeRTOS operating system with multithread on top of the network presentation. Yup, it fails again with any file larger than 8kbyte just as before.
Now, my next objective is to abort the Harmony Network Presentation Layer and the included WolfSSL we were using and handle the network and SSL encryption myself directly with TCP/IP stack and BearSSL. BearSSL is another implementation of SSL/TLS protocol that is smaller in size and has put in more consideration into the embedded system. After understanding the example provided by bearSSL I am starting to implement bearSSL on TCP/IP server demo provided by Harmony, then only integrate it in RED6 after I am sure it works…