• Immutable Page
  • Info
  • Attachments

KernelProjects/Mac80211TestDriver

Problem Description

mac80211 is currently exclusively tested by developers on real hardware with one of the 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 could live in debugfs or relayfs, maybe having one file for frames and one file for control operations/hw conf calls.

Jouni Malinen has implemented something similar (all the frame relaying is done in kernel space), drivers/net/wireless/mac80211_hwsim.c. This code should be extended.

Project Difficulty

This project requires getting familiar with the mac80211 driver API code which we're starting to document, see http://linuxwireless.org/en/developers/mac80211 and links from there. Writing the userspace API requires familiarity with debugfs or relayfs. The actual difficulty of hte project comes from the userspace part which can range from an almost trivial program just using the API to a very extensive fuzz-tester or similar.

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.

Tell others about this page:

last edited 2008-06-17 06:34:42 by JohannesBerg