On Tuesday 04 September 2012 18:41:16 Yeoh Chun-Yeow wrote: > Hi, Johannes > > > 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? > Yes, you are correct. Case 3 is working only accidentally not always > if the mesh node loaded with nohwcrypt=1 is reboot. So, with following > case is also not working. > > mesh1: ath5k loaded without nohwcrypt=1 (with > IEEE80211_KEY_FLAG_SW_MGMT enabled) > mesh2: ath5k loaded without nohwcrypt=1 (with > IEEE80211_KEY_FLAG_SW_MGMT enabled) > > Can we conclude that unicast data frames get processed in hardware and > robust unicast management frames get processed in software for CCMP > are not working. > > By the way, current secured mesh requires the AES CMAC to be enabled. > But without enabling IEEE80211_HW_MFP_CAPABLE, the key cannot be added > since this cipher suite is considered not supported. But actually AES > CMAC can be done in software. Any work around on this? > I think you can override this by supplying your own custom set of available ciphers. This is done by setting hw.wiphy->cipher_suites hw.wiphy->n_cipher_suites during the initalization of the driver (i.e.: before ieee80211_register_hw(hw) is called). Regards, Chr -- 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
