Re: [PATCH 06/14] mac80211: adding 802.11n essential A-MSDU Rxcapability

[Jouni Malinen <j@w1.fi>]

On Mon, Nov 12, 2007 at 05:45:42PM +0100, Johannes Berg wrote:

> > Would appreciate your opinion for next possible solution:
> > I'll Move ieee80211_rx_h_data_agg before ieee80211_rx_h_802_1x_pae, and
> > assuming I identify A-MSDU, I'll loop for each internal MSDU on:
> >   ieee80211_rx_h_802_1x_pae 
> >   ieee80211_rx_h_drop_unencrypted
> >   ieee80211_rx_h_data
> > return value of ieee80211_rx_h_data_agg to
> > __ieee80211_invoke_rx_handlers will be this small loop's return value 
> 
> I'm not sure I'd like to see such a thing. One thing I'm generally
> unhappy with here is how the handlers are in a list but there isn't a
> point in adding/removing any. Also, I'm not convinced that what you're
> saying will actually work because the handlers expect 802.11 frames so
> you'd have to make 802.11 frames out of the 802.3 frames you get...

When working with a proprietary (pre-802.11n) frame aggregation, we
ended up doing more or less this, i.e., converting the frames to a list
of skb's that had generated 802.11 headers and then passing them one by
one to ieee80211_rx_h_data. I don't know whether I would say that I
likeed the end result, but at least it seemed to work without major
problems.

This was assuming that there were never frames that would need special
handling in the aggregate (i.e., need for special PAE or
unencrypted/encrypted processing). Since the aggregate was encrypted as
a single unit, the drop_unencrypted was not an issue. Same was, in
practice, true for most of PAE processing. I don't think the initial
EAPOL handshake is an issue, but at least in theory, there could be an
EAPOL re-authentication happening at some point and if EAPOL frames
require special processing, this would need to be taken into account.

> What I originally wanted to do for this was to add a new
> "handle_data_frame" function that operates on 802.3 frames but has all
> the info available, is called from the rx_h_data handler and
> incorporates all the three callbacks you list above.That'd be similar to
> what I did with the crypto code (where we now only have a single handler
> doing it all rather than a bunch doing different pieces of the
> functionality)

Please note that data frame handling requires support for four addresses
and plain 802.3 header would not be sufficient without some additional
meta data. I would assume this to be doable, but some of the
functionality will need to moved around to handle the 802.11 specific
things first (like WDS interface selection) and then pass some meta data
in addition to the frame. This would get relatively close to the
MA-UNITDATA service primitives from the MAC (which do indeed only pass
two addresses; 802.3 header would just be one example of how this
information can be passed).

> You should be able to do this in the code right now because I removed
> the management interface and hence EAPOL frames aren't handled
> specially. Hostapd wants to have eapol frames on the management
> interface and 802.11 framed, but I don't understand that and would
> rather have it be done differently.

As long as the issues with encrypted vs. unencrypted frames can be
resolved for both TX and RX in a way that handles the 802.1X and WPA
cases, it should be fine passing EAPOL frames as normal data frames. In
addition, bridging code should be told not to bridge this ethertype if
that has not been done yet.

-- 
Jouni Malinen                                            PGP id EFC895FA