wifi: mac80211: always allow transmitting null-data on TXQs

Jouni reported that certain sequences of tests caused some
WDS tests to fail after applying the upcoming hwsim changes
for NAN. I bisected that down to converting hwsim to TXQs,
and after a long debug session found that the 4-addr NDP was
getting dropped, because it goes out via a (management) TXQ
and is a data frame.

It's unclear to me now why this only happens in some test
sequences (e.g. "sigma_dut_sae_h2e_ap_loop ap_wds_sta" and
"sigma_dut_eap_ttls_all_akm_suites ap_wds_sta_open"), maybe
that affects timing and the frame is otherwise delayed in
some way.

Correct the check to only drop frames that actually carry
data, not NDPs.

Reported-by: Jouni Malinen <j@w1.fi>
Link: https://patch.msgid.link/20260417141601.851ddf4adb59.I3d668c0e1bdca9cd98f2fc46f84a066e68cc7a62@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index b487d2330f25f119f730b714900815c19c77bf1d..8e4876d1c5440083e99a1e605deb9c411a1bc119 100644 (file)
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -3916,7 +3916,7 @@ begin:
                 * injected frames or EAPOL frames from the local station.
                 */
                if (unlikely(!(info->flags & IEEE80211_TX_CTL_INJECTED) &&
-                            ieee80211_is_data(hdr->frame_control) &&
+                            ieee80211_is_data_present(hdr->frame_control) &&
                             !ieee80211_vif_is_mesh(&tx.sdata->vif) &&
                             tx.sdata->vif.type != NL80211_IFTYPE_OCB &&
                             !is_multicast_ether_addr(hdr->addr1) &&