[ath9k-devel] [PATCH] ath9k: Fix symbol overlap window for half/quarter channels
Since commit cd6cfd7311a385144a2f9c74f692ae2df3ae033f "ath9k: do not set half/quarter channel flags in AR_PHY_MODE" the condition "rfMode & (AR_PHY_MODE_QUARTER | AR_PHY_MODE_HALF)" would never evaluate to true. Fix this by using the available IS_CHAN_HALF_RATE and IS_CHAN_QUARTER_RATE marcros instead. Signed-off-by: Helmut Schaa <helmut.sc...@googlemail.com> Cc: Felix Fietkau <n...@openwrt.org> --- Just stumbled over that piece of code while looking into TX99, so this is only compile-tested. Felix, can you please confirm if this is correct or if removing the whole block would be better? Thanks, Helmut drivers/net/wireless/ath/ath9k/ar9003_phy.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/wireless/ath/ath9k/ar9003_phy.c b/drivers/net/wireless/ath/ath9k/ar9003_phy.c index 81ab3ca..ae304355 100644 --- a/drivers/net/wireless/ath/ath9k/ar9003_phy.c +++ b/drivers/net/wireless/ath/ath9k/ar9003_phy.c @@ -1010,7 +1010,7 @@ static void ar9003_hw_set_rfmode(struct ath_hw *ah, if (IS_CHAN_A_FAST_CLOCK(ah, chan)) rfMode |= (AR_PHY_MODE_DYNAMIC | AR_PHY_MODE_DYN_CCK_DISABLE); - if (rfMode & (AR_PHY_MODE_QUARTER | AR_PHY_MODE_HALF)) + if (IS_CHAN_HALF_RATE(chan) || IS_CHAN_QUARTER_RATE(chan)) REG_RMW_FIELD(ah, AR_PHY_FRAME_CTL, AR_PHY_FRAME_CTL_CF_OVERLAP_WINDOW, 3); -- 2.8.1 ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] [PATCH 3/3] ath9k: Simplify ar9003_hw_tx99_set_txpower
There's no need to keep the same for loop twice in the code.
Move the txpower cap before the loop to reduce code complexity.
Signed-off-by: Helmut Schaa <helmut.sc...@googlemail.com>
---
drivers/net/wireless/ath/ath9k/ar9003_phy.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_phy.c
b/drivers/net/wireless/ath/ath9k/ar9003_phy.c
index 2f15cbc..81ab3ca 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_phy.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_phy.c
@@ -1844,13 +1844,9 @@ static void ar9003_hw_tx99_set_txpower(struct ath_hw
*ah, u8 txpower)
static u8 p_pwr_array[ar9300RateSize] = { 0 };
unsigned int i;
- if (txpower <= MAX_RATE_POWER) {
- for (i = 0; i < ar9300RateSize; i++)
- p_pwr_array[i] = txpower;
- } else {
- for (i = 0; i < ar9300RateSize; i++)
- p_pwr_array[i] = MAX_RATE_POWER;
- }
+ txpower = txpower <= MAX_RATE_POWER ? txpower : MAX_RATE_POWER;
+ for (i = 0; i < ar9300RateSize; i++)
+ p_pwr_array[i] = txpower;
ar9003_hw_tx_power_regwrite(ah, p_pwr_array);
}
--
2.8.1
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] [PATCH 2/3] ath9k: Move TX99 config option under ath9k debugging
Since ATH9K_TX99 depends on ATH9K_DEBUGFS anyway move it there such that "make menuconfig" will indent TX99 support below ath9k debugging. Signed-off-by: Helmut Schaa <helmut.sc...@googlemail.com> --- drivers/net/wireless/ath/ath9k/Kconfig | 40 +- 1 file changed, 20 insertions(+), 20 deletions(-) diff --git a/drivers/net/wireless/ath/ath9k/Kconfig b/drivers/net/wireless/ath/ath9k/Kconfig index 40fa915..f68cb00 100644 --- a/drivers/net/wireless/ath/ath9k/Kconfig +++ b/drivers/net/wireless/ath/ath9k/Kconfig @@ -75,6 +75,26 @@ config ATH9K_STATION_STATISTICS ---help--- This option enables detailed statistics for association stations. +config ATH9K_TX99 + bool "Atheros ath9k TX99 testing support" + depends on ATH9K_DEBUGFS && CFG80211_CERTIFICATION_ONUS + default n + ---help--- + Say N. This should only be enabled on systems undergoing + certification testing and evaluation in a controlled environment. + Enabling this will only enable TX99 support, all other modes of + operation will be disabled. + + TX99 support enables Specific Absorption Rate (SAR) testing. + SAR is the unit of measurement for the amount of radio frequency(RF) + absorbed by the body when using a wireless device. The RF exposure + limits used are expressed in the terms of SAR, which is a measure + of the electric and magnetic field strength and power density for + transmitters operating at frequencies from 300 kHz to 100 GHz. + Regulatory bodies around the world require that wireless device + be evaluated to meet the RF exposure limits set forth in the + governmental SAR regulations. + config ATH9K_DFS_CERTIFIED bool "Atheros DFS support for certified platforms" depends on ATH9K && CFG80211_CERTIFICATION_ONUS @@ -103,26 +123,6 @@ config ATH9K_DYNACK based on ACK frame RX timestamp, TX frame timestamp and frame duration -config ATH9K_TX99 - bool "Atheros ath9k TX99 testing support" - depends on ATH9K_DEBUGFS && CFG80211_CERTIFICATION_ONUS - default n - ---help--- - Say N. This should only be enabled on systems undergoing - certification testing and evaluation in a controlled environment. - Enabling this will only enable TX99 support, all other modes of - operation will be disabled. - - TX99 support enables Specific Absorption Rate (SAR) testing. - SAR is the unit of measurement for the amount of radio frequency(RF) - absorbed by the body when using a wireless device. The RF exposure - limits used are expressed in the terms of SAR, which is a measure - of the electric and magnetic field strength and power density for - transmitters operating at frequencies from 300 kHz to 100 GHz. - Regulatory bodies around the world require that wireless device - be evaluated to meet the RF exposure limits set forth in the - governmental SAR regulations. - config ATH9K_WOW bool "Wake on Wireless LAN support (EXPERIMENTAL)" depends on ATH9K && PM -- 2.8.1 ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] [PATCH 1/3] ath9k: reuse ar9003_hw_tx_power_regwrite for tx99 setup
The same functionality as ar9003_hw_tx_power_regwrite is hardcoded in
ar9003_hw_tx99_set_txpower. Just reuse the existing ar9003_hw_tx_power_regwrite
for TX99 setup too.
Signed-off-by: Helmut Schaa <helmut.sc...@googlemail.com>
---
drivers/net/wireless/ath/ath9k/ar9003_eeprom.c | 2 +-
drivers/net/wireless/ath/ath9k/ar9003_eeprom.h | 1 +
drivers/net/wireless/ath/ath9k/ar9003_phy.c| 60 ++
3 files changed, 5 insertions(+), 58 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c
b/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c
index f680982..dec1a31 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c
@@ -4402,7 +4402,7 @@ static void ar9003_hw_selfgen_tpc_txpower(struct ath_hw
*ah,
}
/* Set tx power registers to array of values passed in */
-static int ar9003_hw_tx_power_regwrite(struct ath_hw *ah, u8 * pPwrArray)
+int ar9003_hw_tx_power_regwrite(struct ath_hw *ah, u8 * pPwrArray)
{
#define POW_SM(_r, _s) (((_r) & 0x3f) << (_s))
/* make sure forced gain is not set */
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_eeprom.h
b/drivers/net/wireless/ath/ath9k/ar9003_eeprom.h
index 694ca2e..107bcfb 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_eeprom.h
+++ b/drivers/net/wireless/ath/ath9k/ar9003_eeprom.h
@@ -355,5 +355,6 @@ unsigned int ar9003_get_paprd_scale_factor(struct ath_hw
*ah,
struct ath9k_channel *chan);
void ar9003_hw_internal_regulator_apply(struct ath_hw *ah);
+int ar9003_hw_tx_power_regwrite(struct ath_hw *ah, u8 * pPwrArray);
#endif
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_phy.c
b/drivers/net/wireless/ath/ath9k/ar9003_phy.c
index be14a8e..2f15cbc 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_phy.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_phy.c
@@ -17,6 +17,7 @@
#include
#include "hw.h"
#include "ar9003_phy.h"
+#include "ar9003_eeprom.h"
#define AR9300_OFDM_RATES 8
#define AR9300_HT_SS_RATES 8
@@ -1840,7 +1841,7 @@ static void ar9003_hw_tx99_stop(struct ath_hw *ah)
static void ar9003_hw_tx99_set_txpower(struct ath_hw *ah, u8 txpower)
{
- static s16 p_pwr_array[ar9300RateSize] = { 0 };
+ static u8 p_pwr_array[ar9300RateSize] = { 0 };
unsigned int i;
if (txpower <= MAX_RATE_POWER) {
@@ -1851,62 +1852,7 @@ static void ar9003_hw_tx99_set_txpower(struct ath_hw
*ah, u8 txpower)
p_pwr_array[i] = MAX_RATE_POWER;
}
- REG_WRITE(ah, 0xa458, 0);
-
- REG_WRITE(ah, 0xa3c0,
- ATH9K_POW_SM(p_pwr_array[ALL_TARGET_LEGACY_6_24], 24) |
- ATH9K_POW_SM(p_pwr_array[ALL_TARGET_LEGACY_6_24], 16) |
- ATH9K_POW_SM(p_pwr_array[ALL_TARGET_LEGACY_6_24], 8) |
- ATH9K_POW_SM(p_pwr_array[ALL_TARGET_LEGACY_6_24], 0));
- REG_WRITE(ah, 0xa3c4,
- ATH9K_POW_SM(p_pwr_array[ALL_TARGET_LEGACY_54], 24) |
- ATH9K_POW_SM(p_pwr_array[ALL_TARGET_LEGACY_48], 16) |
- ATH9K_POW_SM(p_pwr_array[ALL_TARGET_LEGACY_36], 8) |
- ATH9K_POW_SM(p_pwr_array[ALL_TARGET_LEGACY_6_24], 0));
- REG_WRITE(ah, 0xa3c8,
- ATH9K_POW_SM(p_pwr_array[ALL_TARGET_LEGACY_1L_5L], 24) |
- ATH9K_POW_SM(p_pwr_array[ALL_TARGET_LEGACY_1L_5L], 16) |
- ATH9K_POW_SM(p_pwr_array[ALL_TARGET_LEGACY_1L_5L], 0));
- REG_WRITE(ah, 0xa3cc,
- ATH9K_POW_SM(p_pwr_array[ALL_TARGET_LEGACY_11S], 24) |
- ATH9K_POW_SM(p_pwr_array[ALL_TARGET_LEGACY_11L], 16) |
- ATH9K_POW_SM(p_pwr_array[ALL_TARGET_LEGACY_5S], 8) |
- ATH9K_POW_SM(p_pwr_array[ALL_TARGET_LEGACY_1L_5L], 0));
- REG_WRITE(ah, 0xa3d0,
- ATH9K_POW_SM(p_pwr_array[ALL_TARGET_HT20_5], 24) |
- ATH9K_POW_SM(p_pwr_array[ALL_TARGET_HT20_4], 16) |
- ATH9K_POW_SM(p_pwr_array[ALL_TARGET_HT20_1_3_9_11_17_19], 8)|
- ATH9K_POW_SM(p_pwr_array[ALL_TARGET_HT20_0_8_16], 0));
- REG_WRITE(ah, 0xa3d4,
- ATH9K_POW_SM(p_pwr_array[ALL_TARGET_HT20_13], 24) |
- ATH9K_POW_SM(p_pwr_array[ALL_TARGET_HT20_12], 16) |
- ATH9K_POW_SM(p_pwr_array[ALL_TARGET_HT20_7], 8) |
- ATH9K_POW_SM(p_pwr_array[ALL_TARGET_HT20_6], 0));
- REG_WRITE(ah, 0xa3e4,
- ATH9K_POW_SM(p_pwr_array[ALL_TARGET_HT20_21], 24) |
- ATH9K_POW_SM(p_pwr_array[ALL_TARGET_HT20_20], 16) |
- ATH9K_POW_SM(p_pwr_array[ALL_TARGET_HT20_15], 8) |
- ATH9K_POW_SM(p_pwr_array[ALL_TARGET_HT20_14], 0));
- REG_WRITE(ah, 0xa3e8,
- ATH9K_POW_SM(p_pwr_array[ALL_TARGET_HT40_23], 24) |
- ATH9K_POW_SM(p_pwr_array[ALL_TARGET_HT40_22], 16) |
-
Re: [ath9k-devel] [PATCH] ath9k: Allow platform override without EEPROM override
On Wed, May 7, 2014 at 9:28 AM, Helmut Schaa helmut.sc...@googlemail.com wrote: Add a new platform data flag use_eeprom that indicates that the eeprom found on the card itself should be used instead of the one present in the platform data. This allows to override the MAC address of a PCI card while preserving the eeprom data from the card itself. The default behavior is preserved. Signed-off-by: Helmut Schaa helmut.sc...@googlemail.com John, please hold on this one. I'll send a v2. Helmut ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] [PATCH] ath9k: Allow platform override without EEPROM override
Add a new platform data flag use_eeprom that indicates that the eeprom
found on the card itself should be used instead of the one present in
the platform data.
This allows to override the MAC address of a PCI card while preserving
the eeprom data from the card itself.
The default behavior is preserved.
Signed-off-by: Helmut Schaa helmut.sc...@googlemail.com
---
drivers/net/wireless/ath/ath9k/init.c | 2 +-
include/linux/ath9k_platform.h| 2 ++
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath9k/init.c
b/drivers/net/wireless/ath/ath9k/init.c
index c99e50f..1af7708 100644
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -508,7 +508,7 @@ static int ath9k_init_softc(u16 devid, struct ath_softc *sc,
sc-tx99_power = MAX_RATE_POWER + 1;
init_waitqueue_head(sc-tx_wait);
- if (!pdata) {
+ if (!pdata || pdata-use_eeprom) {
ah-ah_flags |= AH_USE_EEPROM;
sc-sc_ah-led_pin = -1;
} else {
diff --git a/include/linux/ath9k_platform.h b/include/linux/ath9k_platform.h
index 8598f8e..a495a95 100644
--- a/include/linux/ath9k_platform.h
+++ b/include/linux/ath9k_platform.h
@@ -36,6 +36,8 @@ struct ath9k_platform_data {
int (*get_mac_revision)(void);
int (*external_reset)(void);
+
+ bool use_eeprom;
};
#endif /* _LINUX_ATH9K_PLATFORM_H */
--
1.8.4.5
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] ath9k: Sometimes noisefloor is missing in survey data
Hi, while playing with ACS in hostapd I noticed that sometimes the noisefloor information is not included in the survey data when using ath9k. Any idea how and why this can happen? Thanks, Helmut ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH v2] ath9k_htc: Restore skb headroom when returning skb to mac80211
Hi John, Hi Marc, On Tue, Aug 20, 2013 at 11:01 AM, Marc Kleine-Budde m...@blackshift.org wrote: On 08/16/2013 09:39 PM, Marc Kleine-Budde wrote: From: Helmut Schaa helmut.sc...@googlemail.com ath9k_htc adds padding between the 802.11 header and the payload during TX by moving the header. When handing the frame back to mac80211 for TX status handling the header is not moved back into its original position. This can result in a too small skb headroom when entering ath9k_htc again (due to a soft retransmission for example) causing an skb_under_panic oops. Fix this by moving the 802.11 header back into its original position before returning the frame to mac80211 as other drivers like rt2x00 or ath5k do. Reported-by: Marc Kleine-Budde m...@blackshift.org Signed-off-by: Helmut Schaa helmut.sc...@googlemail.com Tested-by: Marc Kleine-Budde m...@blackshift.org Signed-off-by: Marc Kleine-Budde m...@blackshift.org --- Hello Helmut, I've change the patch a bit, I've used ieee80211_get_hdrlen_from_skb() instead of open coding it. Tested in ARMv5 with USB device ID 0cf3:7015 Atheros Communications, Inc. TP-Link TL-WN821N v3 802.11n [Atheros AR7010+AR9287] for four weeks. Without that patch the kernel oopes after about one week. I think this is a candidate for stable, can you add stable to Cc? ping Sorry, completely forgot about this patch. You're right, this is indeed a stable candidate. John, could you please add Cc: sta...@vger.kernel.org when applying this to your tree? Thanks, Helmut ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH] ath9k_htc: fix skb_under_panic error
On Wed, Jun 5, 2013 at 7:03 PM, Oleksij Rempel li...@rempel-privat.de wrote: I was running two stream netperf test for 2 hours without visible regressions. With or without your pskb_expand_head patch applied? Thanks, Helmut ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH] ath9k_htc: fix skb_under_panic error
Hi, On Tue, Jun 4, 2013 at 8:37 PM, Oleksij Rempel li...@rempel-privat.de wrote: This error seems to be really rare, and we do not know real couse of it. But, in any case, we should check size of head before reducing it. We had a similar issue in rt2x00 quite some time ago. In general mac80211 should always reserve enough headroom as requested by the driver in hw-extra_tx_headroom. However, there is a chance that a frame is send to the driver again (see ieee80211_handle_filtered_frame). But if the frame payload (or head) was moved due to padding and was not restored before calling ieee80211_tx_status by the driver the second trip through the driver has reduced headroom and could lead to such an error. Quickly checking ath9k_htc it seems as if ath9k_htc_tx adds some padding but ath9k_htc_tx_process does not remove the padding when passing the frame back to mac80211. Helmut ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH] ath9k_htc: fix skb_under_panic error
On Tue, Jun 4, 2013 at 8:37 PM, Oleksij Rempel li...@rempel-privat.de wrote:
This error seems to be really rare, and we do not know real couse of it.
But, in any case, we should check size of head before reducing it.
Mind to try the (completely untested) patch against wireless-testing instead?
Helmut
---
Subject: [PATCH] ath9k_htc: Restore skb headroom when returning skb to mac80211
ath9k_htc adds padding between the 802.11 header and the payload during
TX by moving the header. When handing the frame back to mac80211 for TX
status handling the header is not moved back into its original position.
This can result in a too small skb headroom when entering ath9k_htc
again (due to a soft retransmission for example) causing an
skb_under_panic oops.
Fix this by moving the 802.11 header back into its original position
before returning the frame to mac80211 as other drivers like rt2x00
or ath5k do.
Signed-off-by: Helmut Schaa helmut.sc...@googlemail.com
---
drivers/net/wireless/ath/ath9k/htc_drv_txrx.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c
b/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c
index e602c95..666cfb6 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c
@@ -448,6 +448,8 @@ static void ath9k_htc_tx_process(struct
ath9k_htc_priv *priv,
struct ieee80211_conf *cur_conf = priv-hw-conf;
bool txok;
int slot;
+struct ieee80211_hdr *hdr;
+int padpos, padsize;
slot = strip_drv_header(priv, skb);
if (slot 0) {
@@ -504,6 +506,15 @@ send_mac80211:
ath9k_htc_tx_clear_slot(priv, slot);
+/* Remove padding before handing frame back to mac80211 */
+hdr = (struct ieee80211_hdr *) skb-data;
+padpos = ieee80211_hdrlen(hdr-frame_control);
+padsize = padpos 3;
+if (padsize skb-len padpos + padsize) {
+memmove(skb-data + padsize, skb-data, padpos);
+skb_pull(skb, padsize);
+}
+
/* Send status to mac80211 */
ieee80211_tx_status(priv-hw, skb);
}
--
1.7.10.4
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] AR9280 issue @ 2.4 GHZ
Am Mittwoch, 6. April 2011 schrieb rafael garrido: We have several notebooks in the in the university with the following Wlan card Atheros AR9280 5GHZ 2,4GHZ ID 168C:0002A REV 01 , we are trying to use Ubuntu 10.04 kernel ver 2.6.31-21 and we have tested the latest driver available from your web site compat-wireless-2011-03-31.tar , we double checked we are able to connect to Aruba AP-125 @ 5GHZ but we are not able to connect @ 2,4 GHZ channel 1 ,11 ,52 , neither of these channels allow us to connect , always we got wlan2: deauthenticating from 00:24:6c:d0:17:f0 by local choice (reason=3) , we don´t know why the Wlan card is working properly at 5GHZ but it doesn´t at 2,4GHZ , please Have you ever heard this before ? Any idea how to solve this issue at 2,4 GHZ . Are the Aruba APs configured to force 5Ghz capable clients to 5Ghz? In that case the APs won't answer direct probe requests from clients that already scanned the 5Ghz band. And you should see log messages like direct probe timeout in your kernel log. Helmut ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] AR9280 issue @ 2.4 GHZ
[CC'ing ath9k-devel again] Am Mittwoch, 6. April 2011 schrieb rafael garrido: Yes , we have direct probe to 00:24:6c:ce:fb:40 timed out after 3 tries in the kernel log , regarding the your question , the Aruba AP-125 are configured to force 5GHZ capable clients , because the AP can spread signal at 2,4 GHZ and 5GHZ ( they have 2 radio devices ) , but there is some places set as 2,4 GHZ and we need to be sure both , so our problem is why atheros AR9280 doesn´t connect where there is 2,4 GHZ AP ? For you information we have tested this issue with another AP as Ovislink 2,4 GHZ and Atheros AR9280 connects properly , Do you know why not with Aruba AP-125 AFAIK because the Aruba AP does not comply with 802.11-2007 (11.1.3.2.1) when you enable the force 5Ghz clients to 5Ghz-feature: cite 11.1.3.2.1 Sending a probe response STAs, subject to criteria below, receiving Probe Request frames shall respond with a probe response only if a) The SSID in the probe request is the wildcard SSID or the specific SSID of the STA, b) The BSSID field in the probe request is the wildcard BSSID or the BSSID of the STA, and c) The DA field in the probe request is the broadcast address or the specific MAC address of the STA. /cite The linux wireless stack mac80211 sends a direct probe request to the AP prior to connecting. In turn the AP should answer with a probe response (case b from above). But the Aruba AP won't do this in your configuration. Hence, mac80211 thinks the AP is not in range anymore and won't even try to authenticate/ associate. The same problem seems to appear with cisco APs as well, see [1]. Helmut [1] http://www.spinics.net/lists/linux-wireless/msg59513.html ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] About the video problem of ath9k_htc
Hi,
Am Saturday 21 August 2010 schrieb LvEric:
I am using the ath9k_htc driver for TL -WN721N on my Linux Set top box.
after insmod all moudles, plugin the TL-WN721N ,and run wlist wlan0 scan,
It can works,but the video output became sharking when scaning, when it
finish the scaning,
the video back to normal. why? This driver oprate some video output? Or
something is same as the video driver?
Any body known what is the reason of this?
One possible explanation would be because the scanning involves changing
the channel and as a result the wifi card cannot exchange data with the AP
during that time (I just assume your set top box is configured as wireless
STA and associates with an AP since otherwise you wouldn't need to scan).
However, the software scan implementation in mac80211 uses the configured qos
requiremenets to determine how many channels to scan at once. In order to
reduce the average latency at the cost of a longer wireless scan duration you
can use something like the attached python script (this will set the qos
latency to 300ms while running, however not sure if the script is still up to
date). This should advise mac80211 to not leave the operating channel for
longer periods of time than 300ms (or by a different value you put in there).
And one more thing: the scan implementation in mac80211 does not respect
DTIM beacons at all and thus won't work nicely with mutli- and boradcast
traffic at all. Not sure if that applies to your issue.
HTH,
Helmut
#!/usr/bin/python
import struct, time
DEV_NODE = /dev/network_latency
pmqos_dev = open(DEV_NODE,'w')
latency = 30 #in us
data = struct.pack('=i', latency)
pmqos_dev.write(data)
pmqos_dev.flush()
while(1):
time.sleep(1.0)
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
