Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PPPOS reconnection/disconnection faliuer after sometime. (IDFGH-6123) #7803

Closed
3 tasks
AdiXPS opened this issue Oct 31, 2021 · 15 comments
Closed
3 tasks

PPPOS reconnection/disconnection faliuer after sometime. (IDFGH-6123) #7803

AdiXPS opened this issue Oct 31, 2021 · 15 comments
Labels
Awaiting Response awaiting a response from the author Resolution: Done Issue is done internally Status: Done Issue is done internally

Comments

@AdiXPS
Copy link

AdiXPS commented Oct 31, 2021

Environment

  • Development Kit: Custom
  • Module or chip used: ESP32-PICO-D4
  • IDF version 4.3
  • Build System: idf.py
  • Compiler version `xtensa-esp32-elf-gcc
  • Operating System: Windows
  • (Windows only) environment type: ESP Command Prompt.
  • Using an IDE?: Yes | VS CODE
  • Power Supply: |Battery]

Problem Description

I've tried @david-cermak example, basiclly I found two main issues after leave it running for a couble of hours:

1-after awhile, I'am getting the famous "GGuru Mediation Error: Core 1 panic'ed (LoadProhibited). Exception was unhandled." One more thing here, I notice that its showing Core 1 while I dont have any task running on it..?

`Guru Meditation Error: Core 1 panic'ed (LoadProhibited). Exception was unhandled.

Core 1 register dump:
PC : 0x400d52e5 PS : 0x00050031 A0 : 0x400826f8 A1 : 0x3ffb0dc0
0x400d52e5: uart_ll_get_intsts_mask at C:/esp4/esp-idf/components/hal/esp32/include/hal/uart_ll.h:170
(inlined by) uart_rx_intr_handler_default at C:/esp4/esp-idf/components/driver/uart.c:746

0x400826f8: _xt_lowint1 at C:/esp4/esp-idf/components/freertos/port/xtensa/xtensa_vectors.S:1105

A2 : 0x3ffb7760 A3 : 0x3ffb0aa0 A4 : 0x00000091 A5 : 0x8ca96391
A6 : 0x00000910 A7 : 0x00000000 A8 : 0x00000001 A9 : 0x3ffb0d50
A10 : 0x00000000 A11 : 0x00000000 A12 : 0x80103e4e A13 : 0x3ffb86c0
A14 : 0x3ffb2f6c A15 : 0x3ffb86e0 SAR : 0x0000001a EXCCAUSE: 0x0000001c
EXCVADDR: 0x00000008 LBEG : 0x00000000 LEND : 0x00000000 LCOUNT : 0x00000000

Backtrace:0x400d52e2:0x3ffb0dc0 0x400826f5:0x3ffb0e10 0x40118563:0x3ffb8710 0x400d845b:0x3ffb8730 0x40088505:0x3ffb8750 0x4008a525:0x3ffb8770
0x400d52e2: uart_ll_get_intsts_mask at C:/esp4/esp-idf/components/hal/esp32/include/hal/uart_ll.h:170
(inlined by) uart_rx_intr_handler_default at C:/esp4/esp-idf/components/driver/uart.c:746

0x400826f5: _xt_lowint1 at C:/esp4/esp-idf/components/freertos/port/xtensa/xtensa_vectors.S:1105

0x40118563: cpu_ll_waiti at C:/esp4/esp-idf/components/hal/esp32/include/hal/cpu_ll.h:183
(inlined by) esp_pm_impl_waiti at C:/esp4/esp-idf/components/esp_pm/pm_impl.c:827

0x400d845b: esp_vApplicationIdleHook at C:/esp4/esp-idf/components/esp_common/src/freertos_hooks.c:63

0x40088505: prvIdleTask at C:/esp4/esp-idf/components/freertos/tasks.c:3839 (discriminator 1)

0x4008a525: vPortTaskWrapper at C:/esp4/esp-idf/components/freertos/port/xtensa/port.c:168

