Flint 2 (GL-MT6000) firmware 4.9.1 – mDNS/multicast not working correctly on the new IoT network

Router
1

Hi,

I believe I may have found an mDNS/multicast issue with the new IoT network in firmware 4.9.x on the GL-MT6000 (Flint 2).

I have already spent a significant amount of time troubleshooting this issue. I tested different network configurations, checked routing and firewall rules, captured traffic with tcpdump on both the router and the Proxmox host, verified Wi-Fi client association, and tested individual ESPHome devices.

Unfortunately, despite all these troubleshooting efforts, I have not been able to get mDNS working correctly on the IoT network.

At this point, my tests seem to indicate that the issue is specifically related to the IoT network or its Wi-Fi/multicast handling rather than ESPHome, Home Assistant, or basic IP routing.

Router / firmware

  • Router: GL-MT6000 / Flint 2

  • GL.iNet firmware: 4.9.1

  • OpenWrt: 21.02-SNAPSHOT

  • Revision: r15812+1092-46b6ee7ffc

  • Target: mediatek/mt7986

  • Architecture: aarch64_cortex-a53

Network setup

  • Main LAN: 192.168.50.0/24

  • IoT network: 192.168.107.0/24

  • IoT gateway: 192.168.107.1

  • IoT SSID: IDIoT

  • IoT Wi-Fi: 2.4 GHz

  • IoT bridge: br-iot

  • "Isolate Clients": disabled

  • IGMP snooping: disabled

  • Multicast support on br-iot: enabled

I have several ESPHome devices connected to the IoT SSID. Normal IP/unicast communication works correctly, but mDNS communication between Wi-Fi clients on this IoT SSID does not appear to work correctly.

One of the Wi-Fi clients is my Proxmox server:

192.168.107.162

One of the ESPHome devices (esp-ble1) is:

192.168.107.232

The Proxmox client sends an mDNS query for esp-ble1.local to 224.0.0.251:5353.

When running tcpdump directly on the GL-MT6000 br-iot interface, I can see the query from Proxmox and the response from the ESPHome device:

192.168.107.162.5353 > 224.0.0.251.5353:

A (QM)? esp-ble1.local

192.168.107.232.5353 > 224.0.0.251.5353:

A 192.168.107.232

The ESPHome device also correctly advertises its _esphomelib._tcp.local service on br-iot.

However, when I capture the same traffic directly on the Proxmox Wi-Fi interface:

tcpdump -ni wlp3s0 udp port 5353 and src 192.168.107.232

I receive:

0 packets captured

So the router itself can see the mDNS response from the ESPHome device on br-iot, but the response does not reach the other Wi-Fi client.

At the same time, normal unicast communication between exactly the same two Wi-Fi clients works correctly.

For example, ESPHome API traffic on TCP port 6053 successfully reaches the Proxmox client. I can see traffic such as:

192.168.107.232.6053 > 192.168.107.162.xxxxx

Ping between the devices also works.

I also verified that both clients are associated with the same Wi-Fi AP/radio (ra2). iwinfo ra2 assoclist shows both the Proxmox Wi-Fi MAC and the ESPHome device MAC connected to the same AP.

Therefore, this does not appear to be a basic routing or connectivity issue.

A/B test with the same ESPHome device

I then performed another test using an ESP8266 ESPHome device called watermeter.

Initially, watermeter was connected to the new IoT SSID and received an address in:

192.168.107.0/24

While connected to the IoT network:

  • the device itself was reachable,

  • Home Assistant could communicate with it,

  • normal IP communication worked,

  • but ESPHome Device Builder could not resolve the device using mDNS / .local.

I then changed only the Wi-Fi network used by this device and moved the same ESP8266 from the IoT SSID to my normal Main SSID.

It received:

192.168.50.237

After moving it to the Main network, without changing the ESPHome application functionality:

  • mDNS immediately started working,

  • ESPHome Device Builder reports mDNS ACTIVE,

  • the device is shown as available,

  • hostname discovery works correctly,

  • ESPHome communication works normally.

So I can reproduce the following A/B result:

Same ESPHome device on IoT network (192.168.107.x):

Unicast/IP communication: OK

Home Assistant communication: OK

mDNS: FAIL

image
image549×594 21.9 KB

Same ESPHome device on Main network (192.168.50.x):

Unicast/IP communication: OK

Home Assistant communication: OK

mDNS: OK

image
image461×1274 28.6 KB

This makes me suspect that multicast frames originating from one Wi-Fi station on the new IoT SSID are reaching br-iot, but are not being forwarded back over Wi-Fi to other stations associated with the same IoT AP.

I also checked the wireless UCI configuration. There is no obvious multicast setting present, and client isolation is not enabled.

For example:

wireless.iot2g.ssid='IDIoT'

and the LuCI interface confirms that Isolate Clients is disabled.

Since the IoT Network functionality is relatively new in the 4.9.x firmware, I am wondering whether this could be related to the implementation of the new IoT network, the bridge configuration, or the MediaTek Wi-Fi driver used by the standard GL.iNet firmware.

Could you please advise whether this is expected behavior?

In particular:

  1. Should mDNS/multicast traffic work between two Wi-Fi clients connected to the same IoT SSID?

  2. Is there any additional multicast/client-to-client setting used internally by the new IoT Network feature?

  3. Could this be a firmware 4.9.1 or MediaTek driver issue?

  4. Would you recommend testing the Native OpenWrt/OP24 firmware to determine whether this is specific to the MediaTek SDK Wi-Fi driver?

I can provide the complete tcpdump captures, UCI configuration, firewall configuration, screenshots, or perform additional tests if required.

I would really appreciate any guidance, as I have already spent a lot of time troubleshooting this and have not been able to find a configuration issue that explains the behavior.

Thanks!

2

Hi,

Thank you for the detailed report.

Could you please SSH into the router and check the following?

uci -q get gl-black_white_list.iot.ap_isolate
uci -q get wireless.iot2g.isolate
cat /sys/class/net/ra2/brport/hairpin_mode
cat /sys/class/net/ra2/brport/multicast_to_unicast

If hairpin_mode does not return 1, please try:

ip link set dev ra2 type bridge_slave hairpin on

Then check whether mDNS starts working properly again.