# madwifi "Set Mode" failure

## zanzer7

I've been reading topics here for the last few hours, but of all the solutions, nothing has helped me.

I'm using madwifi drivers (madwifi-driver-0.1443.20060207), got a secure (WPA-PSK) stable connection up and running.

However, I can't in any way set ath0 to monitor mode (or any other mode than managed, for that matter). I keep getting this error:

```
heartofgold ~ # iwconfig ath0 mode monitor

Error for wireless request "Set Mode" (8B06) : 

    SET failed on device ath0 ; Invalid argument.
```

I've got these relevant flags set in my /usr/src/linux/.config:

```
CONFIG_NET_WIRELESS=y

CONFIG_NET_RADIO=y

CONFIG_CRYPTO_HMAC=y
```

Scanning works:

```
wlanconfig ath0 list scan

SSID            BSSID              CHAN RATE  S:N   INT CAPS

zan             00:**:**:**:**:9f    7   54M 52:2   119 EPs  WPA
```

But when I do airodump, I get the same error as with iwconfig ath0 mode monitor.

I've tried creating a new interface, ath1, with:

```
heartofgold ~ # wlanconfig ath1 create wlandev wifi0 wlanmode monitor

ath1

heartofgold ~ #
```

I'm able to set ath1 into monitor mode, but when I run airodump with this interface:

```
heartofgold ~ # airodump ath1 output 0
```

...then airodump runs fine, but the resulting table hasn't got any APs in it.

As I said, the actual wireless (WPA-secured) connection runs fine.

I'm using linux-2.6.15-gentoo-r1, by the way...

ANY help will be great, and if you got the same problem, well ... stick around!  :Smile: 

(NOTE: I'm not able to paste into this browser, so there might actually be typos in the error messages :s)

EDIT: There was a typo: I had written wifiX instead of wifi0 in my post - it has been corrected now.

----------

## wmgoree

The madwifi-ng drivers don't set modes with iwconfig anymore (at least, not directly) because they use virtual ap's. So, what you'll have to do is use wlanconfig (which has a good man page) to set up the vap. It goes something like this.

```

wlanconfig ath create wlandev wifi0 wlanmode monitor

```

You'll now have a new athX device in monitor mode. The advantage of this is that you can associate with multiple access points using a single card. The disadvantage is that as far as I can tell, channel choice is card-wide, meaning they'll both have to be on the same channel. Also, if you're scanning while associated, the scan has to stay on the channel of your associated network.

I *believe* you can then use iwconfig to manage your new interface and set it to managed or adhoc or whatever, but I haven't tested that; if it doesn't work, just use wlanconfig to set up whatever you want.

Note that this causes problems with some things like kismet and airsnort that expect to be able to alter your interface's mode. If you want to use kismet, create ath1 as I described above (making sure you use wlanmode monitor), set ath1 as the interface in kismet.conf, and it *should* see that the card is already in monitor mode and go happily on its way.

----------

## zanzer7

Thanks for replying and wanting to help, wmgoree  :Very Happy: 

Though sadly (as I wrote), I have already tried that solution, and while I was able to put the newly created device into monitor mode, airodump still didn't work as it should.

I'm mingling with a few config files now, but I don't really see anything which could be causing it...

Another point is, I've gotten hold of a copy of BackTrack (a merge of Auditor and Whax), which seems to run airodump just fine. Problem is, I have no idea what configuration is being used, as BackTrack is based on Slax, which is again a livecd based on Slackware.

So I know it's possible to make it work (even without having to create a new interface; airodump ath0 out 0 works fine in BackTrack), it just annoys me I can't make it work in gentoo.

Any info about how to get the configuration from BackTrack to work in Gentoo will also be greatly appreciated  :Smile: 

----------

## wmgoree

REALLY sorry! Firefox was cutting off the post weirdly and I missed about 3/4s of it.

I had issues with getting the last several madwifi drivers in portage to work with most tools (stumbler, kismet, etc.) I'd say to grab a CVS snapshot of the drivers and see if that fixes your problem; if not you can always just re-emerge the drivers in portage.

----------

## zanzer7

I just compiled the cvs version.

20060217

Still same error  :Sad: 

I'm clueless now ...

----------

## zanzer7

I made airodump work, but only by using old (20051025) madwifi drivers... unfortunately I couldn't make wpa_supplicant work with these, and since my network is wpa-psk-encrypted, I need this feature...

If there's any solution to the above problem... well...

----------

## zanzer7

I've tried looking into what drivers BackTrack uses...:

madwifi-driver-20051025 (injection patched)

wpa_supplicant-0.4.7

I've been trying to use these in gentoo, by first removing the old (newer) drivers, and installing a tarball of a patched madwifi-20051025 driver.

I then edit the wpa_supplicant-0.4.7 ebuild to also be combatible with the madwifi drivers (which they aren't to begin with, and USE="madwifi" doesn't work with 0.4.7). I save this as 0.4.7-r1

When I've digested the newly created ebuild, I try to emerge it (emerge --nodeps =wpa_supplicant-0.4.7, since it finds the madwifi drivers as 'not installed'). This doesn't work, since wpa_supplicant can't find the madwifi driver modules.

Somehow the BackTrack wpa_supplicant-0.4.7 must've been edited to support madwifi drivers as well, because they work (somewhat) properly. 

If there's anyway I could copy those to make them work in Gentoo (or something like that), I'd be verypleased to know  :Very Happy: 

----------