ELF file SHA256: d843f1542d225f73`

2-Mostly the crash is happening when stopping PPP only if there is existing connection. If for any reason the disconnection happen from host (ISP; no IP EVENT) its very stable.

[0;32mI (511128) esp-modem: entering esp_modem_stop_ppp...[0m [0;31mE (512058) esp-modem: esp_dte_handle_line(124): handle line failed[0m [0;33mW (512058) pppos_example: Unknow line received: ~!E[0m Guru Meditation Error: Core 1 panic'ed (LoadProhibited). Exception was unhandled.

Always getting Unknow line received: ~!E.

When I monitor the modem I am getting this transmitted:

"10/30/2021 3:50:38 PM",CONNECT 150000000 "10/30/2021 3:50:38 PM",~ÿ}#À!}!¦} }9}"}&} } } } }#}%Â#}%}%}&Öcº÷}'}"}(}"£�~~ÿ}#À!}"}!} }4}"}&} } } } }%}&M§T}$}'}"}(}"³ø~~ÿ}#À!}!§} }8}"}&} } } } }#}$À#}%}&Öcº÷}'}"}(}"í×~~ÿ}#À!}+¨} }(Öcº÷CC~~À# ý0~~€!< jà~~€! "10/30/2021 3:50:39 PM", -ø0~~€!= ¶º~~€! "10/30/2021 3:50:39 PM",™ m�Të7ƒTë9æÄG~~€! "10/30/2021 3:50:39 PM",™ m�Të7ƒTë9æõÙ~~!E ;å@ U­Ä "10/30/2021 3:50:43 PM",E "10/30/2021 3:50:43 PM",™ m»�bµÇª€ }]y
"10/30/2021 3:50:43 PM",¼}^€bV_9 x(~
"10/30/2021 3:50:43 PM",OK

"10/30/2021 3:50:47 PM",OK
"10/30/2021 3:50:59 PM",~!E (®²@ 3Ú¶13‚.
"10/30/2021 3:50:59 PM",™ m»âpK.hì¶Ñ�P s‘ “~~!E ;æ@ U­Ã "10/30/2021 3:51:23 PM",E "10/30/2021 3:51:23 PM",™ m»�bµÇª€ áw
"10/30/2021 3:51:23 PM",¼�cV_9 µ~~!E 0 @ sIa13‚.`

seems the esp sending +++ and ath but the modem keep sending garbage? or it didnt actually exit data mode?

here is sample from modem when there is no issues..:

`"10/30/2021 5:05:32 PM",CONNECT 150000000
"10/30/2021 5:05:32 PM",ÿ}#À!}!}1} }9}"}&} } } } }#}%Â#}%}%}&Ö¨N½}'}"}(}"°}#ÿ}#À!}"}!} }4}"}&} } } } }%}&×É£Õ}'}"}(}"_Dÿ}#À!}!}2} }8}"}&} } } } }#}$À#}%}&Ö¨N½}'}"}(}"¡¿ÿ}#À!}+}3} }(Ö¨N½œ°À# ý0€!Ø ªŠ€!
"10/30/2021 5:05:34 PM", -ø0€!Ù vЀ!
"10/30/2021 5:05:34 PM",AN�Të7ƒTë9毥~~€!
"10/30/2021 5:05:34 PM",AN�Të7ƒTë9æž;

"10/30/2021 5:05:38 PM",OK

"10/30/2021 5:05:41 PM",OK

"10/30/2021 5:05:52 PM",OK`

Expected Behavior

Should successfully connect and disconnect.

Actual Behavior

Crashes after period of time..

Steps to reproduce

  1. step1
  2. ...

// If possible, attach a picture of your setup/wiring here.

Code to reproduce this issue

