esp_eth_disable() crash

[thethinker]

HI guys,
So I have came across an issue with lan8720 and pico-d4. I noticed there is no IP lost timer for ETH interface, so If my link is up and I lost IP I won't know about it (ex: if router gets disconnected from a switch that esp is connected to).
My attempt to fix the issue:
--Ping the gateway address and if I get too many timeouts then disable and re-enable the eth interface that way I know when I get my IP back again.

However the issue is that calling either esp_eth_disable() or esp_eth_deinit() results in a weird situation which looks like a halt.
After the call I get:
D (28658) emac: emac stop
D (28659) emac: eth link_down
after these two lines, everything stops and the watchdog doesn't even reset the esp.

Can someone please test and confirm this? I haven't been able to pinpoint the issue yet.

Thanks!

[thethinker]

Okay, so turns out the issue was an open UDP socket which is used by "esp_log_set_vprintf()" function (I'm sending logs to a server using udp socket).

I believe this is a bug?

stopping dhcp client for that socket does the same crash.

I solved it by closing the socket first but this should be handled properly in the API.

[thethinker]

Okay,
I believe here is the bug that no one really ever fixed:
https://github.com/espressif/esp-idf/issues/1246

[thethinker]

Hmm,
Really ? None of the ESP guys are willing to help?

[ESP_morris]

Hmm,
Really ? None of the ESP guys are willing to help?

Sorry for the delay.

So finally this an issue about the tcp/ip stack. right?

The Github issue you mentioned has been reopend. Some one will soon reply on it.

And could you please give us more detailed information about your issue?

The original Github issue is due to the misuse of socket API, which is calling socket API(e.g. sendto) in the TCP/IP task. What the result caused by this is a deadlock. So whatchdog won't be triggered too. The socket APIs are not allowed to be called in TCPIP task.