pppos_client bug/issue !! [IDFGH-3620]

[tabulous]

There is an issue with this example, if the modem sends back a char(s) of data when switched on the ppp control block is null.
This is because in the example

esp_modem_setup_ppp(dte);

is called afterwards, this means esp_dte->ppp is null
esp_dte->ppp = pppapi_pppos_create(&(esp_dte->pppif), pppos_low_level_output, on_ppp_status_changed, dte);

i cant see how this example ever worked really !!!

[tabulous]

bump anyone ?

Or is this going to be another no response ?
Support on here is terrible.

[ESP_cermak]

Hi tabulous,

This example just demonstrates interfacing modems that happen to be in command mode after startup, so it is okay to sync first using generic AT commands and then create and start the ppp network interface after that.

[tabulous]

The issue is if the modem sends 1 byte of data before the ppp is init....... a UART_DATA event type is generated thus this calls esp_handle_uart_data and tries to use pppos_input_tcpip(esp_dte->ppp, esp_dte->buffer, length);

esp_dte->ppp is not init so it crashes




static void uart_event_task_entry(void *param)
{
uart_event_t event;
esp_modem_dte_t *esp_dte = (esp_modem_dte_t *)param;

while (1)
{
if (xQueueReceive(esp_dte->event_queue,
&event, pdMS_TO_TICKS(100)))
{
switch (event.type)
{
case UART_DATA:
// esp_handle_uart_data(esp_dte);
break;

[ESP_cermak]

okay, understand now, thanks for explaining.
There's indeed a race condition, as we first switch over to the command mode and then initialise the PPP network interface. This is true for releases v4.0 and earlier. There was a major refactoring of the PPP client and the esp-modem in v4.1 to use the esp-netif (ESP-IDF abstraction to network interfaces) and I believe there's no such issue in the latest version as we first init the network interface and after we switch to the PPP mode, we just *attach* the esp-modem to the initialised interface.