wifi:todostuff

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision		 Previous revision
wifi:todostuff [2020/07/05 20:46] – AdrianChaddwifi:todostuff [2021/06/06 02:46] (current) – add CategoryWiFi MarkLinimon
Line 1: Line 1:
-====== Random Wifi (net80211, driver) wishlist ======+====== Wifi (net80211, driver) wishlist ======
  
-===== 802.11n bits =====+===== net80211 =====
  
-  * channel width change (see below)+==== Global state ==== 
 + 
 +  * 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. 
 + 
 +==== Encryption ==== 
 + 
 +  * 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 
 + 
 +==== IBSS ==== 
 + 
 +  * (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! 
 + 
 +==== 802.11n ==== 
 + 
 +  * 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   * 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   * 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
Line 10: Line 31:
   * .. 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.   * .. 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.
  
-===== 802.11ac bits =====+==== 802.11s (mesh) ==== 
 + 
 +  * 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! 
 + 
 +==== 802.11ac ====
  
-  * Need CCMP-256 key support; 
-  * Need GCMP-256 key support; 
   * Need to add the TX beamforming, SMPS status change, etc callbacks to net80211 so the driver gets notified;   * Need to add the TX beamforming, SMPS status change, etc callbacks to net80211 so the driver gets notified;
-  * (adrian - in progress) Need to migrate the rest of the 11g protection (barker/preamble/etc) changes to be per-VAP and into vap notification callbacks;+  * (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;   * 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 PMF/MFP (management frame protection) - hardware and software encrypted ones!
-  * Add support for the spatial stream grouping for 11ac AP/STAs+  * Add support for the spatial stream grouping for 11ac AP/STAs (MU-MIMO)
  
-%%=%%= Interesting IE's to add (as mini projects)+==== Interesting IE's to add (as mini projects) ====
  
-  * BSSLOAD+  * 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
  
-===== net80211 channel configuration =====+==== net80211 channel configuration ====
  
   * 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;   * 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;
Line 47: Line 73:
     * .. the rate control code would also need to be taught about shifting duration calculations as appropriate.     * .. the rate control code would also need to be taught about shifting duration calculations as appropriate.
  
-===== net80211 TX datapath =====+==== net80211 TX datapath ====
  
   * figure out how to serialise the net80211 TX path without causing LORs;   * 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;   * 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.   * 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!
  
-===== net80211 rate control and rate representation =====+==== net80211 rate control and rate representation ====
  
   * 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.   * 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.
Line 66: Line 93:
   * 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.   * 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.
  
-===== net80211 802.11n support ===== +==== net80211 regulatory ====
- +
-  * 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. +
- +
-===== net80211 regulatory =====+
  
   * the regulatory database is indexed by SKU, rather than by country. So adding a new _country_ is actually rather annoyingly difficult.   * the regulatory database is indexed by SKU, rather than by country. So adding a new _country_ is actually rather annoyingly difficult.
Line 78: Line 101:
   * add VHT flags and 80/80+80/160MHz wide channel widths.   * add VHT flags and 80/80+80/160MHz wide channel widths.
  
-===== long distance links (ath, but any drivers that support it) =====+===== ath(4) changes ===== 
 + 
 +==== long distance links (ath, but any drivers that support it) ====
  
   * "fix" the coverage class code to work for 2 and 5ghz modes, in full, half and quarter rate   * "fix" the coverage class code to work for 2 and 5ghz modes, in full, half and quarter rate
Line 84: Line 109:
   * validate interoperability   * validate interoperability
  
-===== ath(4) 802.11n support =====+==== ath(4) 802.11n support ====
  
   * 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.   * 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.   * 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.
  
-===== ath(4) half/quarter rate =====+==== ath(4) half/quarter rate ====
  
   * test the half/quarter rate interoperability between pre-11n and 11n NICs - I've done some initial validation, but nothing too in-depth;   * test the half/quarter rate interoperability between pre-11n and 11n NICs - I've done some initial validation, but nothing too in-depth;
Line 95: Line 120:
   * better document all of how this works.   * better document all of how this works.
  
-===== ath(4) RX path / radiotap support =====+==== ath(4) RX path / radiotap support ====
  
   * 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.   * 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.
Line 103: Line 128:
     * .. and this is difficult for 802.11n RX aggregate frames, as you don't necessarily _receive_ all the frames!     * .. and this is difficult for 802.11n RX aggregate frames, as you don't necessarily _receive_ all the frames!
  
-===== 802.11s ===== +==== 802.11n ====
- +
-  * test half/quarter rate +
-  * 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! +
- +
-===== 802.11n =====+
  
   * (done) port over the uAPSD negotiation and basic support from the old madwifi branch;   * (done) port over the uAPSD negotiation and basic support from the old madwifi branch;
   * plan and implement uAPSD support; at least hostap side;   * 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 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;   * 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;
- 
-===== IBSS ===== 
- 
-  * (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); 
  
 ===== TDMA ===== ===== TDMA =====
Line 152: Line 166:
  
   * when doing TDMA, ensure that chips that implement the TX "abort if it will exceed %%TxOP%%" option is enabled;   * when doing TDMA, ensure that chips that implement the TX "abort if it will exceed %%TxOP%%" option is enabled;
 +
 +----
 +
 +{{tag>WiFi}}
  
  • wifi/todostuff.1593982012.txt.gz
  • Last modified: 2020/07/05 20:46
  • by AdrianChadd