Search Linux Wireless

[RFC]: atk5k: fix FCS corruption for ACKs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



When running a monitor interface with ath5k, the FCS of ACK
frames is two bytes short. The reason is that unlike the
payload, the FCS doesn't seem to aligned to a 4 byte boundary
by the chip, the attempt to remove the padding corrupts it.

This patch checks whether there actually is any payload after
the header (besides the FCS) before removing the padding.

This might not be fully correct or not handle other cases where
this can occur, but it doesn't seem too hackish and fixes the
problem for me :)

http://bugzilla.kernel.org/show_bug.cgi?id=12101

commit 8c1d598338077d397aed25fe4840e4d4b51ba79c
Author: Patrick McHardy <kaber@xxxxxxxxx>
Date:   Tue Dec 9 21:52:00 2008 +0100

    atk5k: fix FCS corruption for ACKs
    
    The trailing FCS value is not aliged when no payload is present. Don't try
    to remove padding to avoid corrupting it.

    Kernel Bugzilla #12101
    
    Signed-off-by: Patrick McHardy <kaber@xxxxxxxxx>

diff --git a/drivers/net/wireless/ath5k/base.c b/drivers/net/wireless/ath5k/base.c
index d9e1980..940c724 100644
--- a/drivers/net/wireless/ath5k/base.c
+++ b/drivers/net/wireless/ath5k/base.c
@@ -1752,7 +1752,7 @@ accept:
 		 * not multiples of 4 - remove it
 		 */
 		hdrlen = ieee80211_get_hdrlen_from_skb(skb);
-		if (hdrlen & 3) {
+		if (hdrlen & 3 && hdrlen != rs.rs_datalen - FCS_LEN) {
 			pad = hdrlen % 4;
 			memmove(skb->data + pad, skb->data, hdrlen);
 			skb_pull(skb, pad);

[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]
  Powered by Linux