// the code should be wrapped in the ```cpp tag so that it will be displayed better.
#include "esp_log.h"

    ESP_ERROR_CHECK(esp_netif_init());
    ESP_ERROR_CHECK(esp_event_loop_create_default());
    ESP_ERROR_CHECK(esp_event_handler_register(IP_EVENT, ESP_EVENT_ANY_ID, &on_ip_event, NULL));
    ESP_ERROR_CHECK(esp_event_handler_register(NETIF_PPP_STATUS, ESP_EVENT_ANY_ID, &on_ppp_changed, NULL));

    while (1) {
        //xEventGroupWaitBits(event_group, READINGS_READY, pdFALSE, pdTRUE, portMAX_DELAY);

    #if CONFIG_LWIP_PPP_PAP_SUPPORT
        esp_netif_auth_type_t auth_type = NETIF_PPP_AUTHTYPE_PAP;
    #elif CONFIG_LWIP_PPP_CHAP_SUPPORT
        esp_netif_auth_type_t auth_type = NETIF_PPP_AUTHTYPE_CHAP;
    #elif !defined(CONFIG_EXAMPLE_MODEM_PPP_AUTH_NONE)
    #error "Unsupported AUTH Negotiation"
    #endif

        /* create dte object */
        esp_modem_dte_config_t config = ESP_MODEM_DTE_DEFAULT_CONFIG();
        /* setup UART specific configuration based on kconfig options */
        config.tx_io_num = CONFIG_EXAMPLE_MODEM_UART_TX_PIN;
        config.rx_io_num = CONFIG_EXAMPLE_MODEM_UART_RX_PIN;
        config.rts_io_num = CONFIG_EXAMPLE_MODEM_UART_RTS_PIN;
        config.cts_io_num = CONFIG_EXAMPLE_MODEM_UART_CTS_PIN;
        config.rx_buffer_size = CONFIG_EXAMPLE_MODEM_UART_RX_BUFFER_SIZE;
        config.tx_buffer_size = CONFIG_EXAMPLE_MODEM_UART_TX_BUFFER_SIZE;
        config.event_queue_size = CONFIG_EXAMPLE_MODEM_UART_EVENT_QUEUE_SIZE;
        config.event_task_stack_size = CONFIG_EXAMPLE_MODEM_UART_EVENT_TASK_STACK_SIZE;
        config.event_task_priority = CONFIG_EXAMPLE_MODEM_UART_EVENT_TASK_PRIORITY;
        config.dte_buffer_size = CONFIG_EXAMPLE_MODEM_UART_RX_BUFFER_SIZE / 2;
        modem_dte_t *dte = esp_modem_dte_init(&config);
        /* Register event handler */
        ESP_ERROR_CHECK(esp_modem_set_event_handler(dte, modem_event_handler, ESP_EVENT_ANY_ID, NULL));

        // Init netif object
        esp_netif_config_t cfg = ESP_NETIF_DEFAULT_PPP();
        esp_netif_t *esp_netif = esp_netif_new(&cfg);
        assert(esp_netif);

        void *modem_netif_adapter = esp_modem_netif_setup(dte);
        esp_modem_netif_set_default_handlers(modem_netif_adapter, esp_netif);

        modem_dce_t *dce = NULL;
        /* create dce object */
    #if CONFIG_EXAMPLE_MODEM_DEVICE_SIM800
            dce = sim800_init(dte);
    #elif CONFIG_EXAMPLE_MODEM_DEVICE_BG96
            dce = bg96_init(dte);
    #elif CONFIG_EXAMPLE_MODEM_DEVICE_SIM7600
            dce = sim7600_init(dte);
    #else
    #error "Unsupported DCE"
    #endif
    assert(dce != NULL);
    ESP_ERROR_CHECK(dce->set_flow_ctrl(dce, MODEM_FLOW_CONTROL_NONE));

    /* Print Module ID, Operator, IMEI, IMSI */
    ESP_LOGI(TAG, "Module: %s", dce->name);
    ESP_LOGI(TAG, "Operator: %s", dce->oper);
    ESP_LOGI(TAG, "IMEI: %s", dce->imei);
    ESP_LOGI(TAG, "IMSI: %s", dce->imsi);
    /* Get signal quality */
    uint32_t rssi = 0, ber = 0;
    ESP_ERROR_CHECK(dce->get_signal_quality(dce, &rssi, &ber));
    ESP_LOGI(TAG, "rssi: %d, ber: %d", rssi, ber);
    /* Get battery voltage */
    uint32_t voltage = 0, bcs = 0, bcl = 0;
    ESP_ERROR_CHECK(dce->get_battery_status(dce, &bcs, &bcl, &voltage));
    ESP_LOGI(TAG, "Battery voltage: %d mV", voltage);
    /* setup PPPoS network parameters */
    #if !defined(CONFIG_EXAMPLE_MODEM_PPP_AUTH_NONE) && (defined(CONFIG_LWIP_PPP_PAP_SUPPORT) || defined(CONFIG_LWIP_PPP_CHAP_SUPPORT))
    esp_netif_ppp_set_auth(esp_netif, auth_type, CONFIG_EXAMPLE_MODEM_PPP_AUTH_USERNAME, CONFIG_EXAMPLE_MODEM_PPP_AUTH_PASSWORD);
    #endif
        /* attach the modem to the network interface */
        esp_netif_attach(esp_netif, modem_netif_adapter);
        /* Wait for IP address or disconnect */
        EventBits_t uxBits = xEventGroupWaitBits(event_group, DISCONNECT_BIT | CONNECT_BIT, pdTRUE, pdFALSE, portMAX_DELAY);
        
        /* Adi - check which bit is triggered */
        if( ( uxBits & DISCONNECT_BIT ) != 0 )
        {
            /* xEventGroupWaitBits() returned because just DISCONNECT_BIT was set. */
            ESP_LOGI(TAG, "DISCONNECT_BIT TRIGGERD");

        }
        else if( ( uxBits & CONNECT_BIT ) != 0 )
        {
            /* xEventGroupWaitBits() returned because just CONNECT_BIT was set. */
            ESP_LOGI(TAG, "CONNECTED!");


        }
        
        

        ESP_LOGI(TAG, "STOPPING");
        
        
        ESP_ERROR_CHECK(esp_modem_stop_ppp(dte));
        esp_modem_netif_clear_default_handlers(modem_netif_adapter);
        esp_modem_netif_teardown(modem_netif_adapter);
        esp_netif_destroy(esp_netif);
        ESP_LOGD(TAG, "netif destroyed");
        xEventGroupWaitBits(event_group, STOP_BIT, pdTRUE, pdTRUE, portMAX_DELAY);
        ESP_ERROR_CHECK(dce->deinit(dce));
        ESP_ERROR_CHECK(dte->deinit(dte));
        ESP_LOGI(TAG, "All deleted");
  }

