Release 21 * Save about 6k of RAM by consolidating some rate-ctrl storage. Backported from wave-2 ath10k-ct firmware. And provide a new way to report tx rate status that helps us better differentiate a non-report from 48Mbps (which has rate-code and flags of 0x0). This last bit requires a new driver tweak as well, but driver and firmware should be forwards and backwards compatible. * The driver can set the software retry for agg and non-agg TIDs, but the ath10k driver doesn't ever actually do this currently. Change defaults in the firmware to do zero non-agg retries (hardware will still retry 4 times it seems), and default agg-retries to 4 instead of 16. I'm not sure if the firmware actually handles the agg-retries or not, possibly that is handled by upper layers anyway. * Don't do software retry for non-local frames (ie, frame sent from the driver). This means that instead of seeing around 60 null-data probes on air when peer dies, we will instead only see 4. Similar to logic I did in wave-2 firmware recently. * Fix crash when monitor dev became the only active vdev. Backported fix from my wave-2 firmware. * Backport 'survey' logic from 10.2 to 10.1. And while doing so, fix some issues with how 10.2 tried (and failed) to clear the cycle counters when asking for pdev survey info. * Fix peer stats problem introduced way back in 2016, and also a more recent bug introduced when I did the survey patch. * Don't generate self-peer peer-stats. They do not seem worth showing. * Don't crash if retries is set to greater than 2. The rate-ctrl related logic hit an assert due to code that assumes there cannot be more than 2 retries. Stock drivers cannot set retry count, so this bug would not normally be seen in the wild (though it was at least once before based on an old bug report, perhaps due to rts/cts or something like that?) * Support limited vdev stats, return tsf64 value as requested by a user. * Support CT-STA mode. This is similar to proxy-sta logic, but allows hw-crypt when we have multiple station vdevs connected to the same AP. This feature is only useful for wifi testing scenarios, and is only in the non-commercial (without a license from Candela Technologies) builds. A likely limitation is that stations on a radio cannot connect to more than 2 different APs. And, this needs lots of testing. * Backport PMF support from 10.2, especially for block-ack. This has been tested in hw-crypt mode with htt-mgt. Block-ack does not work in sw-rx-crypt mode with 802.11w/PMF. Release 20 (April 11, 2018) * Allow flushing peer when deleting. Hopefully this will allow the peer delete command to happen in a reasonable amount of time even if the RF environment is busy (or peer has died). To enable this, set the high flag in the mac-addr second word in the ath10k driver near end of the ath10k_wmi_op_gen_peer_delete method: cmd->peer_macaddr.word1 |= __cpu_to_le32(0x80000000); * Attempt to fix crash seen in resmgr-ocs, appearantly due to list corruption. Use a temporary list instead of trying to rely on for-each-safe. * Add flag to tx-descriptor to allow driver to request no-ack on data frames. This is bit 15 on the flag1 field (previously un-used). * Add option to support specifying the tx-rate-code and retry count on a per-packet basis. Only a single series is supported at this time. Useful mainly for radiotap monitor-tx type testing at this point. * Fix crash on startup when chip is at -40 deg C and calibration fails. Instead of asserting, just keep retrying calibration, which appears to start working after a few minutes (when the chip warms up). * Allow reporting per-chain rssi for management frames. We pack the values into empty space in the mgt-frame wmi header. This will only be enabled if the driver requests it, since otherwise the driver is assumed to not understand the new API. ath10k-ct drivers that support this feature will automatically enable it. * A customer reports a case that appears to be the hardware not properly detecting end of AMPDU, so frames were being mis-delivered to the wrong peer. Attempt to work around this, and in doing so, clean up a bunch of void* abuse in the block-ack reordering code (could not ever confirm there was a problem in this area). * Re-work the rx-mem logic to be less complicated and to use less memory. * Attempt to fix crash that appearanty happens because the driver can sometimes delete a vdev in 'up' state. * Attempt to fix hung scan state machine issues. * Fix crash in tx path due to un-initialized memory. * Fix ptk-rekey bug in EAP-PEAP (at least). End result of the bug is that pkts sent were 16 bytes shorter than they should have been, which of course makes them broken. Thanks to the person who took the time to narrow down and report this bug! Release 19 (Sept 1, 2017) * Support IBSS + RSN. This has been tested on openwrt. It works reliably when supplicant defines the bssid, otherwise, it is flakey. I do not think this is a firmware issue. * Ensure we do not try to TX STBC when configured with NSS=1. This fixes an inability to transmit when 9887 station is connected to an AP that is using STBC. * Ensure we do not advertise TX-STBC feature if compiled for NSS=1 (like 9887). * Fix un-initialized variable that caused block-ack to fail in some cases, specifically tx frames of (only) 512 bytes would reproduce the problem. * Fix passing wrong object to some WDS methods. Might fix some errors some have reported with WDS in CT firmware. Fix similar problem related to multicast, but the driver doesn't actually use that currently. * Fix channel reservation logic. This has been broken for a long time in CT firmware, at least when using multiple station vdevs. Somehow, it mostly worked before, but the bug became appearant lately in 10.4 firmware. The fix was backported to 10.1 because it appears to have the same logic problem even though we never noticed this problem before. Possibly it didn't happen, or possibly we never found a way to reliably cause the issue and didn't realize it existed. * Support reading temperature through WMI. This is back-port of 10.2 firmware feature. Requires modified ath10k driver to utilize. * Support SET_SPECIAL_ID_BW_DISABLE_MASK to allow disabling certain bandwidths. This can help with regulatory testing. Examples (NOTE, your /debug fs is probably mounted at /sys/kernel/debug): # Configure for 20Mhz only (disable 80, 40: echo 0xE00000006 > /debug/ieee80211/wiphy1/ath10k/ct_special # Configure for 40Mhz only (disable 80, 20) echo 0xE00000005 > /debug/ieee80211/wiphy1/ath10k/ct_special # Configure for 80Mhz only (disable 40, 20) echo 0xE00000003 > /debug/ieee80211/wiphy1/ath10k/ct_special # Set for vht-rateset, MCS 0, NSS 3: iw dev vap0 set bitrates legacy-5 ht-mcs-5 vht-mcs-5 1:3 # Set for ht-rateset, MCS 0, nss 1: iw dev vap0 set bitrates legacy-5 ht-mcs-5 0 vht-mcs-5 Release 18 * Ensure that frame-type is correct for HTT-MGT frames. Previously this logic was ignored. I am not sure exactly what issue this might have caused, it at least mostly worked previously. * Disable vlan-tx-strip flag. It is not configurable currently, and was hard-coded to true. This broke sending 802.1q vlan packets it seems. Set this flag to zero to fix vlans. * Fix scanning issue, radio would go deaf to scan responses due to inverted logic trying to work around freeing vdev while scanning. This is a long-standing bug introduced long ago in CT firmware, so I guess it must work most of the time or we would have seen it sooner. * Backport much of the 10.2 firmware features from upstream QCA driver. This includes ANI support, adaptive CCA, tx-hang workarounds, and lots of other things. Not all of this may be enabled at this point, and more code waits to be backported as time and motivation allows. * Fix some rate-control issues where ath10k in station mode (at least), would sometimes get stuck at low rates. This appeared to be a probe related state machine issue in the firmware, so I added some timeout logic to kick the state machine if it gets stuck. This signicantly improves throughput tests with many stations. * Allow compiling for 9887 chipset (and user reports it works OK). Release 17 * Support configuring WMI WD timeout using SET_SPECIAL API. * Fix htt-tx for 4.5 and higher kernels. Problem was that mgt tid and non-pause tids were being converted to non-qos tid, which means that mgt frames were going onto the air with 10 bytes of junk on the end. This same bug might have make APs using this firmware not be able to associate with /a/b/g stations as well, but not certain of that. * Properly configure the rx-mask on bootup to work around problem found by Mr. Kazior. This should remove the need to add the driver hack he posted. * Allow configuring pdev failed-retry threshold. This is how many consecutive tx failures the firmware will allow before resetting the wifi chip (not a full firmware crash). * Allow enabling baseband RIFS support. Customer thinks this might help with capturing certain packets in monitor mode. Needs testing. * Back-out previous 10.2 backport patches. Important ones were added in the 16.1 release, and the sum total of the other patches caused instability. Not sure exactly where, might try to apply them again one day. Release 16.1 * Remove verbose debugging spam about cache fetch failures (which are not actually real problems in practice). * Add debug to maybe track down HTC hang related crash. * Backport CCMP IV (PN) changes from 10.2. Hopefully this will fix the stall reported with Apple products. The bug appears to be in how 10.1 firmware was setting the PN high-bits when non-zero TIDs were used. To reproduce this bug, Macbook needs to be receiving traffic on TID 0 and then some TID 3 traffic should be send to Macbook. It may be slightly more tricky than this since I could not reproduce the issue locally. AP must be using AES (WPA2) encryption to hit this bug. * Allow power-save transition based on probe, auth, assoc requests. This lets Mac book properly re-associate after it goes to sleep for a short time. This issue was only seen when using htt-mgt firmware variants. The wmi-mgt evidently sends probe requests and other mgt frames without paying attention to the peer's power-save state. Further investigation showed similar symptom with wmi-mgt variants on at least one embedded platform, so the bug was probably not just with CT's htt-mgt variant. * When using HTT-MGT firmware, ensure MGT frames are always sent on the NONPAUSE TID instead of the MGT TID. Makes me wonder if MGT TID is worth anything at all, but this seems to fix lingering issues with Mac sleeping and power-save. Release 16 * Auto-calculate the 'base' MAC address. This lets us create vdevs with a MAC address range differing from the 'real' MAC of the radio and still keep a tight BSSID-Filter mask. * Add 'special' hack to disable 20, 40, and/or 80Mhz bandwidths when transmitting. This only applies to STATION vdevs, and is implemented to attempt to work around a tx-hang when AP + STA is used concurrently on one radio. # Disable HT40, HT80 echo 0x800000001 > /debug/ieee80211/wiphy0/ath10k/ct_special # Disable HT80 echo 0x800000003 > /debug/ieee80211/wiphy0/ath10k/ct_special # Enable all bandwidths. echo 0x800000000 > /debug/ieee80211/wiphy0/ath10k/ct_special * Decrease tx-completion time from 2ms to 1ms. This might work better with tx descriptor pacing in recent kernels. * Fix crash when firmware beacon-miss was enabled (diet builds do not compile in beacon-miss code at all, by the way.) * Update base-band to fix iqcal hang on 2.4Ghz band. This might fix cases where the NIC appears to go deaf after a while. * Disable 'congestion-bins' logic in the firmware. This effectively caused the firmware to not be able to use all of it's tx descriptors, and would thus not allow back-pressure to propagate properly to the driver. Due to effectively providing more tx buffers, this might increase latency. The host might therefore want to request fewer TX buffers. * Attempt to fix crash due to running out of stateless TID objects in a test with 64 stations: Allocate more stateless TIDS, and drop frames for which we do not have TIDs instead of indirectly causing an assert. * NOTE: See next item down. Increase rate-ctrl cache from 8 to 32. CT firmware has enough RAM savings due to coding efficiences that we can allocate more rate-control objects in RAM. In constant peer load scenarios (32 peers downloading all at once), the firmware is not able to fetch the rate-ctrl objects often enough to update rate-ctrl, and so performance drops from around 600Mbps aggregate throughput down to around 50Mbps. Long term, it would be nice to have all of this in RAM or not need it at all by using host-based rate-ctrl. But for now, at least setting this to 32 lets AP mode perform well up to 32 stations. A bit more coding work could allow this to be configurable on the host so a user could choose to use less RAM for vdevs and/or peers and more for rate-ctrl cache objects. * Even with 32 rate-ctrl objects, tests started performing well right after we go past 32 peers. So, I re-wrote a bit of the rate-ctrl logic to make it deal better with out-of-ram rate-ctrl cache objects. This uses some temporary storage, which eats a fair bit of RAM, so now the number of rate-ctrl objects should be 16 instead of 32. In addition, I am also now compiling a firmware variant that has no rate-ctrl caching (nrcc) at all. This appears to scale well up to 100 plus peers. This option should be good for most users (8 vdevs, 128 peers, etc), but it uses too much RAM to be used by users wanting 64 vdevs. Please see these reports for how this new firmware performs. For these tests, AP uses the ngcc firmware variant, and Station is using the new rate-ctrl caching firmware with 15 in-ram cache: Station upload test: http://www.candelatech.com/examples/script-report-udp-ul-new-ratectrl-logic/ AP (download) test: http://www.candelatech.com/examples/script-report-AP-udp-dl-nrcc/ In addition, this 10.1 firmware outperforms in almost all ways the stock 10.2.4.70 firmware, as well as CT 10.2 firmware. * Back-port some AXI/CE crash/hang work-arounds from 10.2 firmware. Might fix some of the more mysterious crashes. * The firmware tries to cache rate-ctrl objects in the host (driver) memory. But, with lots of active stations, this appears to cause constant cache swapping and in the end, rate-ctrl fails to work well at all. CT Firmware has lots of RAM savings, especially when using fewer than 64 vdevs, so allow users to configure more than the default (currently 32) of in-ram rate-ctrl objects. As long as firmware RAM is available, allocating as many rate-ctrl objects as possible (up to number of peers) is probably a good idea. This setting should be harmless in all CT firmware, but it will only have an effect in beta-16 firmware and later. Setting value to 0 means use firmware defaults. This requires a kernel patch to enable the feature, see this for an example (or search for ath10k_modparam_target_num_rate_ctrl_objs_ct in CT kernels): http://dmz2.candelatech.com/?p=linux-4.2.dev.y/.git;a=commitdiff;h=6654f7b8315113c699dfb22d6e3bfd0a51a29985 * Add 'no-beacon-miss-ct' feature flag for 'diet' builds. This lets the host know that beacon-miss is not enabled so it can let mac80211 handle the beacon miss. * When a user used a scan request that needed more than 5 buffers (many ssids, for instance) the scan logic ran out of local mgt buffers and then just failed to send more frames. Instead, use it's (now fixed) delay-time logic to wait a bit and send the rest of the frames 5ms or so later. Release 15 * Enable Management-over-HTT firmware variants. These are *NOT* compatible with stock drivers. You must use this patch or something similar for the 'htt-mgt' firmware to work. In general, CT firmware HTT-MGT frames should be sent on the MANAGEMENT TID, and should be sent as 'NATIVE-WIFI' type. http://dmz2.candelatech.com/git/gitweb.cgi?p=linux-4.0.dev.y/.git;a=commitdiff;h=56d57560d68da5d9a5ec266c0d9bc6f2ad8a2f44;hp=abd3ee5c4d297e56b854864624152f5704c5df20 Expected benefit is better handling of stations with buggy power-save, and better handling of stations that go out of range while in power-save mode. * Enable transmit on Monitor interfaces. Currently, the rate is fixed at 1Mbps and destination MAC addresses are at least mostly ignored (and fixed to that of the monitor device itself). * Allow monitor mode to receive 'Association Request', block-ack action frames, nodata frames, TYPE-CTL frames. Previously, these were not delivered to the WMI interface, and the kernel driver is configured to drop mgmt frames in the normal RX htt datapath, so host never saw them. This makes sniffing with ath10k a lot more useful. When no monitor devices are active, the firmware reverts to the previous behaviour. I guess the idea is that this is an optimization and keeps some un-needed frames off the host. * Enable setting noise-floor-threshold and min-cca-power. If set, this will over ride the defaults, including eeprom (though firmware ignores these settings in the eeprom anyway.) Don't mess with this unless you understand the consequences. But, if set properly, noise-floor-threshold tweaking may fix ETSI CCA adapatibility test failures. * Allow setting arbitrary rate-mask. This allows the user to disable all but /b legacy rates, for instance. It should also allow configuring subsets of all other HT and VHT rates, but that has not yet been tested. In addition, fix several bugs that caused the firmware to ignore tx-rate-ctrl settings because it did not properly fetch the cached RAM from the host OS. To enable these features, you need to be using the CT kernel patches (currently only in 4.0, but will at least be ported forward to 4.2 sometime soon. Might not be ported to 3.17 or other older kernels.) * Allow disabling firmware-added legacy, HT and VHT related IEs in probe requests. The host can do a better job of adding these, and this keeps there from being duplicated IEs in probe requests. Requires kernel patch to take advantage of these new features. * IBSS: Allow enabling A-MSDU for IBSS. It appears there is a bug in the hardware or firmware that causes the BSSID to be zero when diong A-MSDU frames for IBSS interfaces. I cannot figure out how to fix that, and it may just not be fixable due to hardware issues. But, the receiving host could be configured (hacked?) to just match on the destination address and ignore the BSSID address, and then it appears to work just fine. CT Kernel (4.2 now, maybe 4.0 soon) has patches to allow enabling IBSS A-MSDU in the CT firmware. By default, A-MSDU is (still) disabled for IBSS. # Enable A-MSDU IBSS on wiphy0 radio. echo 0x500000001 > /debug/ieee80211/wiphy0/ath10k/ct_special # Disable A-MSDU IBSS on wiphy0 radio. echo 0x500000000 > /debug/ieee80211/wiphy0/ath10k/ct_special * Ensure that off-channel packets sent on 5Ghz band do not use CCK encoding rates (which are only valid on 2.4Ghz band). This fixes at least one problem with ANQP queries to APs on the 5Ghz band. * vdev-up logic was resetting the mcast/bcast and non-data rate-ctrl codes to default values. This over-rode any settings that the driver may have previously set, breaking the driver's ability to properly specify rates. So, a check has been added so that if the driver has set the mcast rate before the vdev-up command happens, then the mcast, bcast, and non-date rate control settings are not modified. It is assumed that if the driver is setting mcast rate, then it is also setting the rest. The Candela kernel driver patches do this at least. In additiona, add the off-channel fixup logic for mcast/bcast frames as well, just in case those can be sent as off-channel frames. * Allow setting a global maximum tx-power. This is to allow a user to be as sure as possible that the hardware will never transmit above thsi power level. See CT kernels for a patch that enables setting this value: http://dmz2.candelatech.com/?p=linux-3.17.dev.y/.git;a=commitdiff;h=fd488b42eb008c27e4dba07c5df615b95235d8e0 * Allow tuning the g_rc_rate_max_per_thr value. This rate-ctrl tunable defaults to 50, and some reports indicate that setting this to a higher value (70, for instance), may make performance better in a crouded RF environment. * More rate-ctrl cleanup, fix some border cases when setting subsets of alowed rates, save lots of firmware RAM by cleaning up un-used struct members. * Remove EAPOL M1, M4 snooping. This logic attempted to stop any DATA frames from being transmitted until the M4 was successfully sent (for STA, IBSS), and until the M1 had been sent for AP mode. This was breaking 802.11r roaming because the 4-way is only done at the initial connection, not on subsequent roams. If the host/driver allows data frames before encryption keys are set, then possibly this opens up a race where un-encrypted frames could hit the air. Linux, at least, will not send in-appropriate send frames to an un-authorized peer, so my change should be safe on Linux. Possibly other OS's might have issues. * Compile out some tx-descriptor debugging in the hot path. I have never seen this code find any bugs, so I'm assuming it is not needed. Release 14 * Fix crash related to a race where packet was (re)sent to a peer that had been deleted. The crash was in the rate-ctrl logic, and was seen when an Apple MAC laptop with bcom AC NIC did a network discovery while connected to ath10k AP and while running iperf. The ath10k AP disconnects the MAC in this case, which can trigger the firmware bug. Possibly, a better solution is to force a flush of the peer's tx queue when deleting a peer. A note has been made to revisit this in the future. * Allow over-riding thresh62_ext and some ack-timing registers. thresh62_ext has been tested, the others have not at this time. * Fix beacon concurrency issues: The firmware did not properly go in an 'rx-all-beacons' mode when more than 2 station vdevs were created. This left the third receiving no beacons if connected to a different AP from the others. * Fix TID mapping: When host requests one of the special TIDS, such as HTT_DATA_TX_EXT_TID_NON_QOS_MCAST_BCAST, then the firmware should NOT attempt to re-map this to AC/TID. Instead, pass it unchanged into the lower code. This lets null-func packets go out as truly non-qos frames instead of turning them into QoS best-effort frames and then letting block-ack work (or not, or at least not fast enough, in my testing). May require host patch to set the TID to HTT_DATA_TX_EXT_TID_NON_QOS_MCAST_BCAST as needed to make good use of this firmware. This change only affects station mode. * Fix HTT-TX status indication. Old code mostly just returned SUCCESS for everything. Now, we get proper NO-ACK and DISCARD values as well. This allows stations to properly dis-associate if the AP dies (when this firmware is used in station mode). It may improve other areas as well. * Return temperature in second octet of the OPMODE 'register' when dumping target registers, for instance: SW-OPMODE 0x00006d01 * Fix ANQP queries to APs with which the station is not currently connected. The station will now use the bss-peer if actual peer is unknown. This changes some behaviour for how mgt frames to unknown peers is handled. This appears good for ANQP/GAS, but possibly there are other test cases where the old logic was needed? * Some work to allow tx on monitor ports. Does not actually get pkts on the air for some reason, maybe due to requiring a peer for each destination like ath10k does for off-channel work? * Make tx-power take the NSS at which each rate transmits into account. This effectively gives +5db to NSS1 rates and +3db to NSS2 rates as compared to the original code. * Support setting mgmt tx rate. With patch to ath10k driver, this allows the user to specify broadcast, multicast, management and normal unicast traffic rates independenly. Setting rates in ath10k requires a recent 'iw'. For instance to set just the beacon rate to fixed speed: echo beacon > /debug/ieee80211/wiphy1/ath10k/set_rates ./local/sbin/iw dev vap1 set bitrates legacy-2.4 6 ht-mcs-2.4 For full list of available options: cat /debug/ieee80211/wiphy1/ath10k/set_rates * Add extra debug for assert in CE engine logic. * Re-work various bits of code to make it more compact to save precious IRAM. Should be no functional change in this sort of thing, but it gives me room for additional useful code. * Return tx-completion status so that we can report xmit-failed (no-ack) errors up the stack. Adds new feature flag (30) and requires kernel patch to use it. * Enable IBSS + RSN. Requires kernel patches found in CT 4.0 kernel tree, latest supplicant, etc. Upstream WEP patch is probably needed for IBSS + WEP (not tested). Things are still a bit flakey on startup, but I think this may be wpa_supplicant issue. Tested against ath9k peer. See known-bugs section below. NOTE: I had to pad pkt length by +16 for IBSS + RSN frames. I am not sure why this is needed. Possibly either firmware or driver will need additional, similar hacks for IBSS + WEP. * Fix IBSS blockack support. There was some mis-ported code that was breaking IBSS-BSSID, which in turn breaks ability to properly send or process blockack action frames. In addition, I see only about 13Mbps throughput when amsdu is enabled, but if I disable that, then it runs much faster. So, disable amsdu in blockack code for IBSS interfaces. I do not understand why this problem is seen. Known Bugs: * Cannot get ath10k to ath10k IBSS + RSN to work. ath9k <-> ath10k RSN or Open works ath10k <-> ath10k Open works. I see 4-way complete, but then no other frames are seen on the air except for beacons. * Monitor mode may not capture high-speed frames properly (when amsdus exist?) * Monitor mode will not capture Action frames (blockack req/response, for instance)