• Review the use of ic→ic_curchan versus per-VAP and per-node channels; ic_curchan should only be used by NICs that need net80211 to change channel/configurations.
• Update the per-VAP / global state for 11g ERP, short/long slot time, WME, HT protection, etc to assign the state per-channel, not per-VAP - so the IEs reflect reality on the given channel rather than using the “global” state currently being faked.
• Look at what it'd take to push node creation/deletion, encryption key management and transmit/receive traffic handling into asynchronous callbacks rather than synchronous driver calls. This will allow drivers that need to sleep (ie, firmware!) to sleep in their callbacks, and remove having to do all of the update deferral inside of each driver.

• Need CCMP-256 key support (11ac, 11ax)
• Need GCMP-256 key support (11ac, 11ax)
• Add support for the >1 pairwise key that showed up in 802.11-2016
• Explicitly tag keys as pairwise and remove the pointer-comparison logic done to determine if a given key is pairwise or not; it's dumb and error-prone

• (done) implement WME and HT info field parameter configuration and parsing when “seeing” neighbor 802.11 ibss/mesh nodes;
• (done) update the ibss support to negotiate 11n aggregation (which should happen automatically when the above is working);
• IBSS encryption - get it better documented; avos@ figured out how to get it working a while ago!

• The channel width change in net80211 needs to be extended to defer the actual channel width change/update (ie, the channel flags and the vap→iv_bss→ni_chw field update) until _after_ the queued channel width change net80211 task has occured. Otherwise there's a small window where ni_chw doesn't reflect what the hardware actually has configured, resulting in unpredictable messes.
• operating mode change - fix the 2ghz ping-pong that happens when overlapping BSSes have both HT and non-HT stations, so the HT protmode flips between 0x11 and 0x13
• make the A-MPDU negotiation configurable per-TID - eg, disable ADDBA/DELBA for voice/video, enable it but disable A-MPDU formation, limit maximum block-ack window, etc
• (.. right now enabling A-MPDU for voice can be very exciting)
• Go look at 802.11-2016 and make sure the HT capabilities / HT info field information is right. Notably, 802.11-2016 section 9.4.2.57 (HT operation element) has a bit “non greenfield STAs present” which we're definitely not setting or tracking
• .. and I guess whilst here at least add in the bits for correctly handling the greenfield bits during HTCAP/HTINFO and assoc/beacons; because at least THIS bit isn't set.

• fix the “current TX rate” logic for link estimation, it shouldn't use ni_txrate at all
• work with monthadar@ to include whatever other missing patches there are from his tree
• monthadar's 11s work broke one important thing - when using 11s relaying, he isn't reinjecting the frame back INTO the net80211 stack for re-encap and sequence number assignment. mesh_forward() is the function that needs to be rewritten to reinject into the normal net80211 encap path, and then the net80211 encap path needs to notice it was from the mesh layer and set the mesh layer headers again!

• Need to add the TX beamforming, SMPS status change, etc callbacks to net80211 so the driver gets notified;
• (done) Need to migrate the rest of the 11g protection (barker/preamble/etc) changes to be per-VAP and into vap notification callbacks;
• Update the channel width (80+80, 160) negotiation to the 802.11-2016 spec rather than the draft 11ac spec; the meanings of the bits changed a little in the released final spec because of implementation incompatibilities;
• Add support for PMF/MFP (management frame protection) - hardware and software encrypted ones!
• Add support for the spatial stream grouping for 11ac AP/STAs (MU-MIMO)

• BSSLOAD - implement updating it on the hostap/IBSS/mesh side
• BSSLOAD - implement updating the beacon IEs sent/stored on the IBSS/mesh/STA side so we can see BSSLOAD (and other IEs) change over time rather than whatever was seen during initial scan/association

• The new whitespace cards (eg from Xagyl) don't necessarily tune on a 1MHz boundary. They have xxx.5MHz channel frequency centres. It would be nice to “teach” net80211 and the drivers about this;
  • .. quite likely it'll involve changing ic_freq to be a structure, rather than an integer;
  • .. then going through the net80211 layer, ioctl layer and driver code, fixing the compile warnings by using an accessor macro to change ic_freq into a proper frequency value
  • .. and have it print out a warning if the caller wanted an even MHz (the default) and the channel wasn't like that
  • .. THEN change it from MHz → KHz
  • Note that chan→ic_freq isn't mapped (it's the frequency being programmed by the NIC) - so the Xagyl 420MHz card support would really just require changes to the ioctl layer; regulatory domain layer and presentation layers;
  • But for “absolutely correct” quarter rate support on the AR5212, they have xxx.5MHz channel centres, and it would be nice to be really obvious that those NICs tune to those channel frequency centres, rather than xxx.0MHz.
• There's also 60GHz support that's coming soon, so any new channel representation needs to be ready for that too

• It would be nice to kill (with fire) the half/quarter rate PHY modes and make them purely channel flags. Right now the half/quarter rate mode assumes it's an OFDM 11ag channel, with no 11b/11n rates.
  • .. the aim is to support 11n rates in 11na/11ng channels, but then have things configured to be half or quarter rate in width.
  • .. this does only make sense for HT20 as HT40 would effectively be double that (HT40 quarter = HT20 half, HT40 half = HT20) but totally incompatible (ie, HT40 wouldn't work with a normal HT20 NIC, as it's two 10MHz channels glued together.)
  • .. and since Atheros chips have analog filters that get configured separately to the HT mode, it may actually be that the analog filter gets configured in a way that makes HT40 half/quarter rate not actually work well!
  • .. In any case, it should still just be a channel flag, so we know we can enable 11n rates
