Fixed channel mon0

[lucid]

This problem never ceases to follow me around. If you don't know what this is I'll breifly explain it to you. Basically, for whatever reason, when running airodump-ng I've noticed that the WPA handshake won't work because it claims you are fixed on channel(usually -1) and the target is on another channel. I've had it trying out aircrack-ng on Arch. The supposed fix to that problem was to install the compat drivers. Doing this originally prevented me from connected to the internet at all. This solution is no longer working anyway considering to recent package deprecations in the Arch repositories. Such as the rtl8187 module.

I figured that Kali surely wouldn't have this problem so I decided to crack my own network using Kali linux. Same basic problem, except that instead of saying 'fixed channel mon0 -1' in the upper right-hand corner while attempting the handshake running airodump-ng, it says 'fixed channel mon0 ' and the number next to it keeps switching. Has anyone found a fix for this at all? Anyone else have this problem? Because I'm rather sick of it at this point.

I followed this page in order to fix the problem on Kali:

http://ubuntuforums.org/showthread.php?t=1598930

Everything worked up until I ran make. Then I get this:

Code: [Select]

/root/compat-wireless-2010-10-16/config.mk:196: "WARNING: CONFIG_CFG80211_WEXT will be deactivated or not working because kernel was compiled with CONFIG_WIRELESS_EXT=n. Tools using wext interface like iwconfig will not work. To activate it build your kernel e.g. with CONFIG_LIBIPW=m."
/sbin/modprobe: invalid option -- 'l'
/sbin/modprobe: invalid option -- 'l'
make -C /lib/modules/3.7-trunk-amd64/build M=/root/compat-wireless-2010-10-16 modules
make: *** /lib/modules/3.7-trunk-amd64/build: No such file or directory.  Stop.
make: *** [modules] Error 2


[Snayler]

Basically, for whatever reason, when running airodump-ng I've noticed that the WPA handshake won't work because it claims you are fixed on channel(usually -1) and the target is on another channel.

That's some bug with rtl8187 driver, or with airodump itself (i don't remember which). The new version of airodump has a switch to disable the message. In my experience, you can ignore the -1 error, the card will work anyway.

I figured that Kali surely wouldn't have this problem so I decided to crack my own network using Kali linux. Same basic problem, except that instead of saying 'fixed channel mon0 -1' in the upper right-hand corner while attempting the handshake running airodump-ng, it says 'fixed channel mon0 ' and the number next to it keeps switching. Has anyone found a fix for this at all? Anyone else have this problem? Because I'm rather sick of it at this point.

How are you running airodump-ng? Because if you leave the channel undefined, it will just hop channels.

Also, I never needed to compile drivers with rtl8187 chipsets. The default driver on most distros works just fine.

[lucid]

airodump-ng -c 2 --bssid 00:00:00:00:00:00 -w psk mon0

That's the command I run. Obviously with the proper mac address and channel number.

[Snayler]

How about your network manager? Maybe it's messing with the card, have you disabled it in /etc/network/interfaces?

Also, instead of using airmon-ng, try this:

Code: [Select]

ifconfig wlan0 down
iwconfig wlan0 mode monitor
ifconfig wlan0 up
Also, for arch: https://bbs.archlinux.org/viewtopic.php?id=115210

[lucid]

Wow. That solution worked...

Once. Then I tried it again and I'm getting the same problem. I've decided to run through everything that I'm doing.

Ok, so first I ran these commands:

Code: [Select]

ifconfig wlan3 down(wlan3 is the interface of my external wireless adapter)
iwconfig wlan3 mode monitor
ifconfig wlan3 up

Ok so far so good. Next I run this:

Code: [Select]

airodump-ng wlan3

Then after selecting the appropriate AP for the network I want to crack:

Code: [Select]

airodump-ng -c 2 --bssid 'apmacaddress' -w psk wlan3

Then, and here's the part where it usually messes up. I run:

Code: [Select]

aireplay-ng -0 1 -a 'apmacaddress' -c 'deauthclientmac' wlan3

Usually it tells me that it can't deauth because I'm on a different channel then the target. The first time I tried Snayler's advice this part worked. Then I decided to start from scratch just to be sure of what I was doing and now it doesn't work again.

