> On 2012-08-09 11:21 PM, Luis R. Rodriguez wrote: >> On Thu, Aug 9, 2012 at 2:07 PM, Pavel Roskin <proski@xxxxxxx> wrote: >>> On Thu, 9 Aug 2012 11:10:38 -0700 >>> "Luis R. Rodriguez" <rodrigue@xxxxxxxxxxxxxxxx> wrote: >>> >>>> And this would lead to .. what? How did you realize this? Can you >>>> please resend and add all this information to the commit log message? >>> >>> Also please use a better subject. For example: >>> >>> ath9k: fix decrypt_error initialization in ath_rx_tasklet() >>> >>> "issue" is too vague. >> >> Also -- what I was getting at is to evaluate whether or not this is an >> important fix or critical. To determine if its critical it helps to >> understand exactly what negative behavior was observed. If its >> critical it can go to stable but I have a feeling this is not >> critical. If its not critical and only important although it won't go >> to stable I'll still cherry pick it for the stable compat-wireless >> releases. > I think it's critical enough for stable. I think when using CCMP > encryption, high CPU load can get the connection stuck (because of CCMP > PN corruption when the issue occurs). > > - Felix > I was using a two hop network encrypted with AES CCMP. STA <---f0---> Node A <---f0---> Node B f0=2412GHz Node A and node B were running latest OpenWRT trunk, AR9280 chipset. I was injecting 30Mbps of UDP iperf traffic from STA to Node B. I was facing a connection stuck issue on Node B side because it reports a lot of decrypt errors and since decrypt_error flag sets to true, it tries to decrypt an already decrypted frame with ieee80211_aes_ccm_decrypt. Setting decrypt_error to false at beginning of ath_rx_tasklet cycle the connection is definitely more stable avoiding waste of CPU time. Regards Lorenzo -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
