On Tue, 2012-09-04 at 19:25 +0800, Yeoh Chun-Yeow wrote: > Hi, Jouni > > I have retested with the following: > > case 1 with submitted patch: > mesh1: ath5k nohwcrypt=1 > mesh2: ath5k (no IEEE80211_KEY_FLAG_SW_MGMT) > Result: Both of them are not able to ping each other. Also, the PREP > action frame is not able to decrypted by another node. > > case 2 with submitted patch: > mesh1: ath5k nohwcrypt=1 > mesh2: ath5k nohwcrypt=1 > Result: They are able to ping each other. > > case 3 with submitted patch but enable IEEE80211_KEY_FLAG_SW_MGMT: > mesh1: ath5k nohwcrypt=1 > mesh2: ath5k (with IEEE80211_KEY_FLAG_SW_MGMT) > Result: They are able to ping each other > > case 4 with submitted patch but enable IEEE80211_KEY_FLAG_SW_MGMT: > mesh1: ath5k (with IEEE80211_KEY_FLAG_SW_MGMT) > mesh2: ath5k (with IEEE80211_KEY_FLAG_SW_MGMT) > Result: Both of them are not able to ping each other. Also, the PREP > action frame is not able to decrypted by another node. > > So can we conclude that hardware encryption is not working for both > robust unicast management frame and also unicast > data frame? I am confuse why on case 4, it is not working?
I would guess that hardware *decryption* is faulty, maybe only one action frame needs to be correct and so if one of them is nohwcrypt=1 it still works? johannes _______________________________________________ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
