== Problem description == [http://linuxwireless.org/en/developers/mac80211 mac80211] is currently mostly tested on real hardware with the many available drivers. However, this requires hardware, and some tests are simply not possible (sometimes sending corrupt frames etc.) Therefore, it would be good to be able to test via a pseudo driver that doesn't use real hardware but exposes the mac80211 API to userspace instead. This means that it allows doing arbitrary mac80211 operations from userspace. Major points are having frames that mac80211 is transmitting in userspace and "receiving" frames into mac80211's RX path. Additionally, the hw configuration calls mac80211 does should be passed to userspace and handled there. The userspace API should also enable calling many of the mac80211 functions. In order to test association to an access point etc. one would probably use two test drivers and link them together in a userspace tool that passes frames between the two; one would then run hostapd on one interface and act as a client on the second. The userspace tool would also allow injecting arbitrary frames to allow for easy fuzz-testing. Bonus points for being scriptable to allow frame injection into a sequence of frame exchanges to try hijacking a session etc. to be able to test error-paths in the code. == Starting points == The interface for the pseudo driver should probably live in debugfs, maybe having one file for frames and one file for control operations/hw conf calls. == Additional ideas == * Many protocol tests can be implemented this way as well by having a implementing partial access point code in the userspace application and have that access point behave erratically to test corner cases; similarly for testing the access point code etc. * IEEE specification tests could be implemented, for example verifying that when the access point starts advertising RTS/CTS protection the low-level driver is notified of that.