]> git.baikalelectronics.ru Git - kernel.git/commit
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)
commit7f199f5e45e06dbc0cd93c6fdd915a91af1b798d
treede519dbb9bfd805769e9c13ad3cd086a57ac4ea0
parentacce27dd03ab9bb6b5a849c0ab0248c53cb81300
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