22a3aee637
PS-POLL support. This implements PS-POLL awareness i nthe * Implement frame "leaking", which allows for a software queue to be scheduled even though it's asleep * Track whether a frame has been leaked or not * Leak out a single non-AMPDU frame when transmitting aggregates * Queue BAR frames if the node is asleep * Direct-dispatch the rest of control and management frames. This allows for things like re-association to occur (which involves sending probe req/resp as well as assoc request/response) when the node is asleep and then tries reassociating. * Limit how many frames can set in the software node queue whilst the node is asleep. net80211 is already buffering frames for us so this is mostly just paranoia. * Add a PS-POLL method which leaks out a frame if there's something in the software queue, else it calls net80211's ps-poll routine. Since the ath PS-POLL routine marks the node as having a single frame to leak, either a software queued frame would leak, OR the next queued frame would leak. The next queued frame could be something from the net80211 power save queue, OR it could be a NULL frame from net80211. TODO: * Don't transmit further BAR frames (eg via a timeout) if the node is currently asleep. Otherwise we may end up exhausting management frames due to the lots of queued BAR frames. I may just undo this bit later on and direct-dispatch BAR frames even if the node is asleep. * It would be nice to burst out a single A-MPDU frame if both ends support this. I may end adding a FreeBSD IE soon to negotiate this power save behaviour. * I should make STAs timeout of power save mode if they've been in power save for more than a handful of seconds. This way cards that get "stuck" in power save mode don't stay there for the "inactivity" timeout in net80211. * Move the queue depth check into the driver layer (ath_start / ath_transmit) rather than doing it in the TX path. * There could be some naughty corner cases with ps-poll leaking. Specifically, if net80211 generates a NULL data frame whilst another transmitter sends a normal data frame out net80211 output / transmit, we need to ensure that the NULL data frame goes out first. This is one of those things that should occur inside the VAP/ic TX lock. Grr, more investigations to do.. Tested: * STA: AR5416, AR9280 * AP: AR5416, AR9280, AR9160 |
||
---|---|---|
.. | ||
amd64 | ||
arm | ||
boot | ||
bsm | ||
cam | ||
cddl | ||
compat | ||
conf | ||
contrib | ||
crypto | ||
ddb | ||
dev | ||
fs | ||
gdb | ||
geom | ||
gnu/fs/reiserfs | ||
i386 | ||
ia64 | ||
isa | ||
kern | ||
kgssapi | ||
libkern | ||
mips | ||
modules | ||
net | ||
net80211 | ||
netatalk | ||
netgraph | ||
netinet | ||
netinet6 | ||
netipsec | ||
netipx | ||
netnatm | ||
netpfil | ||
netsmb | ||
nfs | ||
nfsclient | ||
nfsserver | ||
nlm | ||
ofed | ||
opencrypto | ||
pc98 | ||
pci | ||
powerpc | ||
rpc | ||
security | ||
sparc64 | ||
sys | ||
teken | ||
tools | ||
ufs | ||
vm | ||
x86 | ||
xdr | ||
xen | ||
Makefile |