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