summaryrefslogtreecommitdiff
path: root/drivers/video/via
diff options
context:
space:
mode:
authorBenoit Papillault <benoit.papillault@free.fr>2010-02-27 23:05:26 +0100
committerJohn W. Linville <linville@tuxdriver.com>2010-03-10 17:44:06 -0500
commit8127fbdc417b5916b82e91400a4be1d9555feee7 (patch)
treede519dbb9bfd805769e9c13ad3cd086a57ac4ea0 /drivers/video/via
parentc2ef355bf3ef0b8006b96128726684fba47ac928 (diff)
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>
Diffstat (limited to 'drivers/video/via')
0 files changed, 0 insertions, 0 deletions