Intermittent DNS failures for local hostnames on 2.4 GHz Wi‑Fi only

Environment

Home network with dual‑band AP (2.4 GHz and 5 GHz SSIDs on same SSID name), OpenWrt router acting as DHCP server (192.168.1.1), clients include Android phones (Android 13) and a Raspberry Pi 4 running avahi/Bonjour for local hostname advertising.

Symptoms

Clients on 2.4 GHz intermittently fail to resolve local hostnames like 'printer.local' and 'nas.local' for periods of ~1–5 minutes; 5 GHz clients continue to resolve names normally. During failure, numeric IP access (http://192.168.1.50) works from 2.4 GHz clients.

Observations

When resolution fails on 2.4 GHz: ping by name returns 'unknown host'; avahi-browse on a 2.4 GHz laptop shows fewer services than the Pi reports; pinging the router and upstream DNS succeeds with low latency; DHCP leases on router show both 2.4 and 5 GHz clients with correct IPs; router logs show frequent wireless client re-associations on 2.4 GHz coinciding with name failures.

Already attempted

Rebooted AP and router; moved AP firmware from stock to latest stable; disabled 'AP isolation' and 'multicast to unicast' options; restarted avahi-daemon on Raspberry Pi; flushed local DNS cache on affected phones; temporarily renamed SSIDs to separate bands — issue persisted only for devices on 2.4 GHz SSID. No persistent change.

Question

What diagnostic steps and packet captures should I collect to confirm whether this is an mDNS/Bonjour multicast delivery problem, wireless client roaming issue, or a DHCP/ARP cache corruption on the AP? What reversible configuration changes can I try that are unlikely to disrupt other clients?

Post timeline

COMMUNITY RESPONSES

Verified community troubleshooting

0 replies

No answers yet..

Showing 0 of 0 community responses

AI DIAGNOSTICS

Incident analysis

Updated 1w ago• Trouble ID

Most likely causes

2.4 GHz radio instability causing packet loss or frequent reassociation breaking mDNS timing 90%

AP dropping or throttling multicast/mDNS between 2.4 GHz clients (multicast-to-unicast conversion misconfigured) 75%

ARP cache or DNS caching on the AP incorrectly associating hostnames to stale MACs for 2.4 GHz clients 20%

Summary

Symptoms point to multicast service discovery or local name announcement loss isolated to 2.4 GHz clients. Correlation with frequent re‑associations suggests a wireless layer problem (packet loss, multicast handling, or client power management) but DHCP and upstream DNS working implies name resolution for local hostnames (mDNS/LLMNR) is affected. Differences by band and persistence after firmware updates suggest AP or radio configuration rather than host daemon bugs.

Suggested Fixes

Diagnostic step 1

Collect packet captures on an affected 2.4 GHz client and on the AP (or a mirrored port) during a failure window; capture IGMP/mDNS/multicast and DHCP traffic (use tcpdump -i wlan0 port 5353 or equivalent)

Diagnostic step 2

Enable verbose wireless logs on the AP temporarily and look for disassociation/reassociation events; correlate timestamps with name resolution failures

Diagnostic step 3

Temporarily force an affected client to use a static IP and manually query mDNS with avahi-resolve to test whether multicast responses are received