NativeWifi tx mode expects QoS Data frames to be
delivered as Data frames with QoS part (e.g. tid)
being delievered out-of-band in fw tx command.
The QoS bit wasn't stripped before submitting to
firmware.
Stripping fixes two known problems:
* qca6174 IOT with some APs, e.g.
Cisco AIR-AP 1252 (which would crash after
ath10k association). Some ath9k APs would
crash as well.
* sniffing own tx frames via radiotap because,
e.g. wireshark was seeing QoS bit set but
since QoS Control was stripped in ath10k it
would parse beginning of LLC/SNAP
>From debugability point of view this removes the
ability to distinguish QoS from non-QoS frames
when sniffing own tx via radiotap. On the other
hand frames can be now parsed correctly without
special software modification.
Signed-off-by: Michal Kazior <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
skb->data, (void *)qos_ctl - (void *)skb->data);
skb_pull(skb, IEEE80211_QOS_CTL_LEN);
- /* Fw/Hw generates a corrupted QoS Control Field for QoS NullFunc
- * frames. Powersave is handled by the fw/hw so QoS NyllFunc frames are
- * used only for CQM purposes (e.g. hostapd station keepalive ping) so
- * it is safe to downgrade to NullFunc.
+ /* Some firmware revisions don't handle sending QoS NullFunc well.
+ * These frames are mainly used for CQM purposes so it doesn't really
+ * matter whether QoS NullFunc or NullFunc are sent.
*/
hdr = (void *)skb->data;
- if (ieee80211_is_qos_nullfunc(hdr->frame_control)) {
- hdr->frame_control &= ~__cpu_to_le16(IEEE80211_STYPE_QOS_DATA);
+ if (ieee80211_is_qos_nullfunc(hdr->frame_control))
cb->htt.tid = HTT_DATA_TX_EXT_TID_NON_QOS_MCAST_BCAST;
- }
+
+ hdr->frame_control &= ~__cpu_to_le16(IEEE80211_STYPE_QOS_DATA);
}
static void ath10k_tx_h_add_p2p_noa_ie(struct ath10k *ar,