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
_______________________________________________
ath5k-devel mailing list
ath5k-devel@lists.ath5k.org
https://lists.ath5k.org/mailman/listinfo/ath5k-devel
