[rt2x00-users] Padding and alignment for rt2800pci / rt2800usb

[Ivo van Doorn]

On Friday 28 August 2009, Benoit PAPILLAULT wrote:
> Ivo van Doorn a écrit :
> >
> > So only thing that needs fixing here is always let rt2x00lib check for
> > L2 padding rather then depending on the txdesc flag?
> I think so in fact. Even using the L2PAD flag, we still need to do
> lots of checking. Not using the L2PAD flag will just remove some code,
> so let's do it.

Yeah we only need to remove the L2PAD descriptor check in rt2800pci/usb,
and always enable the L2PAD flag for rt2x00lib in those drivers. That way
rt2x00lib will always handle L2padding and it will determine if something
needs to be done anyway.

> > But you do have a method on detecting that there are multiple frames?
> > Or did you founds that out by dumping the frames to userspace and
> > analysing them?
> >
> I dig into the ralink source code. Apparently, they just check that
> the remaining frame size and break the loop if the remaining size
> cannot contain RXINFO + RXWI.
> So far, I just check the received RX buffer size against what I
> expected it to be based on the first 802.11 frame. And this would
> explain why during WPA2 testing, it would not answer to all EAPOL
> request from the AP.
> 
> Do we agree to drop all the alignment code?

No. Because we still need it in place for the other drivers.
Besides I have a hunch that 4-byte alignment for the beacons
remains important.

> Could you tell me why crypto is handled in a separate path of code (at the beginning of
> rt2x00lib_rxdone)?

That path is to insert the IV/EIV data which was provided in the descriptor back into the frame
so mac80211 can use it for its own encryption engine. It might not be needed for rt2800pci/usb
but all other drivers do need it. But when IV/EIV is being added to the frame we are already
moving portions of the frame which makes it easier and faster to do all alignment actions at
the same time. That saves some memmove() calls later on.

Ivo