I would like to report a Wi-Fi 7 MLO client-to-client connectivity issue on a GL.iNet GL-BE6500 router.
Summary
-------
When two clients are connected to the same Wi-Fi 7 MLO SSID, they may not be able to reliably reach each other on the same LAN. The router itself can reach both clients, and both clients can reach the router, but one wireless client cannot initiate communication to the other because ARP resolution fails.
This appears to be related to the MLO AP / QSDK bridge forwarding path. Both clients are learned behind the same MLO interface, `mld0`, and ARP broadcast frames between the clients are not reliably forwarded.
Device / Firmware
-----------------
Router:
Model: GL.iNet GL-BE6500
OS: OpenWrt 23.05-SNAPSHOT / QSDK-based firmware
Kernel: Linux 5.4.213
LAN bridge: br-lan
MLO virtual interface: mld0
MLO SSID:
SSID: PepsiCo-MLO
2.4 GHz MLO link: active
5 GHz MLO link: active
Client A:
Device: Mac
IP: 192.168.10.220
MAC: 3e:84:d2:dd:fb:2c
Connection: Wi-Fi, same MLO SSID
Client B:
Device: Armbian Linux device
IP: 192.168.10.100
MAC: c0:bf:be:05:fd:06
Wi-Fi adapter: MediaTek MT7925
Connection: Wi-Fi, same MLO SSID
The Armbian client is connected with MLO enabled. Example output:
link_id=0
freq=2437
link_id=1
freq=5180
Observed Problem
----------------
From the Mac:
ping 192.168.10.100
fails. The Mac ARP table shows:
192.168.10.100 at incomplete
However, from the GL-BE6500 router:
ping 192.168.10.100
works normally.
The router's neighbor table also knows the Armbian client:
192.168.10.100 dev br-lan lladdr c0:bf:be:05:fd:06 REACHABLE
The Mac and the Armbian device can both reach the router. The Armbian device can also initiate traffic to the Mac. The failure is mainly when the Mac tries to initiate traffic to the Armbian device.
Important Evidence
------------------
On the GL-BE6500, both clients are learned behind the same MLO interface:
c0:bf:be:05:fd:06 dev mld0 master br-lan
3e:84:d2:dd:fb:2c dev mld0 master br-lan
This means both wireless clients are behind `mld0`.
When the Mac tries to ping the Armbian device, packet capture on the Armbian Wi-Fi interface shows ARP requests from the router, but not from the Mac.
Seen on Armbian:
ARP request 192.168.10.1 -> 192.168.10.100
ARP reply 192.168.10.100 -> 192.168.10.1
Not seen on Armbian:
ARP request 192.168.10.220 -> 192.168.10.100
This indicates that the ARP broadcast from the Mac is not being forwarded correctly by the GL-BE6500 / QSDK MLO AP path to the other MLO client.
What Was Ruled Out
------------------
The following were checked and do not appear to be the root cause:
- Armbian IP configuration
- DHCP lease assignment
- Client routing table
- Armbian firewall
- Wi-Fi power-save mode
- Normal AP isolation configuration, since isolate=0
- Linux bridge hairpin alone
The following was also tested and did not reliably solve the problem:
bridge link set dev mld0 hairpin on
Current Workaround
------------------
The issue can be worked around on the GL-BE6500 by enabling PVLAN proxy ARP on `br-lan` and disabling ICMP redirects:
/etc/sysctl.d/99-mlo-pvlan-proxy-arp.conf
with this content:
# Work around QSDK Wi-Fi 7 MLO client-to-client ARP loss.
# MLO clients are learned behind br-lan/mld0, but ARP broadcasts between them can be dropped.
net.ipv4.conf.br-lan.proxy_arp=1
net.ipv4.conf.br-lan.proxy_arp_pvlan=1
net.ipv4.conf.br-lan.send_redirects=0
net.ipv4.conf.all.send_redirects=0
Apply with:
sysctl -e -p /etc/sysctl.d/99-mlo-pvlan-proxy-arp.conf
After applying the workaround:
- The Mac can ping the Armbian device after clearing ARP.
- The Armbian device remains connected with dual-link MLO.
- The issue is resolved without changing the Armbian client configuration.
Example verification:
Mac -> Armbian:
12 packets transmitted, 12 packets received, 0.0% packet loss
Expected Behavior
-----------------
Without requiring proxy ARP, clients connected to the same MLO SSID and same LAN should be able to communicate normally.
The expected flow is:
1. Mac sends ARP request for 192.168.10.100.
2. GL-BE6500 forwards the ARP broadcast correctly through br-lan/mld0.
3. Armbian receives the ARP request.
4. Armbian replies to the Mac.
5. Client-to-client communication works normally.
Request
-------
Please investigate the GL-BE6500 / QSDK MLO AP bridge forwarding behavior, specifically:
1. Whether ARP broadcasts between clients behind the same `mld0` interface are being dropped.
2. Whether intra-BSS / client-to-client forwarding works correctly for Wi-Fi 7 MLO clients.
3. Whether the Linux bridge FDB interaction with the QSDK MLO virtual interface `mld0` is correct.
4. Whether hostapd / driver handling of multiple MLO clients behind `mld0` needs adjustment.
5. Whether this can be fixed in firmware without requiring `proxy_arp_pvlan`.
The current workaround using `proxy_arp_pvlan` is effective, but it should not be required for normal same-LAN communication between MLO wireless clients.
