Mdns not working in bridge example (IDFGH-14440)

[ash-abeer]

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

ESP-IDF Version: v5.3.1
Project: Bridge Example
I am trying to run mDNS in a bridge configuration, but it appears to be non-functional.
Initially, I used the default configurations:

CONFIG_MDNS_PREDEF_NETIF_STA=y
CONFIG_MDNS_PREDEF_NETIF_AP=y
CONFIG_MDNS_PREDEF_NETIF_ETH=y

However, it did not work as expected.
Next, I registered the bridge network interface using mdns_register_netif and called the mdns_netif_action function, but the output remained the same. I also increased the maximum number of interfaces:

MDNS_MAX_INTERFACES=5

After that, I disabled the predefined network interfaces and tried again by registering only the bridge network interface:

# CONFIG_MDNS_PREDEF_NETIF_STA is not set
# CONFIG_MDNS_PREDEF_NETIF_AP is not set
# CONFIG_MDNS_PREDEF_NETIF_ETH is not set

Despite these changes, mDNS still does not seem to work.

Question:

Is mDNS support for the bridge configuration not implemented, or am I missing something?

Code

esp_err_t err = mdns_init();
if (err != ESP_OK)
{
    ESP_LOGE(TAG, "Failed to initialize mDNS: %s", esp_err_to_name(err));
    return;
}

err = mdns_hostname_set("mywebbie");
if (err != ESP_OK)
{
    ESP_LOGE(TAG, "Failed to set hostname: %s", esp_err_to_name(err));
    mdns_free();
    return;
}

ESP_LOGI(TAG, "mDNS hostname set to: %s", "mywebbie");

const char *instance_name = "Webbie Device";
err = mdns_instance_name_set(instance_name);
if (err != ESP_OK)
{
    ESP_LOGE(TAG, "Failed to set instance name: %s", esp_err_to_name(err));
}
else
{
    ESP_LOGI(TAG, "mDNS instance name set to: %s", instance_name);
}
ESP_ERROR_CHECK(mdns_register_netif(br_netif));
ESP_ERROR_CHECK(mdns_netif_action(br_netif, MDNS_EVENT_ENABLE_IP4 /*| MDNS_EVENT_ENABLE_IP6 */ | MDNS_EVENT_IP4_REVERSE_LOOKUP | MDNS_EVENT_IP6_REVERSE_LOOKUP));

[david-cermak]

This should work independently on both interfaces, but won't necessarily forward multicasts (mdns datagrams) across interfaces.

mDNS still does not seem to work.

You mean that it doesn't work on a single netif or across netifs?

[ash-abeer]

@david-cermak It works when the dhcp servers are separate for both interface (not a bridge configuration). But when only 1 dhcp server is used for both the interfaces means both interface netifs are glued together to make a single one (Bridge configuration). Mdns does not work on that.

[david-cermak]

In general, you just need to add an address to the forwarding database, but this should be handled automatically for multicasts.
quickly tested with a simple A query and it worked with avahi-resolver. Didn't work with one-shot queries (using common DNS lookup on the multicast address) -- need to investigate further.
how do you use the mdns library? using full featured mdns (avahi or dns-sd) or the simplified mdns (e.g. dig)?

[ash-abeer]

@david-cermak I haven't used avahi or dns-sd yet. Just simply browsing with this url mydomain.local doesn't work on the browser. I have tried with Safari, Brave and Chrome.

[david-cermak]

Could you please confirm that you're seeing something like this:

No.     Time           Source                Destination           Protocol Length Info
      1 0.000000000    192.168.4.2           224.0.0.251           MDNS     97     Standard query 0x6788 A hostname.local, "QM" question 
      2 0.196719080    192.168.4.1           192.168.4.2           MDNS     90     Standard query response 0x6788 A hostname.local, "QM" question A 192.168.4.1
      3 0.196823997    192.168.4.2           192.168.4.1           ICMP     118    Destination unreachable (Port unreachable)

so that the ESP actually responds, but there's this destination unreachable packet?

doesn't work on the browser.

depends on your platform, I think it should typically work on mac, but might not on windows.

anyway, if this is the case, i'll have to fix it, mdns should work with one-shot queries, too.

[ash-abeer]

@david-cermak I'm seeing this when it's not working. By the way i have figured out the issue. The mdns_netif_action needs to be called when esp32 has assigned the ip to client. Now the domain is getting resolved in the browser.

1579	18.161903	192.168.0.2	224.0.0.251	MDNS	74	Standard query 0x0000 A mywebbie.local, "QM" question
1580	18.162071	192.168.0.2	224.0.0.251	MDNS	74	Standard query 0x0000 AAAA mywebbie.local, "QU" question
1584	18.570188	192.168.0.2	224.0.0.251	MDNS	74	Standard query 0x0000 AAAA mywebbie.local, "QM" question
1585	18.572821	192.168.0.2	224.0.0.251	MDNS	74	Standard query 0x0000 A mywebbie.local, "QM" question
1587	18.586494	192.168.0.2	224.0.0.251	MDNS	74	Standard query 0x0000 AAAA mywebbie.local, "QM" question
1589	18.589139	192.168.0.2	224.0.0.251	MDNS	74	Standard query 0x0000 A mywebbie.local, "QM" question
1596	18.994063	192.168.0.2	224.0.0.251	MDNS	74	Standard query 0x0000 AAAA mywebbie.local, "QU" question
1597	18.996961	192.168.0.2	224.0.0.251	MDNS	74	Standard query 0x0000 A mywebbie.local, "QM" question
1600	19.008226	192.168.0.2	224.0.0.251	MDNS	74	Standard query 0x0000 AAAA mywebbie.local, "QU" question
1601	19.009186	192.168.0.2	224.0.0.251	MDNS	74	Standard query 0x0000 A mywebbie.local, "QM" question
1615	20.613620	192.168.0.1	192.168.0.2	ICMP	70	Destination unreachable (Port unreachable)
1616	20.613978	192.168.0.1	192.168.0.2	ICMP	70	Destination unreachable (Port unreachable)
1619	20.614570	192.168.0.1	192.168.0.2	ICMP	70	Destination unreachable (Port unreachable)
1620	20.614874	192.168.0.1	192.168.0.2	ICMP	70	Destination unreachable (Port unreachable)