When beacons get stuck in AP mode, the most likely cause is interference.
Such interference can often go on for a while, and too many consecutive
beacon misses can lead to connected clients getting dropped.
Since connected clients might not be subjected to the same interference
if that happens to be very local, the AP should try to deal with it as
good as it can. One way to do this is to trigger an NF calibration with
automatic baseband update right after the beacon miss. In my tests with
very strong interference, this allowed the AP to continue transmitting
beacons after only 2-3 misses, which allows a normal client to stay
connected.
With some of the newer - really sensitive - chips, the maximum noise
floor limit is very low, which can be problematic during very strong
interference. To avoid an endless loop of stuck beacons -> nfcal ->
periodic calibration -> stuck beacons, the beacon miss event also sets
a flag, which allows the calibration code to bypass the chip specific
maximum NF value. This flag is automatically cleared, as soon as the
first NF median goes back below the limits for all chains.
In my tests, this allowed an ath9k AP to survive very strong interference
(measured NF: -68, or sometimes even higher) without losing connectivity
to its clients. Even under these conditions, I was able to transmit
several mbits/s through the interface.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Stuck beacons are a useful indicator for debugging various PHY
issues such as calibration. Putting them on the same debug level
as the other beacon stuff makes it hard to spot them in huge amounts
of spam.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
With VEOL, Beacon transmission in ad-hoc does not currently work.
I believe for larger ad-hoc networks, VEOL is too unreliable, as
it can get beacon transmissions stuck during synchronization.
Use SWBA based beacon trasmission similar to AP mode instead.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Acked-by: Benoit Papillault <benoit.papillault@free.fr>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This fixes IBSS beacon transmissions without VEOL enabled
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Add ah variable in the functions that didn't have it and used sc->imask.
Replace sc->sc_ah with ah in those functions.
Signed-off-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
In AP mode, ath_beacon_config_ap only restarts the timer if a TSF
restart is requested. Apparently this was added, because this function
unconditionally sets the flag for TSF reset.
The problem with this is, that ath9k_hw_reset() clobbers the timer
registers (specified in the initvals), thus effectively disabling the
SWBA interrupt whenever a card reset without TSF reset is issued
(happens in a few places in the code).
This patch fixes ath_beacon_config_ap to only issue the TSF reset flag
when necessary, but reinitialize the timer unconditionally. Tests show,
that this is enough to keep the SWBA interrupt going after a call to
ath_reset()
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Cc: stable@kernel.org
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Instead of hardcoding the lowest rate for Beacon frames, use the rate
index specified in the mac80211 TX info in AP mode.
Signed-off-by: Jouni Malinen <jouni.malinen@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
beacons configuration SHOULD be done only if the STA is associated.
Signed-off-by: Senthil Balasubramanian <senthilkumar@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Previously ath9k left the initialization of slot timing and ACK/CTS
timeout to the mode specific initvals. This does not handle short vs
long slot in 2.4 GHz and uses a rather strange value for the 2.4 GHz
ACK timeout (64 usec).
This patch uses the proper ath9k_hw functions for setting slot time and
timeouts and also implements the switch between short and long slot
time in 2.4 GHz
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Update the beacon queue parameters with best effort queue parameters for
IBSS mode. This reduces the number of beacons generated by ath9k and
ensures a fair beacon distribution when there are multiple IBSS stations.
Also CWmin is quadrupled to achieve the expected percentage of
distribution.
Signed-off-by: Vivek Natarajan <vnatarajan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch changes ath9k to pass proper MCS indexes and flags
between the RC and the rest of the driver code.
sc->cur_rate_table remains, as it's used by the RC code internally,
but the rest of the driver code no longer uses it, so a potential
new RC for ath9k would not have to update it.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
And move it to hw code on mac.c where it belongs.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
ath9k uses this for now, ath9k_htc is expected to re-use this
as well. We lave ath5k as is, but it certainly can also be
converted later.
The ath9k module parameter and debugfs entry is kept.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When the TSF is reset power save state is disabled and
then restored. The helpers to disable power save and restore
it use a lock provided by the driver core. Move the callers
of the helpers outside of the hw code.
We reset the TSF when mac80211 tells us and on the beacon.c
helper ath9k_hw_beaconinit() when it is made explicitly required.
Add a helper on beacon.c which will deal with ps awake/restore
if we need to reset the TSF upon ath9k_hw_beaconinit().
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
DPRINTF() is used in hw specific related code, as such
ensure we don't rely on the private driver core ath_softc
struct when calling it. Drivers can then implement their
own DPRINTF() as they see fit.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch moves the sanity check on beacon interval
which was done only for mesh mode to all operating
modes just to be safe.
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
It looks like mac80211 can request the driver to start beaconing with
a beacon interval of zero in some cases (at least for mesh point). This
does not sound correct and something may need to be fixed in
mac80211. However, taken into account the unpleasantness of getting
stuck in an infinite busy loop with rtnl_lock held, let's add a quick
workaround in the driver to avoid the worst symptom while someone more
familiar with the mesh implementation can figure out what should be done
with mac80211 as far as beacon interval configuration is concerned.
Signed-off-by: Jouni Malinen <jouni.malinen@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
I have a TrendNet 652-BRP running OpenWRT + ath9k very well. The only
problem is that the beacon gets stuck maybe once a day. After
Vasanthakumar Thiagarajan's "ath9k: cleanup beacon parameters
configuration" patch, ath9k would nearly re-configure the beacons after it
detected the stuck beacon, and did a reset. But it would fail the
SC_OP_TSF_RESET check in ath_beacon_config_ap. This patch gets the beacon
fully reconfigured after the reset.
Signed-off-by: Jeff Hansen <x@jeffhansen.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The previous version used a simple loop to go through all Beacon
frames when determining the next TBTT and DTIM count. This is not too
bad for the case where the setup happens before timesync (i.e., very
small TSF), but this can become very heavy operation if a short Beacon
interval is used and the current TSF is large.
In preparation for a patch to update timer setup based on Beacon
timestamp, optimize this routine to take fixed time regardless of the
actual TSF value.
Signed-off-by: Jouni Malinen <jouni.malinen@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch configures the beacon timers with beacon interval
and beacon period passed through vif.bss_conf. Also cache the
currecnt beacon configuration which will be used to configure
the beacon timers when the driver triggers it after reset.
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
On x86 this allows us to do the following small savings:
shave off 23 % off of the module's data, and
shave off 6 % off of the module's text.
We save 456 bytes, for those counting.
$ size ath9k.ko
text data bss dec hex filename
250794 3628 1600 256022 3e816 ath9k.ko
$ size ath9k-old.ko
text data bss dec hex filename
239114 15308 1600 256022 3e816 ath9k-old.ko
$ du -b ath9k.ko
4034244 ath9k.ko
$ du -b ath9k-old.ko
4033788 ath9k-old.ko
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
We currently have two beacon interval configuration knobs:
hw.conf.beacon_int and vif.bss_info.beacon_int. This is
rather confusing, even though the former is used when we
beacon ourselves and the latter when we are associated to
an AP.
This just deprecates the hw.conf.beacon_int setting in favour
of always using vif.bss_info.beacon_int. Since it touches all
the beaconing IBSS code anyway, we can also add support for
the cfg80211 IBSS beacon interval configuration easily.
NOTE: The hw.conf.beacon_int setting is retained for now due
to drivers still using it -- I couldn't untangle all
drivers, some are updated in this patch.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