// If your code is longer than 30 lines, GIST is preferred.

Debug Logs

2ndcrash
`[0;32mI (511128) esp-modem: entering esp_modem_stop_ppp...[0m
[0;31mE (512058) esp-modem: esp_dte_handle_line(124): handle line failed[0m
[0;33mW (512058) pppos_example: Unknow line received: ~!E[0m
Guru Meditation Error: Core  1 panic'ed (LoadProhibited). Exception was unhandled.`

Always getting Unknow line received: ~!E.


************************************************* 1st crash
`Guru Meditation Error: Core  1 panic'ed (LoadProhibited). Exception was unhandled.

Core  1 register dump:
PC      : 0x400d52e5  PS      : 0x00050031  A0      : 0x400826f8  A1      : 0x3ffb0dc0
0x400d52e5: uart_ll_get_intsts_mask at C:/esp4/esp-idf/components/hal/esp32/include/hal/uart_ll.h:170
 (inlined by) uart_rx_intr_handler_default at C:/esp4/esp-idf/components/driver/uart.c:746

0x400826f8: _xt_lowint1 at C:/esp4/esp-idf/components/freertos/port/xtensa/xtensa_vectors.S:1105

A2      : 0x3ffb7760  A3      : 0x3ffb0aa0  A4      : 0x00000091  A5      : 0x8ca96391  
A6      : 0x00000910  A7      : 0x00000000  A8      : 0x00000001  A9      : 0x3ffb0d50
A10     : 0x00000000  A11     : 0x00000000  A12     : 0x80103e4e  A13     : 0x3ffb86c0  
A14     : 0x3ffb2f6c  A15     : 0x3ffb86e0  SAR     : 0x0000001a  EXCCAUSE: 0x0000001c  
EXCVADDR: 0x00000008  LBEG    : 0x00000000  LEND    : 0x00000000  LCOUNT  : 0x00000000  

Backtrace:0x400d52e2:0x3ffb0dc0 0x400826f5:0x3ffb0e10 0x40118563:0x3ffb8710 0x400d845b:0x3ffb8730 0x40088505:0x3ffb8750 0x4008a525:0x3ffb8770
0x400d52e2: uart_ll_get_intsts_mask at C:/esp4/esp-idf/components/hal/esp32/include/hal/uart_ll.h:170
 (inlined by) uart_rx_intr_handler_default at C:/esp4/esp-idf/components/driver/uart.c:746

0x400826f5: _xt_lowint1 at C:/esp4/esp-idf/components/freertos/port/xtensa/xtensa_vectors.S:1105

0x40118563: cpu_ll_waiti at C:/esp4/esp-idf/components/hal/esp32/include/hal/cpu_ll.h:183
 (inlined by) esp_pm_impl_waiti at C:/esp4/esp-idf/components/esp_pm/pm_impl.c:827

0x400d845b: esp_vApplicationIdleHook at C:/esp4/esp-idf/components/esp_common/src/freertos_hooks.c:63

0x40088505: prvIdleTask at C:/esp4/esp-idf/components/freertos/tasks.c:3839 (discriminator 1)

0x4008a525: vPortTaskWrapper at C:/esp4/esp-idf/components/freertos/port/xtensa/port.c:168



ELF file SHA256: d843f1542d225f73`

