On Monday 07 April 2008, Johannes Berg wrote: > > > I'm not sure if I understand completely what you mean but rt61pci/rt73usb hardware does the following: > > > > 1) Receive frame > > 2) Determine key from register > > 3) Put IV/EIV into descriptor > > 4) Decrypt > > 5) Notifies driver about the frame + decryption status > > Ok, so you get those out-of-band. > > > Well as an alternative to adding it to tx_control, perhaps a callback function for drivers > > could be provided? At the moment mac80211 calls: > > > > ieee80211_tkip_add_iv(pos, key, > > (u8) (key->u.tkip.iv16 >> 8), > > (u8) (((key->u.tkip.iv16 >> 8) | 0x20) & > > 0x7f), > > (u8) key->u.tkip.iv16); > > > > to insert the IV into the skb, if the driver could get a calback function that calls the above > > function and writes the result into a char* buffer you get the same effect except that the > > driver can put the iv wherever it wants. > > That way rt2x00 doesn't have to set the IEEE80211_KEY_FLAG_GENERATE_IV flag, and > > can request the IV manually from mac80211. > > No, you can't do that because the IV is already incremented at that > point, so you wouldn't be able to perfectly match things up because > ops->tx() need not be serialised with this due to deferring to the > master interface. Ok, so just to summarize (so I have everything right :) ) TX path) rt2x00 sets the IEEE80211_KEY_FLAG_GENERATE_IV flag grabs the IV/EIV from behind the ieee80211 header memmove ieee80211 header to remove the IV/EIV TX done path) memmove ieee80211 header to make room for IV/EIV reinsert IV/EIV behind ieee80211 header call ieee80211_tx_status() for mac80211 RX path) memmove ieee80211 header to make room for IV/EIV insert IV/EIV behind ieee80211 header call ieee80211_rx() for mac80211 Thanks, Ivo -- 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