> 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. Hmm. Management frames cannot be aggregated and EAPOL shouldn't need special processing, but getting all this code into one block so the compiler can optimise it is better nonetheless imho. > 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. Not sure about this. We do interface selection before the RX handlers (well, we currently loop, but that can and ought to be improved). Hence, at the point where we reframe the frame to 802.3 we no longer need any extra data, do we? > 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. Well for TX we've already solved this with the monitor mode injection. For RX, I'm not exactly sure about how things need to work. Can you explain the 802.1X/WPA/dynamic WEP cases? > In > addition, bridging code should be told not to bridge this ethertype if > that has not been done yet. That should be easy enough to check/do. johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