Other items if possible

  • sdkconfig file (attach the sdkconfig file from your project folder)
  • elf file in the build folder (note this may contain all the code details and symbols of your project.)
  • coredump (This provides stacks of tasks.)
@github-actions github-actions bot changed the title PPPOS reconnection/disconnection faliuer after sometime. PPPOS reconnection/disconnection faliuer after sometime. (IDFGH-6123) Oct 31, 2021
@espressif-bot espressif-bot added the Status: Opened Issue is new label Oct 31, 2021
@david-cermak
Copy link
Collaborator

@AdiXPS could you tell us which modem are you using? Also, are you seeing the first crash with just the code you've shared or was there anything else running on ESP32 at the same time?

As for the first issue, null dereference in the internal UART structures, I couldn't think of anything else but memory corruption. Is this happening randomly or could it be somehow related to the second issue? (like one occurs after another?)

As for the second problem, it might be possible that +++ command won't exit the data mode, this is typically defined in the specification of the device used (and for our supported devices, the procedure is to repeat the sequence after one second)

@AdiXPS
Copy link
Author

AdiXPS commented Nov 1, 2021

Hi @david-cermak,
Sure, I am using sim7070g, mostly like sim800. There is no other task is running other than connect and disconnect.

As for the first issue, null dereference in the internal UART structures, I couldn't think of anything else but memory corruption. Is this happening randomly or could it be somehow related to the second issue? (like one occurs after another?)

Its randomly. I notice that its crashing on Core 1? not sure why though.. moreover, based on my observation, its not related as its rare..

As for the second problem, it might be possible that +++ command won't exit the data mode, this is typically defined in the specification of the device used (and for our supported devices, the procedure is to repeat the sequence after one second)

Its the same as sim800. i've added 1s delay before initiating ath command (based on last change you've proposed in another issue). But that didn't prevent the issue from happening again.. I notice one thing that modem in exiting PPP is still sometimes sending data by UART to esp even when confirming for +++..

"10/30/2021 11:33:35 PM",CONNECT 150000000

"10/30/2021 11:33:35 PM",~ÿ}#À!}!í} }9}"}&} } } } }#}%Â#}%}%}&Ø}+‘¹}'}"}(}" ˆÿ}#À!}"}!} }4}"}&} } } } }%}&tUl+}'}"}(}"7õÿ}#À!}!î} }8}"}&} } } } }#}$À#}%}&Ø}+‘¹}'}"}(}"À}:ÿ}#À!}+ï} }(Ø}+‘¹qBÀ#�� � ý0€!�n �1Ö€!��

"10/30/2021 11:33:36 PM",�� -��ø0€!�o �팀!�� ���

