IP_EVENT_PPP_LOST_IP only received after lost ip timer fires when initiating disconnect, is this expected? (IDFGH-11378)

[western-hoolock]

Answers checklist.

• I have read the documentation for esp-protocols components and the issue is not addressed there.
• I have updated my esp-protocols 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.

General issue report

From looking at the (ESP-IDF) code and my own experiments it seems that the IP_EVENT_PPP_LOST_IP event is only posted immediately when the PPP connection disconnects unexpectedly but much later (~minute) when the shutdown is deliberately initiated by calling esp_netif_action_stop.

I can see in the logs that esp_netif_action_stop properly shuts the PPP link down, it just doesn't post IP_EVENT_PPP_LOST_IP, this is only done by the netif lost ip timer, about a minute later.

Is this the desired behavior? I expected the PPP code to post an IP_EVENT_PPP_LOST_IP event in both cases and not rely on the netif lost ip timer to post that event a while later when the PPP code knows perfectly well when the link is down.

NETIF_PPP_ERRORUSER event is properly fired but it's odd to then also get an IP_EVENT_PPP_LOST_IP so much later.

[david-cermak]

Yes, this is expected and how the network layers behave in IDF. These "lost-IP" events (not only PPP, but all others) are triggered from a timer and do not reflect the actual (link) state of the network interface. The reason is probably historical and based on the way the TCP protocol works, because the connection is up and running and you can send data to sockets even if you're physically disconnected.
The solution to this problem would be an event on link-up, link-down state change.

[western-hoolock]

The solution to this problem would be an event on link-up, link-down state change.

Yeah I was kind of treating those events like that, would be convenient so the link state can be directly reflected through an LED/on the screen. I guess the best way to go about this is to have component/esp_modem specific events that get posted to inform the app about link state changes? Or is this something that could easily be done for any interface through lwIP?

[david-cermak]

I guess the best way to go about this is to have component/esp_modem specific events that get posted to inform the app about link state changes?

Yes, currently it's user code that needs to treat interfaces separately to react on link based events,; In case of esp_modem, we can use NETIF_PPP_* events (similarly, for Ethernet we have ETHERNET_EVENT_DISCONNECTED event).

Or is this something that could easily be done for any interface through lwIP?

Yes, lwIP provides a link status callback. There's been a plan to support this in esp_netif to fire an appropriate event on link state change (the task doesn't have a very high prio, though)

[western-hoolock]

Ok thanks. So I have a PPPoS client running with esp_modem and it's battery powered, I need to go back to sleep as soon as possible. Calling esp_modem_destroy(dce) followed by esp_netif_destroy(esp_netif) is enough to attempt to shut down the PPP link cleanly, I can enter sleep after those functions returned? No need to wait for the IP_EVENT_PPP_LOST_IP event since it's fired in response to the xxx_destroy functions invalidating the IP anyway?

[david-cermak]

Calling esp_modem_destroy(dce) followed by esp_netif_destroy(esp_netif) is enough

Yes, this should be enough for the clean closure

No need to wait for the IP_EVENT_PPP_LOST_IP event

Do you still get this event, even after those two calls? This sounds a bit odd to me, since calling

• esp_modem_destroy(dce) would close the PPP session, but there's a timeout; so it's still possible to receive a lost-ip event
• esp_netif_destroy(esp_netif) would remove the network interface, so no other activity is expected. The lost-ip timer might be still active to invoke a callback, but this should end right here:

https://github.com/espressif/esp-idf/blob/c8243465e45489835d645bf217a6929fd0c01b7f/components/esp_netif/lwip/esp_netif_lwip.c#L1330-L1333

so you would see this line in the debug log:

D (32405) esp_netif_lwip: esp_netif_ip_lost_timer esp_netif=0x3ffb92a8 not active any more

but no event should be fired anymore

[western-hoolock]

You're right, it doesn't actually fire the IP_EVENT_PPP_LOST_IP event after esp_netif_destroy I was waiting for the IP_EVENT_PPP_LOST_IP event after the esp_modem_destroy call since I wasn't sure calling esp_netif_destroy would invalidate the interface too early but as you pointed out the callback checks if it's valid so no need to worry about that.

Thanks for clarifying!