Bug in rsi_ftp_file_write_content() causing stack corruption and deadlock

[adam-durridge]

Sending data to an FTP server using multiple calls to rsi_ftp_file_write_content() can cause a serious bug to occur.

It can result in stack corruption (how I found it) and also gets the driver task in an incorrect state causing other Wi-Fi issues like lock ups until timeout.

It is due to how this SAPI call does not generate a response (RX Event) until the last chunk is sent. This https://github.com/SiliconLabs/wiseconnect-wifi-bt-sdk/blob/c95f05486ca38f9a365be5c18161339067b6a36b/sapi/network/protocols/rsi_ftp.c#L506-L510 sets that expected response.

The problem is that on the last chunk, even though this block does not execute due to end_of_file being set, rsi_driver_cb->wlan_cb->expected_response is still equal to RSI_WLAN_RSP_ASYNCHRONOUS from the previous call.

This causes a wait for semaphore instruction to be skipped, https://github.com/SiliconLabs/wiseconnect-wifi-bt-sdk/blob/c95f05486ca38f9a365be5c18161339067b6a36b/sapi/network/protocols/rsi_ftp.c#L524-L528 which causes the wait/post flow of the driver to get out of whack and can produce some nasty effects. In my case a subsequent SAPI call was returning early instead of waiting and when the RX event it should have been waiting on was processed, it filled a buffer that had gone out of scope.

I fixed this one by adding an else clause: else { rsi_driver_cb->wlan_cb->expected_response = RSI_WLAN_RSP_FTP; } I'm not positive this is the appropriate response to use, but it seems to work.