mDNS stops working after two minutes

[leifclaesson]

This issue has been previously posted by others but was erroneously closed as "stale" without resolution. It is still a problem.

Hardware:

Board: LOLIN32, MH-ET-LIVE, DOIT devkit v1 and others. Happens with all ESP32 hardware I've tested.
Core Installation version: 1.0.4
IDE name: Arduino IDE
Flash Frequency: 80Mhz
PSRAM enabled: no

Description:

I'm trying to use MDNS. Using the mDNS_Web_Server example, when the device starts, I am able to access the page at 'esp32.local/'. However, after two minutes, this stops working.

Manually resolving the mDNS address shows the same behavior - it works for the first two minutes after the device is started, then simply stops working.

I did a Wireshark capture on the IP address of the ESP32. It broadcasts the mDNS messages, with a TTL of 2 minutes. It only ever broadcasts those messages at startup (I left the device for ~20m).

If I manually call MDNS.begin periodically, it works, but the correct function for this is update() which is missing from the ESP32 version.

I was able to reproduce this on multiple dev boards, and several others have reported the same issue.

Sketch:

mDNS_Web_Server example (only modified to set the ssid/password)

Debug Messages:

None

[felmue]

HI @leifclaesson

I am running the mDNS_Web_Server example on a ESP32_LyraT board and I can ping 'local.ESP32' after start and also after waiting for more than 2 minutes just fine. I wonder if it has something to do with the OS from which the ping is originated from. I am using MacOSX. What is the OS you are testing with?

BTW: I only very quickly looked into how mDNS is supposed to work, so I could be wrong about it. So far it is my understanding that the server only is supposed to send out it's mDNS information when a client asks for it, so I would not expect it to broadcast its information periodically on it's own (except for when it is started), but only upon request. That is why I think it might be related to the mDNS implementation of the OS used to ping the ESP32 board.

Thanks
Felix

[EricDuminil]

Hello.

For what it's worth, I can reproduce this behaviour with espressif8266.
Same sketch (mDNS_Web_Server example, only modified to set the ssid/password).
Compiling with Arduino IDE or pio doesn't seem to make any difference.
Here are my pio libs:

❯ pio update
Updating platformio/contrib-piohome           3.3.1 @ ~3.3.1                     [Up-to-date]
Updating platformio/tool-unity                1.20500.200612 @ ~1.20500.0        [Up-to-date]
Updating platformio/tool-scons                4.40001.0 @ ~4.40001.0             [Up-to-date]

Platform Manager
================
Platform atmelavr
--------
Updating platformio/atmelavr                  3.0.0                              [Up-to-date]
Updating platformio/toolchain-atmelavr        1.50400.190710 @ ~1.50400.0        [Up-to-date]
Updating platformio/framework-arduino-avr     5.1.0 @ ~5.1.0                     [Up-to-date]

Platform espressif8266
--------
Updating platformio/espressif8266             2.6.2                              [Up-to-date]
Updating platformio/toolchain-xtensa          2.40802.200502 @ ~2.40802.191122   [Up-to-date]
Updating platformio/framework-arduinoespressif8266 3.20704.0 @ ~3.20704.0             [Up-to-date]
Updating platformio/tool-esptool              1.413.0 @ <2                       [Up-to-date]
Updating platformio/tool-esptoolpy            1.20800.0 @ ~1.20800.0             [Up-to-date]
Updating platformio/tool-mkspiffs             1.200.0 @ ~1.200.0                 [Up-to-date]
Updating platformio/tool-mklittlefs           1.203.200522 @ ~1.203.0            [Up-to-date]

I can ping esp8266.local at first (both from Linux Mint 19.3 and OS X El Capitan), but after 2 minutes, it returns ping: esp8266.local: Name or service not known.

I wrote a small bash loop to time it. I start the loop, wait 10 seconds, start the board and let loop and board run:

❯ while sleep 10; do; date; ping -c1 -w3 -O -q esp8266.local | grep received; done
Sat Dec  5 12:43:45 CET 2020
ping: esp8266.local: Name or service not known
Sat Dec  5 12:44:00 CET 2020
1 packets transmitted, 1 received, 0% packet loss, time 0ms
Sat Dec  5 12:44:13 CET 2020
1 packets transmitted, 1 received, 0% packet loss, time 0ms
Sat Dec  5 12:44:23 CET 2020
1 packets transmitted, 1 received, 0% packet loss, time 0ms
Sat Dec  5 12:44:33 CET 2020
1 packets transmitted, 1 received, 0% packet loss, time 0ms
Sat Dec  5 12:44:43 CET 2020
1 packets transmitted, 1 received, 0% packet loss, time 0ms
Sat Dec  5 12:44:53 CET 2020
1 packets transmitted, 1 received, 0% packet loss, time 0ms
Sat Dec  5 12:45:03 CET 2020
1 packets transmitted, 1 received, 0% packet loss, time 0ms
Sat Dec  5 12:45:13 CET 2020
1 packets transmitted, 1 received, 0% packet loss, time 0ms
Sat Dec  5 12:45:23 CET 2020
1 packets transmitted, 1 received, 0% packet loss, time 0ms
Sat Dec  5 12:45:33 CET 2020
1 packets transmitted, 1 received, 0% packet loss, time 0ms
Sat Dec  5 12:45:43 CET 2020
1 packets transmitted, 1 received, 0% packet loss, time 0ms
Sat Dec  5 12:45:53 CET 2020
1 packets transmitted, 1 received, 0% packet loss, time 0ms
Sat Dec  5 12:46:03 CET 2020
1 packets transmitted, 1 received, 0% packet loss, time 0ms
Sat Dec  5 12:46:13 CET 2020
ping: esp8266.local: Name or service not known
Sat Dec  5 12:46:28 CET 2020
ping: esp8266.local: Name or service not known
Sat Dec  5 12:46:44 CET 2020
ping: esp8266.local: Name or service not known
Sat Dec  5 12:46:59 CET 2020
ping: esp8266.local: Name or service not known
Sat Dec  5 12:47:14 CET 2020