• How would this work?
  • .. the PHY table for half/quarter would go away and die;
  • .. the PHY modes for half/quarter would go away and die also;
  • .. the tx time calculations would need to shift the timing by half/quarter as appropriate, with whatever increased slot time and such for half/quarter rates;
  • .. and the 11n tx time calculations would also need shifting;
  • .. the rate control code would also need to be taught about shifting duration calculations as appropriate.

• figure out how to serialise the net80211 TX path without causing LORs;
• document how to abuse the driver if_transmit for sending 802.11 fragments, then convert all the drivers over to using that;
• migrate the last remaining remnants of “there's an ifnet send queue” to not assume that - the power save code is a big, big annoying thorn in my side here.
• Add support for “sequence number assigned in driver/firmware” - then remove the net80211 TX lock for those drivers!

• Reimplement the net80211 rate control API so it takes a TX info structure and fills out a whole series of TX rate related information; as well as taking much more fine grained information about what the hardware supports.
• Support MCS rates, rather than just legacy rates
• Fix all the existing drivers and 802.11s code that just looks at ni_txrate for the “current TX rate”, as that's very race-y and makes 802.11n impossible to represent.
• Create a TX and RX rate representation for net80211 and use that instead of uint8_t/uint16_t
• There's a clash between the basic rates for non-MCS rates (which sets the high bit - 0x80 - to indicate it's a basic rate) versus MCS rates, which use a different method for indicating they're basic. Unfortunately both basic and MCS use the high bit - 0x80 - to indicate things.
• .. the pre-11n stuff uses the high bit in the various IE representations for channel rates, and this is why it's used here.
• .. the post-11n stuff uses a different method.
• So there should be a way to represent a rate that includes a set of flags rather than this hackish way, and then have a way to map it in and out of the legacy/11n channel representation and IEs.
• This is really needed for correct 11n and 11ac rate representation.
• Whilst we're at it, make it so ifconfig can tell the difference between basic rates and 11n/11ac rates; so a non-MCS rate can be configured during 11n. Right now if the VAP is in 11n mode, an ifconfig XXX ucastrate|mcastrate|mgmtrate nn will interpret nn as an MCS rate, NOT a legacy rate. This is very problematic.

• the regulatory database is indexed by SKU, rather than by country. So adding a new _country_ is actually rather annoyingly difficult.
• Change the regulatory database code to be indexed by something that isn't hard-coded, and have the “regulatory domain entry index” map _to_ an SKU where needed.
• This lets me do useful things like _update the regulatory database_..
• extend it to support new frequency ranges (60GHZ, VHF white spaces); in KHz settings rather than MHz increments;
• add VHT flags and 80/80+80/160MHz wide channel widths.

• “fix” the coverage class code to work for 2 and 5ghz modes, in full, half and quarter rate
• validate this on the AR5212 (pre-11n HAL) and AR5416 (11n) HALs
• validate interoperability

• When doing a channel width change, do a reset which doesn't drop frames _and_ forces a rate control recalculation on all frames. Otherwise you risk having flags set which the new PHY mode doesn't support.
• Add support for transmitting beacon frames as 11n frames. This includes setting up the rate scenario so the beacons go out as HT20 frames (regardless of HT20 or HT40) as well as setting the MCS rate, the antenna configuration, TX power, etc.

• test the half/quarter rate interoperability between pre-11n and 11n NICs - I've done some initial validation, but nothing too in-depth;
• add a configuration option to cover whether to configure the pre-11n quarter rate frequencies (off by 500KHz) or the 11n quarter rate frequencies (true);
• better document all of how this works.

• Many of the status fields don't apply for intermediary RX frames in an aggregate. This includes RSSI values. These should be tossed in the RSSI tracking logic.
• Unfortunately net80211 and the radiotap code will also need to be told which frames have valid RSSI and which don't, or they may use invalid RSSI for various decisions.
• Calculate frame duration as best as possible
• Extend the frame timestamp logic to mark whether the timestamp was from the beginning or end of the frame
  • .. and this is difficult for 802.11n RX aggregate frames, as you don't necessarily _receive_ all the frames!

• (done) port over the uAPSD negotiation and basic support from the old madwifi branch;
• plan and implement uAPSD support; at least hostap side;
• implement ADD-TS / DEL-TS support in net80211 for drivers that support U-APSD in firmware;
• implement delayed block-ack support;
• implement a userland tool to log RX and TX EVM for 802.11n frames, in order to assist with TX power calibration and rate control work;

• correctly limit all data transmission to one hardware TXQ, no matter what the TID;
• leverage the ibss/mesh support for 802.11n (above) to support MCS rates (non-aggregation) for TX and RX:
• leverage A-MSDU support for aggregation when doing TDMA (without ACK, obviously).
• Make sure that the TDMA code configures the WME queues in question as having NO-ACK set with them; then ensure net80211 disallows negotiating A-MPDU for an TID whose WME queue requires NO-ACK.

It would be nice to finally fix and enable TPC in general. This would be useful for more efficient spectrum use and lower power consumption.

The net80211 stack already has a per-node TX power value which can be changed on the fly. It's just ignored when passed into the ath driver and HAL.

• The AR5212 series NICs support TPC; but it needs to be tested and validated;
• .. and ensure that self-generated frames (RTS/CTS, ACK, etc) are also obeying the transmit power limits;
• The AR9280 and later NICs don't start at 0dBm, they start at -2.5dBm;
• .. and some of them have a different TX power offset; that needs to be taken into account;
• .. and the AR9285 has some quirky TX power offset adjustments based on the modulation type, and that needs to be taken into account.

Luckily the code for all of the above fudging is in the HAL; it's just used when configuring the TX power table registers for fixed TX power. This needs to be made slightly more generic and available by the TX descriptor setup code.

• implement proper hostap ps-poll support (almost there);

• when doing TDMA, ensure that chips that implement the TX “abort if it will exceed TxOP” option is enabled;