Hi, > > 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. I'm sure robust management frames in software *are* working, but obviously the KEY_FLAG_SW_MGMT only affects transmit, not receive, so receiving may still be broken. > 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? Well, that's a separate question. Of course we could enable it, but what would the point be? You don't have CCM for management frames right now, so CMAC is pretty useless? And if you had CCM for management frames, say with the things discussed in the p54 thread, then you could just enable both, right? johannes -- 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
