2

In the last couple of weeks I've been developing a boot loader that performs a firmware update on a certain device. The setup is as follows:

  1. The firmware binary and its respective SHA1 hash are stored in a web server;

  2. The device is composed of an ESP8266 and a STM32 microcontroller (STM32F401 or STM32F030, there two hardware versions, but the one I'm using is the F401). The ESP is used only with AT+ commands, i.e., I did not built it's firmware, just used the latest version from Espressif.

The idea is that, the STM32 bootloader should use the ESP to download the firmware hash and binary from the webserver and then boot the firmware if the hash is OK. The download is made using the ESP in passive mode, i.e. the STM has to manually request X bytes to read from the ESP buffer, currently I'm using 1 MTU (1460 bytes).

At first, the connection to the webserver was made using HTTP and everything worked perfectly, however, I had to change it to HTTPS, and that's where the problem starts. After the STM has received around 100kB of the firmware (which has 110kB), the ESP only provides 30 bytes per request (which should be around 1 MTU), thus, making the download time extremely large.

I've already did some digging trying to find out if this is related to the ESP, but didn't find anything. Also, the point where this 30 byte download rate starts to happen isn't always at the 100kB mark, I've tested with a 170kB firmware and It started to happen at 160kB ish, so, it looks like it's always the last 10kB.

I've also added some delays in the firmware when the packet size becomes smaller than 1 MTU, to give more time for the ESP to process the packet, since the SSL decryption stuff takes longer to process; but it did not help.

My question is: is there some characteristic in the HTTPS/SSL protocols that reduces the packet length? What could be the causes of what is happening here?

Eugène Adell
  • 3,089
  • 2
  • 18
  • 34
Leonardo Costa
  • 31
  • 3
  • What do you mean by "packet size"? HTTPS/HTTPS protocols are based on TCP protocol which is a stream protocol, that it is has no packet delimitation. Only the lower level will split large data into packets to send to the network level or merge small data into a single packet at the network level. – fpiette Jun 09 '21 at 18:42
  • @fpiette I mean the packets that the ESP sends to the STM through the serial port. So, you're saying that the HTTPS protocol will never limit the packet size? – Leonardo Costa Jun 09 '21 at 18:55
  • 1
    I am saying the HTTPS protocol is a stream protocol and has no knowledge of a packet. The problem is probably not in the HTTPS protocol but in the communication between the ESP and the micro controller thru RS232. – fpiette Jun 09 '21 at 19:05
  • Is the ESP8266 used as a web server or a web client? – fpiette Jun 09 '21 at 19:11
  • @fpiette as web client, I'm using AT+CIPSTART to connect to the server via SSL – Leonardo Costa Jun 09 '21 at 19:33
  • One easier way to find out where is the problem is to simulate an ESP on a PC to see if the same bottleneck exist. – hcheung Jun 10 '21 at 04:06
  • Any capture file to share ? SSL doesn't reduce packet size, but an overloaded client could reduce its _Receive Window_, forcing packets to be small. – Eugène Adell Jun 11 '21 at 20:04
  • @EugèneAdell that is something I could find out using a packet sniffer right? – Leonardo Costa Jun 12 '21 at 21:09
  • Absolutely, _tcpdump_ or _Wireshark_ would do the job, probably on the web server. – Eugène Adell Jun 13 '21 at 06:33

0 Answers0