What's weird is that it might randomly start again after a while (2 or 3 minutes), without rebooting the board:

Sat Dec  5 12:47:59 CET 2020
ping: esp8266.local: Name or service not known
Sat Dec  5 12:48:14 CET 2020
ping: esp8266.local: Name or service not known
Sat Dec  5 12:48:29 CET 2020
ping: esp8266.local: Name or service not known
Sat Dec  5 12:48:44 CET 2020
1 packets transmitted, 1 received, 0% packet loss, time 0ms
Sat Dec  5 12:48:54 CET 2020
1 packets transmitted, 1 received, 0% packet loss, time 0ms
Sat Dec  5 12:49:04 CET 2020
1 packets transmitted, 1 received, 0% packet loss, time 0ms
Sat Dec  5 12:49:14 CET 2020
1 packets transmitted, 1 received, 0% packet loss, time 0ms
Sat Dec  5 12:49:24 CET 2020

It will stop again after exactly 2 minutes, though.

I realize my board isn't an esp32, but it seems to have the same problem as yours, though, so it might help spotting where the actual problem comes from.

[stale]

[STALE_SET] This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.

[mjcross]

Just doing some testing on this; will report back

[stale]

[STALE_CLR] This issue has been removed from the stale queue. Please ensure activity to keep it openin the future.

[mjcross]

OK I've made some checks with tcpdump.

I can confirm that with the mDNS server in the Espressif native framework (ESP-IDF v4.2), the same pattern of packets is sent.
At startup, after obtaining an IP address the ESP32 first broadcasts an mDNS query for the hostname it is about to use (with a TTL of 2 minutes). It does this three times.

If no other machine responds (which would indicate this hostname is already assigned to another machine), the ESP32 then broadcasts an mDNS response to its own query, advertising its IP address (with a TTL of 2 mins). It does this three times.

After this initial announcement I did not see the ESP32 send any further mDNS packets during the 30min period of my test - although it did continue to send periodic ARP broadcasts (which are not related to mDNS).

However unlike the OP, I do not lose the ability to resolve the hostname after the 2 minute period... indeed all the machines on my LAN were still able to resolve and ping the host four hours later.

Looking into this a little more closely, I can see that it is in fact my residential gateway (FritzBox 7530) that has cached the mDNS result for the ESP32, and is serving it to other local clients via the 'normal' DNS service on port 53.

[me-no-dev]

I can agree with @mjcross here. If resolution stops after 2 minutes, that means that the client did not re-query to refresh the record and so made it invalid. Generally it should have asked for the host about 1 minute in (half the TTL).

The MDNS lib in IDF is fully compliant and much tested.

[mjcross]

If your application has long gaps between a client accessing the ESP32 via its mDNS hostname, then you might try getting the ESP32 to do an mDNS lookup of its own hostname using the resolve_mdns_host() API call every couple of minutes. This should keep the record 'fresh' in the cache of other machines on the LAN.

If that doesn't work then you might try periodically restarting the mDNS service on the ESP32 every couple of minutes using mdns_free() and mdns_init(), which should cause a re-broadcast of the initial mDNS registration.

[leifclaesson]

try getting the ESP32 to do an mDNS lookup of its own hostname using the [resolve_mdns_host()](https://docs.espressif.com/projects/esp-
idf/en/latest/esp32/api-reference/protocols/mdns.html#mdns-query) API call every couple of minutes. This should keep the record 'fresh' in the cache of other machines on the LAN.

This is an interesting idea! I will try this. Thank you!

If that doesn't work then you might try periodically restarting the mDNS service on the ESP32 every couple of minutes using mdns_free() and mdns_init(), which should cause a re-broadcast of the initial mDNS registration.

That was actually the first thing I tried -- this causes the ESP to crash and reboot after ~25 hours. Took me quite a while to find why my many ESP32s had trouble staying up, because you don't immediately notice the problem after adding the periodic reinit.. so, that one is not a good solution.

[MythicalForce]

i have the exact same problem... googling my ass off trying to find a fix for this!

[khanhvu161188]

If your application has long gaps between a client accessing the ESP32 via its mDNS hostname, then you might try getting the ESP32 to do an mDNS lookup of its own hostname using the resolve_mdns_host() API call every couple of minutes. This should keep the record 'fresh' in the cache of other machines on the LAN.

I have tried but this approach does not work.