mirror of
https://github.com/outbackdingo/mt76.git
synced 2026-10-24 13:26:48 +00:00
gitops
f5f3418279
mac80211 deliberately leaves bss_conf.bssid as zero_addr for mesh interfaces, because an MBSS has no BSSID in the infrastructure sense: net/mac80211/mesh.c: sdata->vif.bss_conf.bssid = zero_addr; mt7996_mcu_bss_basic_tlv() copies that value into the hardware BSS entry, and the hardware stamps the programmed BSS BSSID into Address 3 of the management frames it transmits. Every Mesh Peering Management frame (Self-Protected Action, category 15) therefore leaves the radio with addr3 = 00:00:00:00:00:00. That value is wrong for the wire. mac80211's own kernel MPM puts the transmitter's MAC in addr3 (net/mac80211/mesh_plink.c: memcpy(mgmt->bssid, sdata->vif.addr, ETH_ALEN)), and hostapd does the same for user-space MPM. bss_conf.bssid == zero is a "no associated BSS" marker, not a value to transmit. This breaks 802.11s interoperability with peers that filter received management frames on BSSID. Measured against an ath11k (QCN9074) peer over a 35 s window: 217 Mesh Peering Open and 194 Peering Confirm frames were transmitted and ACKed at the MAC layer, and none were delivered to the peer's host, while 108 of 400 SAE Authentication frames from the same radio -- which carry a correct addr3 -- were delivered normally. SAE therefore completes and MPM never does; the peer closes with reason 56 (MESH_MAX_RETRIES) reporting our link ID as 0. Instrumenting mt7996_tx() confirms the header is correct on entry to the driver and zeroed on air (same 25 s window: 1035 frames with addr3 = own MAC at mt7996_tx(), 915 frames with addr3 = 0 on air, captured by an independent monitor-mode station). mld=0 on every sample, so the MLD address rewrite in mt7996_tx() is not involved. With this change addr3 is correct on air and a BPI-R4 joins a three-node ath11k 802.11s/batman-adv mesh: all four nodes reach plink ESTAB and exchange batman-adv originators. Signed-off-by: outbackdingo <[email protected]>