On Tue, Sep 04, 2012 at 05:28:40PM +0800, Yeoh Chun-Yeow wrote: > Hi, Johannes > > > _How_ did you test this? Did you test that management frames are > > properly encrypted using AES CCM, and not mangled when decrypted? > > I have setup the two mesh nodes using the secured mesh with the > following key installation: > > /* key to encrypt/decrypt unicast data AND mgmt traffic to/from this peer */ > install_key(&nlcfg, peer, CIPHER_CCMP, NL80211_KEYTYPE_PAIRWISE, 0, mtk); > > I confirm that the hardware key for CCMP is set and > IEEE80211_KEY_FLAG_SW_MGMT is not enabled in mac80211-ops.c. Both > nodes are able to ping each others. Is this enough? Depends on what those nodes were.. If they were both using the same ath5k implementation, then no, that would not be enough. If the CCMP processing is done incorrectly, they could both mangle the results in the same way to hide the issue. It should also be noted that there has been key cache changes between hardware revisions, so working with AR2414 or even AR5213 does not necessarily mean that this would work with AR5210, AR5211, or AR5212. You would need to test an ath5k-based device with another device that is known to handle unicast robust management frame protection correctly. If you do not have a suitable other device for this, it should be possible to force one of the devices to use software encryption for everything (i.e., make sure it does not configure any CCMP keys in the hardware key cache) and then run a test that exchanges robust unicast management frames (both TX and RX using the modified ath5k driver). I would also verify that unicast data frames get processed in hardware and robust management frames in software. -- Jouni Malinen PGP id EFC895FA -- 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
