On Tue, Nov 22, 2016 at 08:59:39AM -0800, Ben Greear wrote: > On 11/22/2016 02:56 AM, Johannes Berg wrote: > >On Mon, 2016-11-21 at 08:10 -0800, Ben Greear wrote: > >>1) Allow supplicant to do bad state-machine transitions (start 4-way > >>before associating, for instance). > > > >Why would you do that? In order to test the AP implementation? > > Yes. And really, you should be able to do similar things on the AP to test stations, > or on IBSS/Mesh devices, etc. hostapd already has some options to corrupt or > drop a percentage of various management frames. Supplicant does not as far > as I know. I'm not sure adding a specific option to corrupt or drop a management frame is the best approach here. Both hostapd and wpa_supplicant have multiple mechanisms to enable testing in CONFIG_TESTING_OPTIONS=y builds and the most flexible cases allow the management and EAPOL frame processing to be handled by a test script through the control interface. This provides much more control on how to misbehave and allows that to be done at higher layer components without having to hardcode stuff in hostapd/wpa_supplicant (or kernel for that matter). In case of mac80211_hwsim tests, this is done in the python scripts (see tests/hwsim directory in hostap.git). > Currently, supplicant can (at least with some small patches that I carry), > add custom information elements to probe requests and similar. But, some things > are built by mac80211 (rate-sets advertised, for instance). So, I was thinking of slightly extending > the API so that user-space could over-ride whatever mac80211 might normally > build itself. That lets you more properly fuzz things from user space. For many cases, I'd expect it to be more flexible to override full frame payload from a test script rather than come up with more detailed (and more complex to implement) APIs.. As far as cfg80211/mac80211 is concerned, it might be convenient to have a command that allows user space to force a STA entry to a specific state when working in station mode (hostapd can already do this in AP mode). This would allow the existing offchannel management frame TX/RX operations to be used to perform arbitrary exchanges and with the forced state changes, this could cover more cases related to negotiating unexpected combinations or exchanges frames in unexpected sequence, etc. > >>4) Maybe some specific tests like putting in over-flow sized lengths > >>of IEs. > > > >Again, fuzzing would cover this? > > Yes, but for ease of use, and to cover frames generated by mac80211, I > was thinking: > > echo 0.25 > /debug/.../wlan0/mgt_fuzzer > > The fuzzer would then corrupt 25% of the management frames. And instead of just randomly > scribbling, it could also parse the frames and do some more clever (and still pseudo-random) > modifications to the frames, like re-writing IEs with bad lengths, flipping bits in specific portions of the > frame we feel might find problems, etc. Why would this be in mac80211? I would much rather handle this type of fuzzing operations in user space and just provide generic interfaces in cfg80211 to allow the messages to be exchanged. For most parts, this capability exists already today.. > >>Has anyone done anything similar they would like to share? > >> > >>Johannes: Any interest in having such a framework in upstream > >>kernels? hostap.git tests/hwsim has quite a few such functions in testing use. I don't think I'd support kernel changes in the style that you are thinking of here, but I would very much support providing more generic interfaces, where required, to allow this type of testing to be performed from user space scripts. > Well, there is a decent chance you could crash some firmware if you sent > corrupted EAPOL frames to it. And just possibly some drivers inspect packets as well, > so I was thinking that fully transmitting the frames out of the system might > have some use. And specifically for me, I am trying to test remote systems, > so hwsim would not be useful for that. > Lots of this capability is already there in mac80211, cfg80211, hostapd, and wpa_supplicant.. While mac80211_hwsim tests are one of the main use cases for this, this works fine with any mac80211-based driver for over-the-air testing as well. For AP mode, it is possible to override most of management frame and EAPOL processing. For STA mode, EAPOL processing can be fully overridden and quite a few management frame exchanges can also be handled from test scripts through wpa_supplicant control interface, but there may still exists some more constraints on preventing some testing combinations. > But, if local Linux (and local userspace) itself is the test target, then hwsim should give some very good > test coverage. Please keep in mind that almost anything that can tested with mac80211_hwsim can also be used with real WLAN hardware when using mac80211-based drivers.. -- Jouni Malinen PGP id EFC895FA
