On Saturday 14 May 2011 11:41:02 Ignacy Gawedzki wrote: > On Sat, May 14, 2011 at 01:13:09AM +0200, thus spake Christian Lamparter: > > On Saturday 14 May 2011 00:21:41 Ignacy Gawedzki wrote: > > > On Fri, May 13, 2011 at 10:31:47PM +0200, thus spake Christian Lamparter: > > > > Note: there's a special bit [RX_MAC_CONTROL - bit 6] which instructs the key > > > > cache controller to do the "key security settings" lookup with addr2 for all > > > > bc/mc frames. If we enable this bit and modify carl9170_op_set_key to set the > > > > per station gtk correctly [i.e.: use sta->addr as MAC and put the keys into > > > > the per-sta space [0-63?]] we should be able to enable PER_STA_GTK... > > > > although the driver will be restricted to a single vif [I think]. > > > > > > If I understand correctly, by PER_STA_GTK you mean a different encryption key > > > for each one-hop neighbor. It happens to be unnecessary in my case as one > > > "ad-hoc-global" encryption key would be enough. > > yes, but AFAIK that's not how it works. There's no "global" encryption key see > > 802.11-2007 8.4.9 RSNA key management in an IBSS: > > "Each Authenticator generates its own GTK and uses either the 4-Way Handshake > > or Group Key Handshake to transfer the GTK to other STAs with whom it has > > completed a 4-Way Handshake." > > Okay, I suppose I didn't understand correctly after all. What you mean by > PER_STA_GTK is a different *decryption* key per station (one-hop neighbor), > right? The encryption key is the GTK and any receiving station supposed to be > able to decrypt the frames must have gone through the 4-way handshake with the > sending station somehow. > > In my case, it would be nice to be able to tell the driver to use the > encryption key for decryption as well and bypass the need to go through the > handshake. But I assume this is not something worth implementing if it's not > there already and not specified by the standard anyway. Oh, don't let the "RX_MAC_CONTROL" fool you, this is just Atheros' name for the register. They really say "Setting this bit instructs the Key Cache controller to send address2 of multicast/broadcast frames to be searched for user and key security settings". If it would only affect decryption, the would have written "*RxMac* Key Cache controller" instead... or Stephen, can you comment on this? [We are talking about Address: 0x1c3c40 - Bit 6] Regards, Christian -- 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
