> > The one thing I'm not sure about here is the EAPOL frame handling. In
> > theory, such frames could be part of an aggregation and thus we'll not
> > get them to the right place. Then again, we haven't decided yet what
> the
> > right place is. Also, what happens with 802.1X port control?
>
> I agree. Good point and thanks for the catch.
> 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...
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)
It'd basically look like this
handle_data_frame
{
result = handle_pae()
if (result == ...)
if (should_drop_unencrypted && is_unencrypted())
return DROP
...
}
and rx_h_data would simply reframe the frame and pass it to this
function, and your deaggregation handler would loop over this function.
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.
We may need more discussion, but I believe finding a good solution to
this is a crucial part of proper support for deaggregation.
johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
