Tokenizing data by '\n' will effectively replace all LF characters by '\0' so checking for phantom lines has to be adjusted:
* minimal empty line is CR only (strlen = 1)
* checking for lines containing CR only
Switching back from data (PPP) mode to command mode must be done is the following sequence:
* No characters entered for T1 time (1 second)
* "+++" characters entered with no characters in between (1 second)
* No characters entered for T1 timer (1 second)
(per specification of SIM800 SIM800_Series_AT_Command_Manual_V1.09.pdf)
Related https://github.com/espressif/esp-idf/issues/7608
In the POST section of `http_native_request` headers are not fetched. thus, just commenting out the GET request example would result in a `status` and `content_length` of `0` being reported (quite confusing).
(Plus, it should log `HTTP POST Status` here, instead of `HTTP GET Status`.)
Merges https://github.com/espressif/esp-idf/pull/7696
In esp_dte_handle_line(), it tokenize the data to call handlers separately
for each *line*. So it needs to post the tokenized data when report unknown
line instead of the first token (which could be a '\r' in my test).
Fixes: 336de29413 ("Examples/pppos_client: Fix manual parsing to accept unexpected lines")
Signed-off-by: Axel Lin <axel.lin@gmail.com>
- Can be used to get connection or client information (SSL context)
- E.g. Client certificate, Socket FD, Connection state, etc.
- Added example callback for getting client certificate information in 'https_server/simple' example
Closes https://github.com/espressif/esp-idf/issues/7479
Replaced hyphens with underscores in examples
project definition for all examples which had
hyphens in their project name. dpp-enrollee is
an exceptions because the name matches the
project directory name while the project
directory also contains hyphens.
OpenSSL component will be discontinued in ESP-IDF v5.x. The only official TLS API will be esp-tls
Add docs warning about deprecation in v5.x
Removed all examples demonstrating usage of openssl in IDF
Regression from a90817cda0 that caused
parsing exit in case of an unexpected result found (line handler
reported ESP_FAIL). Prevously if any error found in the line handler we
just posted an unexpected event, but continued with parsing. Fixed by
allowing for further parsing.
Related: https://github.com/espressif/esp-idf/issues/7176
Due to these problems
* possible race condition, two events competing
* pattern detection work a little different for different IDF versions
* switching between pattern detection and data reading is complicated
* using just data events is easier for porting to a different communication peripheral
These changes were made:
* Removed the UART pattern detection entirely
* Used manual pattern detection after reading plain data from the UART
Closes https://github.com/espressif/esp-idf/issues/7176
