> This is only in RX side. Each AC (access category) queue transmit in
> it's own rate. For example VO trasmitts more packets then BE. So you
> might get into case in receive site that VO packets are already on
> wraparound 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 ph1
> doesn't match for each AC queue.
Right, in software we can keep a phase1 per AC but we don't need to in
hardware since that's just the optimisation.
> > 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 in
> HW before you transmit the packet
> Phase1 need to be adhered to a packet that causes wraparound unlike RX
> that you can fall back to SW decryption
> In TX there is no way back.
Good point. So then for Broadcom we actually need to update phase1 in
hardware when it changes on TX and not bother with RX at all, we'll fall
back to software in that case.
> > > > 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 about
> enum 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 safer
> to do pull mode otherwise it can get out of sync.
True. Hence, since phase2rx is not really useful, we don't actually need
any sort of update flags when we do the TX keys in pull mode, which I
prefer anyway.
> > 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 simple
> reasone that number of transmitted and received packet is not the
> same.
Hm, right. But if we go for pull mode for TX, we only need to have push
mode for the phase1 rx key when that changes, no?
johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
