On Mon, Mar 17, 2008 at 3:13 PM, Johannes Berg<johannes@xxxxxxxxxxxxxxxx> wrote:>> > > Good point. But let's not overload set_key() for it this way. This way,> > > the driver needs to look up the key etc. and the semantics get quite> > > mangled up. Also, your approach doesn't work for Broadcom hardware that> > > only needs phase 1 keys for both RX and TX.> >> > Can you elaborate why it doesn't cover bcom case?>> I don't quite understand the phase 1 key derivation and why it is done> for each DMA queue,This is only in RX side. Each AC (access category) queue transmit init's own rate. For example VO trasmitts more packets then BE. So youmight get into case in receive site that VO packets are already onwraparound side while BE are still using 'old' phase1.Best remedy is to keep phase1 per each AC.
but I think this is not too important as> non-matching will just be done in software.
Correct, this should happen only for short period of time that ph1doesn't match for each AC queue.
However, bcom firmware wants> to have just the phase 1 key, and as far as I can tell the driver can't,> even with your patches, obtain a phase 1 key for TX.
Not sure these cases are symmetric. You have to have phase1 ready inHW before you transmit the packetPhase1 need to be adhered to a packet that causes wraparound unlike RXthat you can fall back to SW decryptionIn TX there is no way back.
>> > > How about instead we add a new "update_tkip_key()" callback that takes> > > exactly the required parameters? It should also give the> > > hardware-key-index so that the driver has less work to do.> >> > It's viable but I actually prefer not opening too many interfaces.> > Please give me some more detailed sketch how do you see that and we> > sure get to some acceptable solution.>> Yes, I would prefer not having that many interfaces as well, but I don't> think shoehorning it into the set_key() callback is a good idea because> (a) you add fields to the key conf structure that are only used for> the tkip stuff and only valid in some calls> (b) the patch breaks the set_key() interface's symmetry>> A new callback update_tkip_key could look like this:>> void update_tkip_phase1key(hw, keyconf, iv32, p1key)
What aboutenum tkip_update_flags { TKIP_PH1_TX_KEY TKIP_PH1_RX_KEY TKIP_PH2_TX_KEY TKIP_PH2_RX_KEY -- actually no need for any driver.} update_tkip_key(hw, keyconf , iv32, flag, key)
But I'm not sure about this... see above/belove
> The IEEE80211_KEY_FLAG_TKIP_PHASE1_VALID flag would go away, and the> new callback would be invoked right from where the phase1 key is> calculated.
Sure again I'm not sure this is symmetric - For TX it would be saferto do pull mode otherwise it can get out of sync.
> I'm not exactly sure whether one needs a phase1 key for RX and one for> TX right now, but if so a direction flag should be added?
Phase1 for TX and RX are not the same, again because of the simplereasone that number of transmitted and received packet is not thesame.
> johannes>��.n��������+%������w��{.n�����{���zW����ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
