ROUTER: GL-BE9300
FIRMWARE: OpenWrt 23.05-SNAPSHOT (ipq53xx/generic)
INTERNET: FTTP direct to BE9300 via PPPoE (iiNet, Australia)
DNS: AdGuard Home (local, on router)
IPs: Mix of DHCP and static reservations
ISSUE
When two WiFi clients connect to the MLO SSID on different bands,
they cannot communicate with each other at all. Ping times out,
TCP connections fail, and discovery apps cannot see the affected
device. The router can reach both clients fine, and each client
can reach wired devices and the internet without issue.
REPRODUCTION
Client A (Windows 11 laptop, Intel WiFi): connects to MLO SSID on 5GHz
Client B (Samsung S25 Ultra): connects to MLO SSID on 6GHz
Client A cannot ping or connect to Client B and vice versa
ARP is fully resolved on both sides (correct MACs, REACHABLE state)
Packets leave Client A but never arrive at Client B
Other WiFi clients on 5GHz can reach Client A without issue,
confirming the bridge and intra-BSS forwarding work correctly
within the same band.
AP isolation is confirmed off (isolate=0) on all relevant SSIDs.
nftables ruleset accepts all LAN traffic. Windows Firewall is not
the cause — the block is bidirectional and present at the ICMP level.
WORKAROUND
Disabling 6GHz from the MLO SSID (leaving 2.4 and 5GHz active)
resolves the issue immediately. Both clients connect via MLO on
2.4+5GHz and can communicate normally.
Alternatively, connecting the S25 Ultra to a non-MLO 5GHz SSID
also resolves it.
ROOT CAUSE (suspected)
The Qualcomm QSDK driver does not appear to forward frames between
clients associated on different MLO links (e.g. one on 5GHz radio,
one on 6GHz radio). Standard Linux tools (iw, wlanconfig) cannot
inspect wireless associations on this driver stack so deeper
diagnosis from the OS side is not possible.
REQUEST:
Hi, now I can be a bit less formal I hope this is enough information to be a bug report, or to get a better workaround for this, as losing 6GHz sucks. Thank you for your time
Same issue confirmed on GL-BE9300 I’m running firmware 4.84 release with OpenWrt 23.05-SNAPSHOT. In my case the affected devices are Apple HomePods (WiFi 5/6).
I have found a persistent issue where wifi clients, when the Admin Panel labels them as MLO, are unreachable from other wireless clients (no response to arping) while AP isolation is confirmed disabled on all SSIDs. The router can ping those devices fine but they cannot talk to each other.
For me, the clearest symptom is intermittent AirPlay and HomeKit unavailability. HomePods that get listed as MLO see unpredictable connectivity. Trying to AirPlay or viewing device settings wirelessly becomes flaky to impossible, and devices’ network settings show signs and connectivity warnings.
REPRODUCTION
AP isolation is confirmed off (isolate=0 on all 12 wifi-iface entries in UCI config). Ping sweep from a Mac results in failures from MLO clients:
HomePod, MLO: unreachable — arping confirms no ARP response
HomePod, MLO: unreachable
HomePod, MLO: unreachable
HomePod, 5G: reachable
Apple TV, 5G: reachable
Additionally, band assignments seem to change at random, if devices move between MLO and non-MLO over time this causes unpredictable failures without any user action.
WORKAROUND ATTEMPTED
I’ve the tried multicast-to-unicast + IGMP snooping workarounds suggested in thread #66693 "gl-inet-flint-3-gl-be9300-wifi-mlo-device-discovery-issues". This did not resolve the issue for me. I saw a brief improvement after reboot, most likely due to temporary placement on 5G, but as the network settled I continued seeing the flaky MLO devices.
SUSPECTED ROOT CAUSE
This would support the root cause of the driver not forwarding frames between clients on different MLO links.
Once I disabled 6GHz from MLO, the issue immediately disappeared, all HomePods become reachable and AirPlay works correctly.
I ran the commands you mentioned in this comment and it seems to be working for the time being. I found that the issue took a few hours to occur - perhaps enough time for my phone or laptop to want to hunt for a different band - so I will update if that did not fix the 6Ghz issue
In the meantime I look forward to a possible firmware patch to fix this
Been a few days connected to the mlo network with 6ghz enabled and all seems to be working, direct ssh connections, moonlight streaming, tailscale, so all good here
It seems the same issue reared itself after about a week, had to run the commands again and it seems to have fixed the issue again - but there is now the issue of my phone-to-tv connection not working - can not use my phone as a remote via the home app
The command to configure Proxy ARP at the kernel level is as follows:
# --- Workaround Flint3 WLAN-ARP-Bug ---
sleep 15
for i in /proc/sys/net/ipv4/conf/*; do
[ -d "$i" ] || continue
IFACE="$(basename "$i")"
case "$IFACE" in
phy*-ap* | wlan*)
echo 1 > "$i/proxy_arp" 2>/dev/null
;;
esac
done
# --- End Workaround ---
We are still investigating this issue further.
In past cases, it has sometimes been caused by client devices not waking up properly after Wi-Fi sleep. In such situations, there isn’t a very effective solution other than fixing it on the client side.
Enabling proxy ARP or multicast-to-unicast can help mitigate the issue to some extent, but they are not universal solutions (and may interfere with devices or applications that rely on MAC address behavior).
We may need to gather more cases and further figure out on this.
Proxy ARP fix doesn’t seem to be working anymore, more and more devices are unable to communicate (All pathways between laptop, phone, and tv are no longer working on mlo network)
Currently my “fix” is to just not use MLO and put everything on a fixed 6ghz band unfortunately
Wireless clients connected to the 6 GHz band cannot communicate with clients on the 2.4 GHz / 5 GHz bands, even when all clients share the same SSID, the same subnet, and Client Isolation is explicitly disabled. Disabling the 6 GHz radio entirely resolves the issue immediately.
Environment
Router: GL.iNet Flint 3 (BE9300), running as main router
Affected client: Apple Mac mini (M5, WiFi 6E) — connected to the 6 GHz band
Unreachable device: Network printer — connected to the 2.4/5 GHz band
Reachable from affected client: router gateway, all other wired and wireless (2.4/5 GHz) devices
Symptoms
The 6 GHz client can ping and reach all devices on the LAN except those associated to other bands.
ping <2.4/5 GHz device> → 100% packet loss (sendto: No route to host / Host is down)
ARP initially shows (incomplete) for the target; after flushing the ARP cache the MAC resolves correctly, but TCP connections still fail.
tcpdump confirms the 6 GHz client sends SYN packets correctly, but receives no response whatsoever — no SYN-ACK, no RST. The target device never replies at L3.
All tested ports (HTTP, HTTPS, IPP, raw printing) timeout.
Troubleshooting performed (all negative)
Client Isolation: disabled in wireless settings — confirmed in UI
No IP conflicts on the LAN (verified via router ARP table)
No routing anomaly on the affected client (correct interface and gateway via route get)
Client-side firewall: disabled
DNS filtering (AdGuard Home): disabled during testing — no effect
No VPN active on the affected client
Root cause hypothesis
The Flint 3 appears to enforce implicit inter-band isolation between the 6 GHz radio and the 2.4/5 GHz radios at L2, regardless of the Client Isolation setting. ARP replies and TCP responses from 2.4/5 GHz clients never reach 6 GHz clients. This silently partitions the wireless LAN by band with no user-facing indication.
Workaround
Disabling the 6 GHz radio causes the affected client to fall back to 5 GHz, after which full L2 connectivity is restored immediately.
Request
Confirm whether inter-band L2 forwarding is intentionally restricted on this platform.
If unintentional, provide a firmware fix or a supported workaround to allow 6 GHz ↔ 2.4/5 GHz client communication.
If by design, please document this behaviour explicitly.
Tested on a single-router setup with no mesh nodes or additional APs.
Another data point on 4.9.0, plus a detail that might help narrow it down.
Setup: GL-BE9300 on 4.9.0, one MLO SSID across 2.4/5/6GHz, AP isolation off everywhere. A WiFi 6E laptop (Intel AX211, single link, no MLO) associated to the 6GHz link could not reach any other wireless client. Wired hosts and the router itself were always reachable. The same laptop on the 5GHz link works perfectly.
I flushed the laptop's ARP cache while it was on 6GHz and pinged a 2.4GHz client (a printer). ARP resolved with the correct MAC, presumably answered by proxy ARP on the AP, but ping was 100% loss and TCP to the same host failed. So in my case address resolution succeeds, and the unicast forwarding path from the 6GHz link towards clients on other links is where frames are lost. That looks slightly different from the pcap in the BE6500 thread where the ARP broadcast itself went missing, so there may be two failure modes, or proxy ARP masks one of them.
The failure also is not stable per band pair. 6GHz to 2.4GHz was dead in every test across two days. 6GHz to 5GHz was dead in the morning and working in the evening after some client roams, with nothing changed on the router. Stale forwarding entries after a client moves links would fit what I saw.
Throughout all of this the affected targets were simultaneously reachable from a wired host and from a 5GHz client, so the targets themselves are fine.
Same workaround as everyone else: removing 6GHz from the MLO SSID fixes it immediately. Happy to run diagnostics on 4.9.0 if the team wants logs.
Thank you for the detailed report and the additional clues.
Regarding the WiFi clients cannot communicate on MLO 6GHz issue, we are still working with Qualcomm to investigate and resolve it. At the moment, no further log information is needed.
In any case, thank you for your patience and willingness to cooperate.
I hope this is enough information to be a bug report, or to get a better workaround for this, as losing 6GHz sucks. Thank you for your time
signs and connectivity warnings.
Once I disabled 6GHz from MLO, the issue immediately disappeared, all HomePods become reachable and AirPlay works correctly.