ath5k: Fix TX/RX padding for all frames
authorBenoit Papillault <benoit.papillault@free.fr>
Sat, 27 Feb 2010 22:05:26 +0000 (23:05 +0100)
committerJohn W. Linville <linville@tuxdriver.com>
Wed, 10 Mar 2010 22:44:06 +0000 (17:44 -0500)
commit8127fbdc417b5916b82e91400a4be1d9555feee7
treede519dbb9bfd805769e9c13ad3cd086a57ac4ea0
parentc2ef355bf3ef0b8006b96128726684fba47ac928
ath5k: Fix TX/RX padding for all frames

Currently, the padding position is based on
ieee80211_get_hdrlen_from_skb(). This is not correct since the HW does
padding on RX (and expect the same padding to be present on TX) at the
following position :

- management : 24 + 6 if 4-addr format
- control    : 24 + 6 if 4-addr format
- data       : 24 + 6 if 4-addr format + 2 if QoS
- invalid    : 24 + 6 if 4-addr format

whereas ieee80211_get_hdrlen_from_skb() is :

- management : 24
- control    : 16 except for ACK/CTS where it is 10
- data       : 24 + 6 if 4-addr format + 2 if QoS + 2 if QoS & order
- invalid    : 24

So, correct frames are not affected : management frames do not use
4-addr format, control frames have no body and invalid frames are ...
not valid by definition. However, in order to use monitor interface for
debugging purpose, one must be able to send/receive any frames, be it
correct or not. Such frames are affected by incorrect padding.

Moreover, since padding is added on TX, we need to remove it before
calling ieee80211_tx_status. This affect TX packets received by monitor
interfaces.

It has been tested between an ath5k based card (AR5212) and an ar9170usb
based card (netgear WNDA3100) using a frame generator and a monitor
interface for each card.

v2: Added ath5k_add_padding / ath5k_remove_padding

Signed-off-by: Benoit Papillault <benoit.papillault@free.fr>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
drivers/net/wireless/ath/ath5k/ath5k.h
drivers/net/wireless/ath/ath5k/base.c
drivers/net/wireless/ath/ath5k/desc.c