pppos_client bug/issue !! [IDFGH-3620]

tabulous
Posts: 34
Joined: Thu Nov 14, 2019 8:58 am

pppos_client bug/issue !! [IDFGH-3620]

Postby tabulous » Tue Jun 30, 2020 2:03 pm

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
Posts: 34
Joined: Thu Nov 14, 2019 8:58 am

Re: pppos_client bug/issue !!

Postby tabulous » Wed Jul 01, 2020 8:59 am

bump anyone ?

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

ESP_cermak
Posts: 69
Joined: Thu Nov 01, 2018 8:32 am

Re: pppos_client bug/issue !!

Postby ESP_cermak » Thu Jul 02, 2020 11:50 am

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
Posts: 34
Joined: Thu Nov 14, 2019 8:58 am

Re: pppos_client bug/issue !!

Postby tabulous » Fri Jul 03, 2020 2:35 pm

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
Posts: 69
Joined: Thu Nov 01, 2018 8:32 am

Re: pppos_client bug/issue !! [IDFGH-3620]

Postby ESP_cermak » Mon Sep 21, 2020 3:30 pm

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.

Who is online

Users browsing this forum: Bing [Bot] and 94 guests