Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit 9c5f89b3 authored by Jouni Malinen's avatar Jouni Malinen Committed by John W. Linville
Browse files

ath9k: Do not remove header padding on RX from short frames 



The 802.11 header is only padded to 32-bit boundary when the frame has
a non-zero length payload. In other words, control frames (e.g., ACK)
do not have a padding and we should not try to remove it. This fixes
monitor mode for short control frames. In addition, the hdrlen&3 use
is described in more detail to make it easier to understand how the
padding length is calculated.

Signed-off-by: default avatarJouni Malinen <jouni.malinen@atheros.com>
Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
parent f2f1ba25

drivers/net/wireless/ath9k/recv.c

+10 −2
Original line number Diff line number Diff line
@@ -571,8 +571,16 @@ int ath_rx_tasklet(struct ath_softc *sc, int flush) 
		hdr = (struct ieee80211_hdr *)skb->data;

		hdrlen = ieee80211_get_hdrlen_from_skb(skb);



		if (hdrlen & 3) {

			padsize = hdrlen % 4;

		/* The MAC header is padded to have 32-bit boundary if the

		 * packet payload is non-zero. The general calculation for

		 * padsize would take into account odd header lengths:

		 * padsize = (4 - hdrlen % 4) % 4; However, since only

		 * even-length headers are used, padding can only be 0 or 2

		 * bytes and we can optimize this a bit. In addition, we must

		 * not try to remove padding from short control frames that do

		 * not have payload. */

		padsize = hdrlen & 3;

		if (padsize && hdrlen >= 24) {

			memmove(skb->data + padsize, skb->data, hdrlen);

			skb_pull(skb, padsize);

		}