From: Jouni Malinen Date: Thu, 11 Dec 2008 16:22:13 +0000 (+0200) Subject: ath9k: Do not remove header padding on RX from short frames X-Git-Url: http://git.lede-project.org./?a=commitdiff_plain;h=9c5f89b3f6580cca21dca4ede940900c5b3c3a81;p=openwrt%2Fstaging%2Fblogic.git 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: Jouni Malinen Signed-off-by: John W. Linville --- diff --git a/drivers/net/wireless/ath9k/recv.c b/drivers/net/wireless/ath9k/recv.c index cb449f0b4171..f2327d8e9c28 100644 --- a/drivers/net/wireless/ath9k/recv.c +++ b/drivers/net/wireless/ath9k/recv.c @@ -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); }