Forcing MIC failures, again
dcbw at redhat.com
Wed May 30 22:24:13 EDT 2007
On Wed, 2007-05-30 at 23:39 +0000, Queisser, Andrew (VfB Stuttgart
> Hi guys,
> I've got Ubuntu with a 2.6.20 kernel now and I'm looking through what
> my options are for forcing MIC failures. I've got a zd1211rw driver
> working with ieee80211 driver. I still don't really understand the
> difference between ieee80211 and mac80211 but as far as I can tell
> they do the same thing in a slightly different way?
ieee80211 = hybrid fullmac/softmac stack reflecting what ipw2x00 cards
ieee80211-softmac = a full softmac stack build on top of ieee80211
mac80211 = completely new softmac stack on which all new softmac drivers
should be built
> My mac80211 doesn't work yet, probably not part of the kernel so I'll
> leave the original advice I got from Jouni for the next stage when I
> have my zd1211rw working with mac80211.
mac80211 will be in 2.6.22. It's not had as much time to mature as have
the ieee80211 and ieee80211-softmac stacks though, so there will be
rough patches still.
> Anyway right now I can rebuild the ieee80211_crypt_tkip module with
> some code to corrupt the MIC but it doesn't seem to have any effect. I
> added something like this:
> if (corruptCondition)
> at the end of the function ieee80211_michael_mic_add, just before the
> return 0 statement. I added some printks to make sure my code executes
> when I do some repeated pinging and it does get executed
> I also tried some printk to print out the 8 bytes at the "pos" pointer
> but they don't match what I see in my sniffer.
> - Would the contents of pos match the bytes in the sniffer or is there
> another level of encryption that happens?
> - Why doesn't the change to the MIC cause a MIC failure on the AP? Do
> I have the code in the wrong spot?
> HostAP mailing list
> HostAP at shmoo.com
More information about the HostAP