mt76: mt7996 sends 802.11s mesh peering frames with zero addr3, breaking interop with ath11k (patch + validation)
openwrt at optimcloud.com
openwrt at optimcloud.com
Tue Sep 15 10:57:29 PDT 2026
On Fri, Sep 11, 2026 at 10:08 AM Janusz Dziedzic <janusz.dziedzic at gmail.com> wrote:
> Sound like a ath11k/ath12k firmware filtering issue for mesh point
> type, while mac80211 setup it zero_addr (should be received).
I'd question framing this as an ath11k/ath12k firmware issue. Here's why:
1. **The standard behavior**: 802.11s Mesh Peering Management frames are
peer-to-peer, not BSS-scoped. The transmitter's MAC belongs in Address 3,
not a BSSID (which mesh doesn't have). mac80211's own kernel MPM does this:
net/mac80211/mesh_plink.c: memcpy(mgmt->bssid, sdata->vif.addr, ETH_ALEN);
hostapd/wpa_supplicant's user-space MPM does the same. The ath11k behavior
(accepting frames with valid addr3, discarding zeroed ones) is correct.
2. **What "should be received"**: You write that mac80211 sets zero_addr and
frames "should be received". But zero_addr in addr3 for management frames
is explicitly wrong on the wire - it's an internal "no BSS" marker, not a
value to transmit. The filtering ath11k does is sensible: management frames
with addr3=00:00:00:00:00:00 are malformed.
3. **The fix location**: The workaround is in mt76, not ath11k. That tells us
where the bug lives. Other drivers (mt76_connac_mcu, mt7925) likely have
the same pattern because they copy bss_conf.bssid unconditionally, but the
solution is the same: use link_conf->addr for mesh interfaces.
4. **Firmware "fix" would be wrong**: Even if QCA changed ath11k/ath12k to
accept zero-addr3 management frames, that would make them more permissive
than the spec intends, not more correct. The transmitter should send valid
frames, not rely on receivers tolerating broken ones.
So I see this as: mt76 programs the hardware with the wrong BSS BSSID for mesh,
causing it to transmit malformed frames. The patch fixes mt76. Calling it an
ath11k firmware issue suggests the receiver should be more tolerant, but the
receiver is already correct.
Happy to discuss if I'm missing something.
Scott
More information about the openwrt-devel
mailing list