AppleIntelWifi
Investigate use of Apple80211 rather then implementing IEEE80211
Apple80211 is already a full fledged supplicant providing the state machine functionality we're desiring after. If this is intended to be a drop in replacement, and provide AirPort functionality, we should REALLY use the RSNSupplicant rather then dealing with the nightmare that is implementing a full 802.11 stack into the driver.
I've started some preliminary research on this on Black80211, but more research needs to be done into it.
Means that we should all use apple80211Controller, interface and RSNSupplicant or other things, it is a big challenge filling of mounts of uncertain problems, but it is also a way we can try.
Are there specific action items for this issue for those wanting to contribute?
@tomasdev I would really love support in trying to figure out how we can architect a non-STL platform heterogenous 802.11 compliant library. I’ve been in contact with zxystd and we both agree that having a library that was completely separate OF the actual drivers (but still got much needed attention) is the best way to go here. I can make a massive project board for this, if needed.
As documented elsewhere, sadly Apple80211 is not what can be considered a “full MAC stack”. It is nearly entirely designed to supplement something like Broadcom’s 802.11 stack, which is a self-contained behemoth which handles everything and has it’s own ioctl facility, memory management, channel scanning, and a full implementation of AWDL (you can find it online, it’s referenced by an academic paper detailing AWDL and the bits behind it that make it work). Implementing AirDrop is COMPLETELY within our reach- “active monitor” (being able to inject frames whilst the device is in a monitoring state) is something that is reliant on the driver, rather then the hardware specifically as I believe that we’d be able to simply add another virtual interface which is listening on ch. 6 for AWDL updates (but this is far far in the future). However, one thing that is incredibly nice is that it handles the entire EAPOL negotiation sequence, and pairing that with WPA2 decryption offload, means that a LOT of attack surface (in terms of crypto) is reduced. I’m simply not comfortable writing crypto code 😅
So another question raise is that which features should the "802.11 compliant library" have? just handle MGMT/DATA frames and rate managemnt or a full 80211 stack like net80211 do(handle state/rate management/scan/auth/frame encryption and decryption)?
I think the library should really focus on being a full stack driver, and handling MGMT/data frames obviously goes along with it. An idea I had was using virtual methods in a class to implement it, akin to how IOKit is programmed.
I think the best course of action is to build out most of the logic in a separate library as much as possible, then potentially statically link that during compile time. I’m building a new system right now, and haven’t had time to flush out the details yet.
