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

esp_https_ota_begin fails with PPP (IDFGH-14321) #15113

Open
3 tasks done
ezamp opened this issue Dec 30, 2024 · 2 comments
Open
3 tasks done

esp_https_ota_begin fails with PPP (IDFGH-14321) #15113

ezamp opened this issue Dec 30, 2024 · 2 comments
Labels
Status: Opened Issue is new Type: Bug bugs in IDF

Comments

@ezamp
Copy link

ezamp commented Dec 30, 2024

Answers checklist.

  • I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
  • I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
  • I have searched the issue tracker for a similar issue and not found a similar issue.

IDF version.

v5.3.2

Espressif SoC revision.

ESP32-S3

Operating System used.

macOS

How did you build your project?

VS Code IDE

If you are using Windows, please specify command line type.

None

Development Kit.

AtomS3 Lite

Power Supply used.

USB

What is the expected behavior?

After calling the "esp_https_ota_begin" function, I expect the OTA update process to start using the PPP interface.
The PPP connection is opened correctly and the MQTT client is able to connect correctly to the broker.
If, on the other hand, I activate the WiFi connection then the OTA update is completed correctly.

I also tried defining the PPP interface as default but nothing changed:

case IP_EVENT_PPP_GOT_IP:
{
    ESP_LOGI(TAG, "Modem Connect to PPP Server");

    //Set NB as default interface
    ip_event_got_ip_t *event = (ip_event_got_ip_t *)event_data;
    esp_netif_t *netif = event->esp_netif;
    esp_netif_set_default_netif(netif);

    //Set DNS (0: Cloudflare, 1: Google)
    ip_addr_t dnsserver;
    IP_ADDR4(&dnsserver, 1, 1, 1, 1);
    dns_setserver(0, &dnsserver);
    IP_ADDR4(&dnsserver, 8, 8, 8, 8);
    dns_setserver(1, &dnsserver);

    [...]

    break;
}

PS: I perform MQTT client disconnection before running the OTA.

What is the actual behavior?

Update fails due to an error in DNS resolution.

Steps to reproduce.

  1. Open PPP connection
  2. Start the OTA update

Debug Logs.

I (288315) OtaManager: OTA started
E (296095) esp-tls: couldn't get hostname for :<REMOVED>.s3.eu-west-1.amazonaws.com: getaddrinfo() returns 202, addrinfo=0x0
E (296095) esp-tls: Failed to open new connection
E (296095) transport_base: Failed to open a new connection
E (296105) HTTP_CLIENT: Connection failed, sock < 0
E (296115) esp_https_ota: ESP HTTP client perform failed: 28674
E (296115) OtaManager: ESP HTTPS OTA Begin failed
I (296125) OtaManager: OTA abort

More Information.

With WiFi interface is working

@ezamp ezamp added the Type: Bug bugs in IDF label Dec 30, 2024
@github-actions github-actions bot changed the title esp_https_ota_begin fails with PPP esp_https_ota_begin fails with PPP (IDFGH-14321) Dec 30, 2024
@espressif-bot espressif-bot added the Status: Opened Issue is new label Dec 30, 2024
@ezamp
Copy link
Author

ezamp commented Jan 5, 2025

I tried defining the interface for the HTTP request (if_name) but I get the same error.

   ifreq ifr = {
        .ifr_name = "pp1",
    };

    esp_http_client_config_t config = {
        .url = OTAMANAGER_FIRMWARE_URL,
        .cert_pem = server_cert_pem_start,
        .timeout_ms = OTAMANGER_RECV_TIMEOUT,
        .keep_alive_enable = true,
        .if_name = &ifr,
    };

@david-cermak
Copy link
Collaborator

Is it possible that you're using WiFi interface and PPP interface at the same time (and specifically receive a DHCP lease after getting the PPP IP)?

Please note that lwip sets DNS servers globally, so it may be possible that the DNS servers received by one interface override previous settings of another interface.
This is documented in the limitation section of lwip docs: https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-guides/lwip.html#limitations
There're multiple ways to address the issue (e.g. set cloudflare/google DNS servers manually, but only after all DNS settings are retrieved), but the easiest option is to enable CONFIG_ESP_NETIF_SET_DNS_PER_DEFAULT_NETIF, see:
https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-reference/network/esp_netif_programming.html?highlight=config_esp_netif_set_dns_per_default_netif#_CPPv422esp_netif_set_dns_infoP11esp_netif_t20esp_netif_dns_type_tP20esp_netif_dns_info_t

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Status: Opened Issue is new Type: Bug bugs in IDF
Projects
None yet
Development

No branches or pull requests

3 participants