On Wed, Mar 13, 2019 at 03:41:50PM +0100, Tom Psyborg wrote: > >> > It's just matter of sending already encrypted frames. All chipsets > >> > handle that. > >> > > >> > Stanislaw > >> > > >> > >> The question is how well all chipsets handle that. I've seen some lags > >> too with MFP enabled connection. While being about 40-50% lower, > >> throughput would still occasionally drop to very low values, like > >> 800Kbps. > > > > The only reason I can image that might have impact on throughput > > in this case is limited CPU power since encryption is done in > > software. Would be good to compare with PA2 with nohwcrypte, if > > there are similar lags. However MFP can require more CPU power. > > > > Stanislaw > > > > nohwcrypt=y mfp=require: there was no throughput drop, no lag, > measured about 80-85Mbps but the connection frozen after a minute or > two. might be related to rekeying. > > CPU power cannot be the problem since I run it on laptop (2x2.20GHz) It can be CPU power on AP, ath10k and ath9k also use software encryption for MFP. > hwcrypt enabled results are low, some lag but connection remained stable: There should be no difference between enabling MFP with nohwcrypt and without nohwcrypt, we will just return -EOPNOTSUPP at different point from rt2x00mac_set_key: if (!rt2x00_has_cap_hw_crypto(rt2x00dev)) return -EOPNOTSUPP; <snip> crypto.bssidx = rt2x00lib_get_bssidx(rt2x00dev, vif); crypto.cipher = rt2x00crypto_key_to_cipher(key); if (crypto.cipher == CIPHER_NONE) return -EOPNOTSUPP; However there are some few others points in the code where we check rt2x00_has_cap_hw_crypto() as well, but all should work the same when we report to mac80211 that the cipher is not supported. Stanislaw