7403d1b9b2
things like EAPOL frames make it out. After a whole bunch of hacking/testing, I discovered that they weren't being early-dropped by the stack (but I should look at ensuring that later..) but were even making to the hardware transmit queue. They were mostly even being received by the remote end. However, the remote end was completely ignoring them. This didn't happen under 150-170MBit TCP tests as I'm guessing the TX queue stayed very busy and the STA didn't do any scanning. However, when doing 100Mbit/s of TCP traffic, the STA would do background scanning - which involves it coming in and out of powersave mode with the AP. Now, this is a total and utter hack around the real problems, which are: * I need to implement proper power save handling and integrate it into the filtered frames support, so the driver/stack doesn't send frames whilst the station is actually in sleep; * .. but frames were actually making it to the STA (macbook pro) and the AP did receive an ACK; but a tcpdump on the receiving side showed the EAPOL frame never made it. So the stack was dropping it for some reason; * Importantly - the EAPOL frames are currently going into the non-QoS TID, which maps to the BE queue and is susceptible to that queue being busy doing other things, but; * There's other traffic going on in the non-QoS TID from other contexts when scanning is going on and it's possible there's some races causing sequence number/IV issues, but; * Importantly importantlly, I think the interaction with TID 16 multicast traffic in power save mode is causing issues - since I -believe- the sequence number space being used by the EAPOL frames on TID 16 overlaps with the multicast frames that have sequence numbers allocated and are then stuffed on the cabq. Since with EAPOL frames being in TID 16 and queued to the BE queue, it's going to be waiting to be serviced with all of the aggregate traffic going on - and if the CABQ gets emptied beforehand, those TID 16 multicast frames with sequence numbers will go out beforehand. Now, there's quite likely a bunch of "stuff happening slightly out of sequence" going on due to the nature of the TX path (read: lots of overlapping and concurrent ath_start() and ath_raw_xmit() calls going on, sigh) but I thought I had caught them all and stuffed each TID TX behind a lock (that lasted as long as it needed to in order to get the frame onto the relevant destination queue - thus keeping things in order.) Unfortunately the last problem is the big one and I'm going to stare at it some more. If it _is_ So this is a work around for now to ensure that EAPOL frames actually make it out before any other stuff in the non-QoS TID and HOPEFULLY before the CABQ gets active. I'm now going to spend a little time in the TX path figuring out exactly why the sender is rejecting things. There's two (well, three if you count EAPOL contents invalid) possibilities: * The sequence number is out of order (ie, something else like the multicast traffic on CABQ) is going out first on TID 16; * The CCMP IV is out of order (similar to above - but less likely, as the TX key for multicast traffic is different to unicast traffic); * EAPOL contents strangely invalid. AP: Ubiquiti RSPRO, AR9160/AR9220 NICs STA: Macbook Pro, Broadcom 11n NIC
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