[proxx]

What works for me with certain cards is this;

systemctl stop NetworkManager (If you use network manager)
ifconfig wlan0 down
airmon-ng start wlan0
iwconfig mon0 channel 4
airodump-ng -c 4 -w something --bssid MAC
aireplay-ng -0 4 -a MAC -c MAC

Basically you force it to a channel before using it.

[lucid]

What works for me with certain cards is this;

systemctl stop NetworkManager (If you use network manager)
ifconfig wlan0 down
airmon-ng start wlan0
iwconfig mon0 channel 4
airodump-ng -c 4 -w something --bssid MAC
aireplay-ng -0 4 -a MAC -c MAC

Basically you force it to a channel before using it.

Ok, so I've followed your instructions, substituting my desired channel, and it got me through the deauth step. However, when I go to actually crack the password with:

aircrack-ng -w passwordlist.txt -b MAC psk-01.cap

It simply tells me there are no valid WPA handshakes found. In the upper right hand corner after running airodump-ng it still says:

fixed channel mon0: 3 < that number keeps changing every second

Even though I had no problem deauthing, indicating I'm on the appropriate channel.

[Mordred]

I'm not exactly sure why you're getting the issue. On my laptop it has never come across as a problem until now, however I do have an alternative for your needs which might allow you to actually crack wpa because it's with wash and reaver.

Code: [Select]

airmon-ng stop wlan3

airodump-ng wlan3

wash -i wlan3 -c <channel> -C -s

//don't think the next part will work if it's WPS Locked, didn't try yet

reaver -i wlan3 -b <BSSID> --fail-wait=360

Maybe this will work? Might also give some clues as to why the normal WPA cracking method is causing troubles with the channels.

[karsa]

It's been a while but iirc what worked for me was, like proxx said, forcing the card to a specific channel, but only with airmon-ng.

Code: [Select]

airmon-ng start wlan0 3
airodump-ng -c 3 --otherstuff mon0
aireplay-ng -stuff


[Snayler]

What about this?

systemctl stop NetworkManager (If you use network manager)
ifconfig wlan3 down
iwconfig wlan3 mode monitor channel 4
ifconfig wlan3 up
airodump-ng -c 4 -w something --bssid MAC
aireplay-ng -0 4 -a MAC -c MAC

It's proxx's advice without airmon-ng.

[lucid]

At this point we are just arguing semantics. I've gotten it to stay on the channel I want. At least I think so, the deauth finally works.

For some reason, I just can't successfully make the WPA handshake happen. It would be interesting to know what actual commands are being run....you know, behind the scenes.

EDIT: Yeah at some today or tommorrow when I get the time I'll try it with other things besides aircrack.

[Snayler]

For some reason, I just can't successfully make the WPA handshake happen. It would be interesting to know what actual commands are being run....you know, behind the scenes.

Check the capture file with wireshark, see if you can find the 4 handshake packets.

And this is still worrying me:

It simply tells me there are no valid WPA handshakes found. In the upper right hand corner after running airodump-ng it still says:

fixed channel mon0: 3 < that number keeps changing every second

My guess would be that using airmon-ng is causing that specific problem. I've read in multiple places that using iwconfig instead of airmon-ng solves that problem.
Also, check if you have more than one instance of airodump running on another terminal window or something.

[lucid]

Well, I've successfully gotten the deauth to work just by running wlan3 in monitor mode and forcing to channel four:

ifconfig wlan3 down
iwconfig wlan3 mode monitor channel 2
ifconfig wlan3 up

The running airodump-ng wlan3 and proceeding from there. So I'm not longer using airmon-ng. I also never have more then one instance of airodump-ng running at one time. I kill one before I start another one. Oh, and I fired up wireshark and set the filter to eapol. At no point in the process do I see any packets whatsoever. So obviously the handshake isn't happening at all.

[Snayler]

Ok, sorry in advance for the basic questions, but I need to be sure:
1. How far is your card from your router?
2. Do you have at least one client connected to your router?
3. What specific card are you using? Alfa? Model?

I'm assuming you're trying this with your own router, correct me if I'm wrong.

[lucid]

1. Same room
2. Yes there is at least one client connected to the target router.
3. Alfa AWUS036H