Re: d80211: current TKIP hwcrypto implementation seems to be broken

[Michael Buesch <mb@bu3sch.de>]

On Monday 05 February 2007 21:43, Jiri Benc wrote:
> On Sun, 4 Feb 2007 13:44:18 +0100, Michael Buesch wrote:
> > We need the phase1 for bcm43xx. We need to upload it to
> > card memory and we need to pass it on every TX on the DMA.
> > 
> > So, currently we receive the phase1 key on the first
> > encrypted TX. That's too late, as we already receive encrypted
> > packets before that. bcm43xx needs the phase1 key (and the iv32)
> > on RX. It uses the one uploaded into the card memory. But it
> > is not uploaded, yet, as we did not TX any encrypted packet.
> > 
> > I'd say the only solution to this is to implement the earlier
> > suggested way of having a library function call to generate
> > the keys. Of course, that needs some bookkeeping about the IVs
> > and stuff.
> > That library function would be called by bcm43xx before any
> > traffic to get an initial phase1 key (and iv32) uploaded.
> 
> What if the key is changed by the user space? You won't know that and
> won't call the library function then. I think it needs to be designed
> in the opposite way - the stack will call a driver's callback.
> 
> Or am I missing something?

Yeah, peobably. I don't really know in detail how
tkip works. I just know that current implementation in
d80211 does not work, as I tried it. ;)

I need to read the specs about it first.

-- 
Greetings Michael.