Hello,
Now that AP mode works in mac80211 I want to use it to test Michael
MIC failures in a wlan driver. Any recommendations, or tips, how to
easily create them with mac80211 and hostapd?
--
Kalle Valo
Johannes Berg <[email protected]> writes:
> On Sat, 2008-11-01 at 17:19 +0200, Jouni Malinen wrote:
>
>> Anyway, if you just want to test Michael MIC error processing on a
>> client, force mac80211 to do software encryption
>
> On that matter, should we put a debugfs control knob in place to
> completely disable HW encryption in mac80211, so we don't need this
> override in all drivers?
I think there's a need for this and we should do it. Just look at this
commit from earlier this week:
commit 05e6eb6f607cc3623c50b2a7c62b29ba6707a316
Author: Bob Copeland <[email protected]>
Date: Wed Oct 29 08:30:54 2008 -0400
ath5k: enable hardware encryption for WEP
This change re-enables hardware encryption for ath5k after setting up
mac80211 to handle the initialization vectors which happens to make it
work. Add a module param (nohwcrypt) to optionally turn it off.
Signed-off-by: Bob Copeland <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Having a support in mac80211 would make it easier both for the driver
developers and users.
--
Kalle Valo
On Sat, Nov 01, 2008 at 04:51:37PM +0100, Johannes Berg wrote:
> On that matter, should we put a debugfs control knob in place to
> completely disable HW encryption in mac80211, so we don't need this
> override in all drivers?
Yes, that would probably be a good idea. There are going to be number of
cases when some combinations are not going to work (e.g., when IEEE
802.11w is added, I would expect to see some breakage..) and being able
to force software encryption per device could end up being quite useful.
--
Jouni Malinen PGP id EFC895FA
"ext Jouni Malinen" <[email protected]> writes:
> On Sat, Nov 01, 2008 at 04:31:26PM +0200, Kalle Valo wrote:
>
>> Now that AP mode works in mac80211 I want to use it to test Michael
>> MIC failures in a wlan driver. Any recommendations, or tips, how to
>> easily create them with mac80211 and hostapd?
>
> There used to be test code for this in mac80211 that allowed testing of
> more or less all TKIP error cases (MIC error on TX/RX, ICV error on
> TX/RX, replay), but it looks like that has been mostly "cleaned up" be
> removal.. You might be able to find it from some old version..
Ok, I'll try to find it.
> Anyway, if you just want to test Michael MIC error processing on a
> client, force mac80211 to do software encryption and modify
> ieee80211_tx_h_michael_mic_add() in net/mac80211/wpa.c to insert an
> incorrect MIC (e.g., add mic[0]++; after the michael_mic() call). You
> will probably need a trigger mechanisms (say debugfs write) to enable
> this for a single TX frame in order to allow proper client testing.
Thanks, this is very helpful.
> Once I have some time, I could take a look at recovering the old design
> with a debugfs interface (it used to use private ioctl). It is useful to
> be able to test this type of things during development/system
> validation.
It sure is. I think I'm going to start using hostapd/mac80211 combo
for all my development, a simple configuration file and proper logs
are very handy compared to some crappy web interface. And having test
cases like artificial Michael MIC failure makes the system even
better.
I really hope that John can push the AP support to mainline during
next merge window :)
--
Kalle Valo
On Sat, Nov 01, 2008 at 04:31:26PM +0200, Kalle Valo wrote:
> Now that AP mode works in mac80211 I want to use it to test Michael
> MIC failures in a wlan driver. Any recommendations, or tips, how to
> easily create them with mac80211 and hostapd?
There used to be test code for this in mac80211 that allowed testing of
more or less all TKIP error cases (MIC error on TX/RX, ICV error on
TX/RX, replay), but it looks like that has been mostly "cleaned up" be
removal.. You might be able to find it from some old version..
Anyway, if you just want to test Michael MIC error processing on a
client, force mac80211 to do software encryption and modify
ieee80211_tx_h_michael_mic_add() in net/mac80211/wpa.c to insert an
incorrect MIC (e.g., add mic[0]++; after the michael_mic() call). You
will probably need a trigger mechanisms (say debugfs write) to enable
this for a single TX frame in order to allow proper client testing.
Once I have some time, I could take a look at recovering the old design
with a debugfs interface (it used to use private ioctl). It is useful to
be able to test this type of things during development/system
validation.
--
Jouni Malinen PGP id EFC895FA
On Sat, Nov 1, 2008 at 4:51 PM, Johannes Berg <[email protected]> wrote:
> On Sat, 2008-11-01 at 17:19 +0200, Jouni Malinen wrote:
>
>> Anyway, if you just want to test Michael MIC error processing on a
>> client, force mac80211 to do software encryption
>
> On that matter, should we put a debugfs control knob in place to
> completely disable HW encryption in mac80211, so we don't need this
> override in all drivers?
>
> johannes
>
Good idea.
Also, we might want to auto-disable HW encryption on a PHY that has
one of the following configurations:
-both station and AP interfaces on a single PHY with different
encryption on the station and the AP (do we already do this?)
-only a monitor interface present
-(possibly) multiple monitor interfaces on the same PHY
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
On Sat, 2008-11-01 at 17:19 +0200, Jouni Malinen wrote:
> Anyway, if you just want to test Michael MIC error processing on a
> client, force mac80211 to do software encryption
On that matter, should we put a debugfs control knob in place to
completely disable HW encryption in mac80211, so we don't need this
override in all drivers?
johannes
On Sat, 2008-11-01 at 16:31 +0200, Kalle Valo wrote:
> Now that AP mode works in mac80211 I want to use it to test Michael
> MIC failures in a wlan driver. Any recommendations, or tips, how to
> easily create them with mac80211 and hostapd?
Inject frames maybe? Easiest is probably to disable hw crypto, then
you'll see the fully encrypted frames on a new monitor interface and can
inject them again.
johannes