> > 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? 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. > 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. Yeah, this used to have four or five different RX handlers. johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
