On Mon, 2006-11-06 at 21:01 +0100, Jiri Benc wrote:

> This definitely breaks AP mode. In the code, there is heavily (ab)used
> the fact that the master device is in fact an AP device. I tried to fix
> that but it was so difficult I gave up. It is needed to rewrite the
> whole RX path (and even that is probably not enough).

Alright, I see the point. Let's fix it up good while at it. Here's a
braindump.

Keeping with the protocol theme, we need to rewrite the rx path to do
the following in the order listed:

 1) if any monitor interfaces are up, copy the skb, add the
    prism/radiotap/whatever header and then clone it to all monitor
    interfaces (don't actually copy for each as we do now)
 2) if it is a unicast frame, determine which interface the frame should
    go to now, it can't be going to more than one afaik
 2) decrypt the frame
 3) defragment the frame
 4) send the frame off to each sub_if that might care about it
 5) do further device specific processing

I need to think more about this though.

If we're careful, we can probably get away with a lot less copying than
we do now by pushing the copying down into those handlers that really
need different data. This would probably only be the crypto handlers,
the others can live with just pskb_copy instead. Then again, we don't
handle non-linear skbs anyway. Actually, we should be calling
skb_linearize at least, no?

And if the frame is not encrypted at all, then we can even save the
skb_copy for the monitor and just use skb_clone and later pskb_copy...

Time for bed,
johannes

Attachment: signature.asc
Description: This is a digitally signed message part

Reply via email to