>> 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...
True, it is a drawback, as I'll have to create 802.11 frames instead of
802.3 (with important data duplicated into all of them), but then I'll
just call ieee80211_invoke_rx_handlers with ieee80211_rx_handler
pointed to
local->rx_handlers[ieee80211_rx_h_802_1x_pae]. Then I won't have to
change any existing handler except of my new ieee80211_rx_h_amsdu
Do you think this approach makes sense?
> 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
Do you mean ieee80211_rx_h_decrypt?
If yes, I see it uses 3 different decrypt schemes. Here I have one
scheme reaping it self over and over.
> 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
---------------------------------------------------------------------
Intel Israel (74) Limited
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
-
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
