>>> The one thing I'm not sure about here is the EAPOL frame handling
>>> johannes
>> I agree. Good point and thanks for the catch.
>> 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
>> Do you think this approach makes sense?
>> ron
> I'm not convinced. That seems fairly ad-hoc and likely to break in the
> future because only parts of the 802.11 header can be reconstructed.
> incorporates all the three callbacks you list above.That'd be similar
> what I did with the crypto code (where we now only have a single hndler
> 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.
> johannes
okay. looking in the architecture i think your approach is better, and
this bug should be fixed the way you suggested.
ron
-
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
