On Wed, 2008-03-12 at 17:05 -0700, Reinette Chatre wrote:
> From: Emmanuel Grumbach <emmanuel.grumbach@xxxxxxxxx>
>
> This patch makes mac80211 able to send a phase1 key for TKIP decryption.
> This is needed for drivers that don't do the rekeying by themselves
> (i.e. iwlwifi). Upon IV16 wrap around, the packet is decrypted in SW, if
> decryption is ok, mac80211 calls to set_key with a new phase 1 RX key.
> --- a/include/net/mac80211.h
> +++ b/include/net/mac80211.h
> @@ -590,12 +590,20 @@ enum ieee80211_key_alg {
> * @IEEE80211_KEY_FLAG_TKIP_REQ_TX_P2_KEY: This flag should be set by
> * the driver for a TKIP key if it requires a phase2 TX key generation
> * in SW. The key will be attached to each packet.
> + * @IEEE80211_KEY_FLAG_TKIP_REQ_RX_P1_KEY: This flag should be set by the driver
> + * for a TKIP key if it requires phase 1 key generation in software.
> + * The phase 1 key will be sent in the same context as Rx.
> + * @IEEE80211_KEY_FLAG_TKIP_PHASE1_VALID: Set by mac80211, valid only when
> + * IEEE80211_KEY_FLAG_TKIP_REQ_RX_P1_KEY was set. When set, the phase 1
> + * fields (tkip_p1k and tkip_iv32) in ieee80211_key_conf are valid.
This really breaks the set_key() model of having always one set_key()
call to add the key and another one to remove it again.
I think it would be much more appropriate to handle this in the driver
by exporting an appropriate phase1 mixing function that takes the
key_conf, iv16, RX vs. TX flag, and for RX the queue number as
arguments. The RX vs. TX flag could be used by the b43 driver since that
hardware can actually derive the phase2 key by itself.
I think for advanced features like crypto hardware acceleration or
similar we should deviate from the "push" model mac80211 has for most
things (and which you also implemented here) so we don't end up creating
special flags for all possible different hardware. A "pull" model is
much more scalable here.
johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
