BE9300 MLO - WiFi clients on different bands cannot communicate

Router
23

I am affected here, as my Google Home devices are not able to communicate with each other, thus failing to play music together as a speaker group while on different network bands.

24

Will you be updating the thread here?

25

Hi guys,

I’ve found that this script helps a LOT, the flakiness is not fully solved but it now works more often than not, even with 6ghz and MLO on. It basically just checks and disables any setting I’ve found to cause issues. Run it on the router via ssh or similar

#!/bin/sh
# mdns-check.sh - audit/fix multicast settings that break mDNS discovery
# Usage: sh mdns-check.sh        (report only)
#        sh mdns-check.sh fix    (disable offenders, commit, reload wifi/network)
# Target: GL.iNet GL-BE9300 (OpenWrt 23.05 / Qualcomm QSDK build)

MODE="${1:-check}"
ISSUES=0
CHANGED_NET=0
CHANGED_WIFI=0

flag() {
        ISSUES=$((ISSUES + 1))
        echo "[BAD] $1"
}

ok() {
        echo "[OK]  $1"
}

# 1. Bridge-level IGMP snooping on br-lan
for dev in $(uci show network | grep "=device$" | cut -d= -f1); do
        name=$(uci -q get "$dev.name")
        [ "$name" = "br-lan" ] || continue
        snoop=$(uci -q get "$dev.igmp_snooping")
        if [ "$snoop" = "1" ]; then
                flag "$dev (br-lan) igmp_snooping=1"
                if [ "$MODE" = "fix" ]; then
                        uci set "$dev.igmp_snooping=0"
                        CHANGED_NET=1
                fi
        else
                ok "br-lan igmp_snooping=${snoop:-unset}"
        fi
done

# 2/3. Per-wireless-interface offenders:
#   multicast_to_unicast_all (OpenWrt/mac80211 layer)
#   mcastenhance + igmpmcasten (Qualcomm driver layer, the usual killer)
for sec in $(uci show wireless | grep "=wifi-iface$" | cut -d= -f1); do
        for opt in multicast_to_unicast_all mcastenhance igmpmcasten; do
                val=$(uci -q get "$sec.$opt")
                [ -n "$val" ] || continue
                if [ "$val" != "0" ]; then
                        flag "$sec $opt=$val"
                        if [ "$MODE" = "fix" ]; then
                                uci set "$sec.$opt=0"
                                CHANGED_WIFI=1
                        fi
                else
                        ok "$sec $opt=0"
                fi
        done
done

echo ""
if [ "$ISSUES" -eq 0 ]; then
        echo "All clear. mDNS-hostile settings are disabled."
        exit 0
fi

if [ "$MODE" = "fix" ]; then
        [ "$CHANGED_NET" -eq 1 ] && uci commit network
        [ "$CHANGED_WIFI" -eq 1 ] && uci commit wireless
        echo "Fixed $ISSUES setting(s). Reloading..."
        [ "$CHANGED_NET" -eq 1 ] && /etc/init.d/network restart
        [ "$CHANGED_WIFI" -eq 1 ] && wifi
        echo "Done. If discovery is still broken, reboot the router to force the driver to reapply."
else
        echo "$ISSUES issue(s) found. Run: sh mdns-check.sh fix"
        exit 1
fi
26

Thanks for following up. Yes, we will post an update in this thread when there is meaningful progress.

At the moment, there has not been much progress. We are still working with Qualcomm because the investigation involves the wireless driver layer, and it needs more time. We do not have an ETA or a firmware version to share yet.

Thank you for your patience.

27

Thanks for sharing the script and explaining the results.

It disables IGMP snooping and several multicast-to-unicast or multicast-enhancement settings, so it may help with mDNS discovery issues such as Google Home speaker groups. However, reports in this thread also show ordinary unicast traffic, including ping and TCP, failing even after ARP has resolved. Therefore, Yes, this should currently be considered a workaround that may reduce some symptoms, rather than a confirmed fix for the underlying MLO inter-band forwarding issue.

We will continue collaborating with Qualcomm to explore how this issue can be fully resolved in a future firmware release.

Additionally, anyone using fix mode should be aware that it applies the configuration and restarts the network and Wi-Fi services, briefly disconnecting all connected devices.

Thanks again for testing and sharing this with the community.

1 Like
28

I just spent a delicious amount of time trying to diagnose issues with my network before coming across this thread and Connections between clients stop working (GL-BE93000) - #7 by will.qiu

I’m trying to understand - are these underlying Qualcomm issues specific to MLO/6G circumstances or are there just general issues with this? I have also been able to sort it out by rebooting the router - but I do not have MLO or 6G enabled (5g and 2.4 yes) on my network so trying to figure out whether these threads are relevant to me or I have a different set of issues

1 Like
30

Hi,

The Qualcomm issue we are investigating in this thread is specific to MLO configurations involving 6 GHz. If neither MLO nor 6 GHz is enabled, your issue is likely unrelated.

Could you provide your router model, full firmware version, and more details about exactly what stops working? For example, which devices are affected, how they are connected, and whether ping, TCP connections, or only device discovery fails.

While the issue is occurring, does the affected client resolve the other device’s MAC address correctly in its ARP/neighbor table? Also, have you tried enabling Proxy ARP and multicast-to-unicast, and did either make any difference?