4f57c7deee
to awake transition as well as handle waking up a VAP in STA powersave mode if it's in bgscan. This was a reasonably hairy bug to try and figure out and it became more obvious because of stuff I've done. Specifically: * a NIC would go into bgscan mode - either because of a bgscan timer or wpa_supplicant asked it to; * the AP would indicate there's traffic for the STA by setting the TIM bitmap bit for it; * mindwell would be met during scan, so it'd wake up and break out of the scan loop in scan_task(), but * because the scan wasn't completed, it wouldn't bring the VAP out of STA mode powersave (so it wouldn't tell the AP about it and it would block VAP TX); * .. but because we kept seeing the TIM bit set, ic->ic_lastdata was being constantly updated, and .. * bgscancont() would thus never say "yes we can continue a bgscan" so the bgscan would hang and never make progress. Now, I do see this particular state occur on iwn(4) - /however/ - this NIC has the firmware call ieee80211_scan_next() once the firmware scan for that channel has completed. This has the effect of moving the scan along to the next channel. I do see the debug that I'm adding where we see a beacon with a TIM bit set whilst we're in bgscan, so the condition about waking up to receive traffic is triggering. It just won't cause a hang. For other NICs - all of the USB ones and at least ath(4) - ieee80211_scan_next() / ieee80211_scan_done() isn't called. So it relies upon the mindwell timer, the beacon receive and the beacon / probe response -> ieee80211_add_scan() to move along the scan state. In the above case, mindwell triggered, there's no beacons triggering the scan_add code to move things along, and we weren't waking things up when seeing the TIM set for us. So it just hung until the interface was dropped. So, the short-term fix here is to do what the comment in scan_task() says - if we are in bgscan mode and we see our TIM bit set, just wake up the VAP. If it's already awake then it's a nop. If we're awake then we transition to awake and handle the traffic. Once there's no TX or RX traffic going on, ic->ic_lastdata won't be updated anymore and bgscancont() will continue. This was triggered more often after my initial SLEEP state handling for software sleep states - because now I update ic->ic_lastdata upon seeing a TIM bit set, not just the RX of the subsequent traffic. That's needed so the thing doesn't ping-pong up and down between seeing the TIM bit set, sending the "I'm awake" NULL data frame, and starting to receive data from the AP. I'd like to subsequently split ic_lastdata into two - one for TX and one for RX - so it becomes easier to use the correct one (or both!) when making decisions like whether to scan, go to sleep, etc. I'd appreciate this getting some further testing. Tested: * rsu(4), STA mode, bgscan on * iwn(4), STA mode, bgscan on
This is the top level of the FreeBSD source directory. This file was last revised on: $FreeBSD$ For copyright information, please see the file COPYRIGHT in this directory (additional copyright information also exists for some sources in this tree - please see the specific source directories for more information). The Makefile in this directory supports a number of targets for building components (or all) of the FreeBSD source tree, the most commonly used one being ``world'', which rebuilds and installs everything in the FreeBSD system from the source tree except the kernel, the kernel-modules and the contents of /etc. The ``world'' target should only be used in cases where the source tree has not changed from the currently running version. See: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html for more information, including setting make(1) variables. The ``buildkernel'' and ``installkernel'' targets build and install the kernel and the modules (see below). Please see the top of the Makefile in this directory for more information on the standard build targets and compile-time flags. Building a kernel is a somewhat more involved process, documentation for which can be found at: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig.html And in the config(8) man page. Note: If you want to build and install the kernel with the ``buildkernel'' and ``installkernel'' targets, you might need to build world before. More information is available in the handbook. The sample kernel configuration files reside in the sys/<arch>/conf sub-directory (assuming that you've installed the kernel sources), the file named GENERIC being the one used to build your initial installation kernel. The file NOTES contains entries and documentation for all possible devices, not just those commonly used. It is the successor of the ancient LINT file, but in contrast to LINT, it is not buildable as a kernel but a pure reference and documentation file. Source Roadmap: --------------- bin System/user commands. cddl Various commands and libraries under the Common Development and Distribution License. contrib Packages contributed by 3rd parties. crypto Cryptography stuff (see crypto/README). etc Template files for /etc. games Amusements. gnu Various commands and libraries under the GNU Public License. Please see gnu/COPYING* for more information. include System include files. kerberos5 Kerberos5 (Heimdal) package. lib System libraries. libexec System daemons. release Release building Makefile & associated tools. rescue Build system for statically linked /rescue utilities. sbin System commands. secure Cryptographic libraries and commands. share Shared resources. sys Kernel sources. tools Utilities for regression testing and miscellaneous tasks. usr.bin User commands. usr.sbin System administration commands. For information on synchronizing your source tree with one or more of the FreeBSD Project's development branches, please see: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/synching.html