On Wed, 2007-08-15 at 18:22 -0700, Jouni Malinen wrote:
> This doesn't sound like a good idea. How would macvlan-based alternative
> solve the problem of having different group keys for each VLAN?
This is actually more complicated than it seems.
Currently, we have this code doing key selection:
if (rx->sdata->type == IEEE80211_IF_TYPE_STA)
always_sta_key = 0;
else
always_sta_key = 1;
if (rx->sta && rx->sta->key && always_sta_key) {
rx->key = rx->sta->key;
which means that we'll always use the per-sta key unless that sta
doesn't have one configured (can that happen?!). And if we do have a sta
key, then we don't handle multicast/broadcast frames correctly as I've
just confirmed in the "meaningless TKIP messages" thread.
Reading 802.11, it seems that there are basically the following keys we
need to know about at this level:
* PTKs
* GTKs
* STKs
For the purposes of mac80211, however, PTKs and STKs should be identical
as far as I can tell, they are just STA keys, used to send and receive
unicast frames to/from that STA.
Hence, the way I see it, initially key selection should simply work as
follows:
(1) if the frame is unicast and there is a key for the sending STA,
use it; it will be a PTK or STK
(2) otherwise, use the key based on the key index, in an IBSS take into
account the transmitter; the found key will be a GTK or WEP key
based on that, I don't understand what ieee80211_rx_h_load_key is doing;
is there a scenario where this selection doesn't work?
I'll try to come up with a fix first that also makes dynamic WEP work,
stay tuned.
Now, anyhow, this thread was about VLANs, so it appears that what we'll
have to do is modify the code to take into account VLAN group keys.
johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