"10/30/2021 11:33:36 PM",D’T��Të�7ƒ�Të9æn�~~€!�� ���

"10/30/2021 11:33:36 PM",D’T��Të�7ƒ�Të9æ_„~

"10/30/2021 11:33:40 PM",OK <=============this is when esp sends +++, module sends OK but esp keeps getting data afterwards..

"10/30/2021 11:33:43 PM",~!E s³ì@ é�+ä6ÌÞO <==== this is the famous ~!E when code crash..

"10/30/2021 11:33:43 PM",D’T�»äê�E 3-��_€� @?ë ���

"10/30/2021 11:33:43 PM",@`Åñ�!ÿç��� "ûÞzêFçÈ�°rúß“Ü={k¹Å!Ð�á¤ê�z©]Z¼ëŠí��� �¡#<©�€¯•Y‹›Fèõ8ü%©B‚~~!E s�•@ ê�Ã;6ÌÞO

"10/30/2021 11:33:43 PM",D’T�»å�@t „àA�J€� 9põ ���

"10/30/2021 11:33:43 PM",�™�Æ{( £��� "�.Kþ�Z��0^#}]ãÝtPV#HÌ�MÁÜe‡�5šT8�½ê��� �ØwG«+Ùéß Í6H×@-Ü�DÛóQ~

Its happening randomly

@david-cermak
Copy link
Collaborator

@AdiXPS

I notice one thing that modem in exiting PPP is still sometimes sending data by UART to esp even when confirming for +++..

This is weird, I've never seen anything like that with any device. Is the OK response surrounded by <CR><LF>? Could you please share binary hexdump?
Are you sure, you don't use any kind of virtual terminal feature/CMUX mode? Or isn't it that your device is somehow configured to multiplex terminals?

Anyway, I'll look into it and try to reproduce the issue, at least the first one. For the second one, we'd probably have to purchase your device sim7070g

@AdiXPS
Copy link
Author

AdiXPS commented Nov 3, 2021

This is weird, I've never seen anything like that with any device.

Yup, I totally agree with you.

Is the OK response surrounded by <CR><LF>?

Yes it is.

Could you please share binary hexdump?

I appreciate to get your advice regarding proper way to get the hexdump.

Are you sure, you don't use any kind of virtual terminal feature/CMUX mode? Or isn't it that your device is somehow configured to multiplex terminals?

I've double check, mux is not enabled.

Anyway, I'll look into it and try to reproduce the issue, at least the first one. For the second one, we'd probably have to purchase your device sim7070g

Thanks.. from what I can see that there are other issues raised here facing same issue, but no one actually tried to check the data coming from modem. I always notice ~!E in others facing the issue.. might it be a buffer issue, as data is coming even after exiting +++?

@david-cermak
Copy link
Collaborator

@AdiXPS

I appreciate to get your advice regarding proper way to get the hexdump.

You can use ESP_LOG_BUFFER_HEXDUMP() macro from IDF's log component, it's used for example here:

ESP_LOG_BUFFER_HEXDUMP("esp-modem: pattern-detection", esp_dte->buffer, length, ESP_LOG_VERBOSE);

IDF version 4.3

Are you sure this was the correct version?

        config.dte_buffer_size = CONFIG_EXAMPLE_MODEM_UART_RX_BUFFER_SIZE / 2;

This line from your code suggests it might have been v4.4? (dte_buffer_size was added in 4.4)

I've been testing the while loop on release/v4.3 on SIM7600 and no issues, so far. I'd guess that the condition of incorrect exit of PPP mode might have caused some memory corruption. I'll focus on this and try to simulate this condition somehow.

@Alvin1Zhang
Copy link
Collaborator

@AdiXPS Thanks for reporting, would you please help share if any updates for the issue? Thanks.

@AdiXPS
Copy link
Author

AdiXPS commented Nov 22, 2021

@AdiXPS Thanks for reporting, would you please help share if any updates for the issue? Thanks.

Still there is no update, same issue is occurring. Actually just today I got new sim7070g, I'll de-solder the one I'm using and replace it with new one just in case. I'll rerun it again with hexdump and I'll post the update within two days God willing.

@espressif-bot espressif-bot added the Awaiting Response awaiting a response from the author label Nov 25, 2021
@AdiXPS
Copy link
Author

AdiXPS commented Nov 29, 2021

@david-cermak @Alvin1Zhang I am still facing the same issue with different SIM7070G module. Different PCB also. @david-cermak Regarding hexdump may I know where exactly I need to place it, to help more in the investigation e.g. at the end of esp_handle_uart_data() function?

@AdiXPS
Copy link
Author

AdiXPS commented Dec 8, 2021

@david-cermak , @Alvin1Zhang We'll, seems that the issue is the module 7070G/7080 have backdoor after full analysis. The modem keeps sending data even after exiting data mode, I have also requested to get the latest firmware from simcom (just to eliminate any M-in-M kind of issues) but its even worse now. Its getting certificates and all kind of alarming stuff:

it tries to get fake cert. for *.piojm.tech and this brings me to conclude that all ~!E famous text received is when simcom tries to establish malicious connections..

"11/29/2021 10:49:10 PM",]�߱-¹IW:�~
"11/29/2021 10:49:11 PM",OK

"11/29/2021 10:49:15 PM",OK <===ATH confirmation
"11/29/2021 10:49:15 PM",~!E �xߴ@ 3�ڴ¤Zi�
"11/29/2021 10:49:15 PM",�o��»ʕ�س¼�؈א� ��< ��� J� F��/· �ʔi�󘩢�=춒ͽ]�½핉 "11/29/2021 10:49:15 PM",�Ę À0 � ÿ� � � �� �� # � � ��h2����]� �Y �V �û0��÷0��ߠ�������:B­G8Ӆ�Àw¯ ª¹R0 "11/29/2021 10:49:15 PM",� *�H�÷ "11/29/2021 10:49:15 PM",���� 0Y1�0 ��U����US1�0���U� "11/29/2021 10:49:15 PM",� DigiCert Inc1301��U���*RapidSSL TLS DV RSA Mixed SHA256 2020 CA-10�� "11/29/2021 10:49:15 PM",200810000000Z� "11/29/2021 10:49:15 PM",220811120000Z0�1�0���U�� *.piojm.tech0��"0 "11/29/2021 10:49:15 PM",� *�H�÷ "11/29/2021 10:49:15 PM",���� ���� 0�� "11/29/2021 10:49:15 PM",���� �­²qf6põ|5RB1�<½;ވ¯䌌´¯r!ÀN$V�b✇U��ڏ>ù^´�­�׫¤Zűü¯gͮ褔 ۟ݞø�x&»�񍒥}^p���¸褼½ފ"11/29/2021 10:49:16 PM",+�|8#5Ʌώ�ˮ�Kհ� "11/29/2021 10:49:16 PM",^�2¡»𽖀õ�¤�ûy¯W7kѨ¨ᔢ°e1u?H֌1.§(�ٴ��ک[¨�2s�J䆤k�5pü�U�㣃���┸_5*2«גѷ?�r¦(PA$�¿�٦¸ꌉ�O¹ùuO$�ΌV��$u�pŬP3讖¤ �»?b_�±¬9HĖ���� �£��û0��÷0���U�#��0���¤�徼y䰣m.)4­#Xܵ1�0���U������˶He��]𒯆ým��X噘0#��U����0�� *.piojm.tech�
"11/29/2021 10:49:16 PM",piojm.tech0���U����ÿ����� 0���U�%��0���+���������+�������0L��U� �E0C07� �H��ýl��0*0(��+���������https://www.digicert.com/CPS0���g� ���0����+��������y0w0$��+�����0���http://ocsp.digicert.com0O��+�����0��Chttp://cacerts.digicert.com/RapidSSLTLSDVRSAMixedSHA2562020CA-1.crt0 ��U����0 0��}^� "11/29/2021 10:49:16 PM",+����ֹ������n���j�h u )y¾𞹹!𖳟c¥w得}]�
"11/29/2021 10:49:16 PM",øùM]&%]DŽ �s׭üߠ �� F0D� (L��8ö@²�¹j߅�K�®¡�A[V�þµڢ Ժ�¯� Q7´®�QIY¹�xµ髼E󌱓˦��3趥l´�䠷 "EE�YU$V�?¡/񷭆ࣦc­ÀK�]ƃ\n⏂ �s׭ý� �� H0F�! Р¤;͠YþĞY�M¹;'��A®緌z�ȣ�jcOy�! �Rf䒄¹´�<ù�Àõ ͟&Bxӿ��띠¯N^�Ơv Q£°õý�y�Vm¸7x� ¤z̛'˷��B�
"11/29/2021 10:49:16 PM",þԋ�堠�s׭ý[ �� G0E� ={é慦%:䟙9��A�-�f/ПU¦4��! �¢n³l���t3꘠�e��EZ)z�»ù¶TIڈd0
"11/29/2021 10:49:17 PM",� *�H�÷
"11/29/2021 10:49:17 PM",�þ5~~!E 4=+ 7��¡�û%�"11/29/2021 10:49:17 PM",�o��»˝µ󋚱ƕ����
"11/29/2021 10:49:17 PM",º7 ���
"11/29/2021 10:49:17 PM",E½z'-¹IW@

I am not interested in this aspect (backdoor or not), how can we ignore such coming data?

@david-cermak
Copy link
Collaborator

Hi @AdiXPS

The famous ~!.. is just an ascii representation of start of frame of PPP and an IP protocol id. This is what you've already pointed out above, that the device didn't exit the PPP session, but is still talking in PPP back. Couldn't be the backdoor data just public certs of some connection, e.g. forcefully retried after the hangup?
I couldn't reproduce the issue with the devices supported in IDF, which makes me think it has to be device specific, something to do with 7070G/7080 modems.

how can we ignore such coming data?

I think you can try to reset the device, either using a reset command or pulling the reset line directly. Or you can try to use CMUX mode, but it depends on your usecase. What's the reason for switching to command mode? Do you need to use AT interface or close the network connection?

@AdiXPS
Copy link
Author

AdiXPS commented Dec 12, 2021

Hi @david-cermak

Couldn't be the backdoor data just public certs of some connection, e.g. forcefully retried after the hangup?

@AdiXPS AdiXPS closed this as completed Dec 12, 2021
@AdiXPS AdiXPS reopened this Dec 12, 2021
@AdiXPS
Copy link
Author

AdiXPS commented Dec 12, 2021

Hi @david-cermak

Couldn't be the backdoor data just public certs of some connection, e.g. forcefully retried after the hangup?

I highly doubt this, as we got confirmation from the module 'OK' (mentioned earlier in the logs) for exiting data and hangup, but the module keeps sending and receiving data. As long as we got ATH => OK this should kill any connection, regardless if its public cert or not. Moreover, even if its public cert, its no where mentioned all of their documentation regarding this behavior/activity. btw the domain cert that we've found in the module is considered as one of the blacklisted DNSs. I am reporting the findings here for anyone will use this module.

What's the reason for switching to command mode? Do you need to use AT interface or close the network connection?

I need to close the connection and get the lon,lat by AT command. and do battery readings.. but as long as we keep getting such data uart will be unuasable

@david-cermak
Copy link
Collaborator

I need to close the connection and get the lon,lat by AT command.

You can use CMUX mode for that and keep the network/PPP still on.

@david-cermak
Copy link
Collaborator

Hi @AdiXPS

Is there any update from your side? This issue seems to be related to specifically your devices of 7070G/7080 family, that are not supported in IDF examples. Could you please close the issue, then? (note, that it's also okay to raise a feature request to support your devices, if you're thinking of that, please do so in the esp-protocols repo)

@Alvin1Zhang
Copy link
Collaborator

Thanks for reporting, will close due to short of feedback, feel free to reopen with more updates. Thanks.

@espressif-bot espressif-bot added Resolution: Done Issue is done internally Status: Done Issue is done internally and removed Status: Opened Issue is new labels Jun 29, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Awaiting Response awaiting a response from the author Resolution: Done Issue is done internally Status: Done Issue is done internally
Projects
None yet
Development

No branches or pull requests

4 participants