If we received response in two chunks and the first one completes the
command (result=OK or FAIL), and the second chunk pre-empts command processing,
then we performed processing again rewritting the result back to
TIMEOUT. This would invalidate the command, but also causes an
exception: ESP_MODEM_THROW_IF_ERROR(ESP_ERR_INVALID_STATE)
Fixed by checking if the processing already finished in process_line().
Closes https://github.com/espressif/esp-protocols/issues/426
In the recent DTE refactoring (cb6e03ac) we install terminal callbacks
in the constructor, but the change missed initializing modem_state
in DTE constructors which take two terminals as arguments to work in
DUAL mode.
Race condtion:
* First command timeouted, but the reply came just after evaluation and
set signal variable to GOT_LINE
* Second command should timeout too, but a consistency check validates
that it timeouted and at the same time GOT_LINE (from previous step) and
throws an exception
STR:
* Revert change in esp_modem_dte.cpp
* Run TEST_CASE("DTE command races", "[esp_modem]")
Closes https://github.com/espressif/esp-protocols/issues/110
reworks to clear shared_ptr<> of both command and data terminals
and having DTE own it. When we swith to CMUX mode the ownership is transfered to CMux terminal