Skip to content

Commit

Permalink
ath9k: Do not remove header padding on RX from short frames
Browse files Browse the repository at this point in the history
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 <jouni.malinen@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
  • Loading branch information
Jouni Malinen authored and John W. Linville committed Dec 12, 2008
1 parent f2f1ba2 commit 9c5f89b
Showing 1 changed file with 10 additions and 2 deletions.
12 changes: 10 additions & 2 deletions drivers/net/wireless/ath9k/recv.c
Original file line number Diff line number Diff line change
Expand Up @@ -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);
}
Expand Down

0 comments on commit 9c5f89b

Please sign in to comment.