Skip to main content
Found link that offers fix as opposed to a work-around
Source Link

Is the instructor using a virtual environment also? If not, you may need to deviate from the exact steps he's using. Just an initial thought. Your output looks fine though.

I have a feeling you need to kill the network processes, that airmon-ng displayed, but I'd try other options first.

Stop monitor modes if any, change interface channel, then enter monitor mode. [wlan0 and mon0 will be your own interfaces]. Since it's a USB card, I'd personally go so far as to remove it and plug it back in. Make sure VM settings are kosher. Then bring it up. In Kali, ifconfig options should be up|down ie [ifconfig wlan0 up] I'm only including that because I think that's what Sergej intended, but put 'stop'.

airmon-ng stop mon0
iwconfig wlan0 channel 1
airmon-ng start wlan0

I'm not sure of Kali, but in Backtrack, yes, the order in which you performed the settings did matter. Won't hurt to try.

Confirm.

iwlist mon0 channel

If that failed, another option is to change channels using airmon-ng.

airmon-ng start wlan0 1

One more alternative is with airodump-ng, subsequent to creating a mon interface; which of course will also display traffic.

airodump-ng --channel 1 mon0

I have a feeling this final trick will do the job, but try the previous methods first. Run a command to kill background processes that sometimes interfere with aircrack's channel switching, including the well-known "-1 channel" error. The warning airmon-ng gave in your example includes the processes.

airmon-ng check kill

That command will take down network-manager, dhclient and/or all associated processes known to interfere with aircrack. Then try switching channels again using iwconfig. Your network connection will terminate, so if this is leading up to a MITM simulation, you'll need to take that into account.

service network-manager restart

...will bring network-manager back up again when you're finished.

As for MDK, I'm not sure if you need to know that software specifically for your testing, but aircrack suite has a tool called airbase-ng which offers the same capabilities as MDK, as far as creating a soft AP. I'd try MDK again after running the 'check kill' in airmon-ng, just to see.

Sorry I can't answer your question as to 'why'. If you query aircrack's monitor mode channel issues, there's tons of info regarding the channel -1 problem, but dig deeper and you'll find it's also related to similar problems users have had, such as yours.

EDIT: Stopping processes isn't a fix and I don't like recommending such things, so I found this patch that may actually FIX the problem that the OP encountered. Patch

It's been a while, hope you were able to duplicate the tests though. Maybe this'll helps others anyway.

Is the instructor using a virtual environment also? If not, you may need to deviate from the exact steps he's using. Just an initial thought. Your output looks fine though.

I have a feeling you need to kill the network processes, that airmon-ng displayed, but I'd try other options first.

Stop monitor modes if any, change interface channel, then enter monitor mode. [wlan0 and mon0 will be your own interfaces]. Since it's a USB card, I'd personally go so far as to remove it and plug it back in. Make sure VM settings are kosher. Then bring it up. In Kali, ifconfig options should be up|down ie [ifconfig wlan0 up] I'm only including that because I think that's what Sergej intended, but put 'stop'.

airmon-ng stop mon0
iwconfig wlan0 channel 1
airmon-ng start wlan0

I'm not sure of Kali, but in Backtrack, yes, the order in which you performed the settings did matter. Won't hurt to try.

Confirm.

iwlist mon0 channel

If that failed, another option is to change channels using airmon-ng.

airmon-ng start wlan0 1

One more alternative is with airodump-ng, subsequent to creating a mon interface; which of course will also display traffic.

airodump-ng --channel 1 mon0

I have a feeling this final trick will do the job, but try the previous methods first. Run a command to kill background processes that sometimes interfere with aircrack's channel switching, including the well-known "-1 channel" error. The warning airmon-ng gave in your example includes the processes.

airmon-ng check kill

That command will take down network-manager, dhclient and/or all associated processes known to interfere with aircrack. Then try switching channels again using iwconfig. Your network connection will terminate, so if this is leading up to a MITM simulation, you'll need to take that into account.

service network-manager restart

...will bring network-manager back up again when you're finished.

As for MDK, I'm not sure if you need to know that software specifically for your testing, but aircrack suite has a tool called airbase-ng which offers the same capabilities as MDK, as far as creating a soft AP. I'd try MDK again after running the 'check kill' in airmon-ng, just to see.

Sorry I can't answer your question as to 'why'. If you query aircrack's monitor mode channel issues, there's tons of info regarding the channel -1 problem, but dig deeper and you'll find it's also related to similar problems users have had, such as yours.

It's been a while, hope you were able to duplicate the tests though. Maybe this'll helps others anyway.

Is the instructor using a virtual environment also? If not, you may need to deviate from the exact steps he's using. Just an initial thought. Your output looks fine though.

I have a feeling you need to kill the network processes, that airmon-ng displayed, but I'd try other options first.

Stop monitor modes if any, change interface channel, then enter monitor mode. [wlan0 and mon0 will be your own interfaces]. Since it's a USB card, I'd personally go so far as to remove it and plug it back in. Make sure VM settings are kosher. Then bring it up. In Kali, ifconfig options should be up|down ie [ifconfig wlan0 up] I'm only including that because I think that's what Sergej intended, but put 'stop'.

airmon-ng stop mon0
iwconfig wlan0 channel 1
airmon-ng start wlan0

I'm not sure of Kali, but in Backtrack, yes, the order in which you performed the settings did matter. Won't hurt to try.

Confirm.

iwlist mon0 channel

If that failed, another option is to change channels using airmon-ng.

airmon-ng start wlan0 1

One more alternative is with airodump-ng, subsequent to creating a mon interface; which of course will also display traffic.

airodump-ng --channel 1 mon0

I have a feeling this final trick will do the job, but try the previous methods first. Run a command to kill background processes that sometimes interfere with aircrack's channel switching, including the well-known "-1 channel" error. The warning airmon-ng gave in your example includes the processes.

airmon-ng check kill

That command will take down network-manager, dhclient and/or all associated processes known to interfere with aircrack. Then try switching channels again using iwconfig. Your network connection will terminate, so if this is leading up to a MITM simulation, you'll need to take that into account.

service network-manager restart

...will bring network-manager back up again when you're finished.

As for MDK, I'm not sure if you need to know that software specifically for your testing, but aircrack suite has a tool called airbase-ng which offers the same capabilities as MDK, as far as creating a soft AP. I'd try MDK again after running the 'check kill' in airmon-ng, just to see.

Sorry I can't answer your question as to 'why'. If you query aircrack's monitor mode channel issues, there's tons of info regarding the channel -1 problem, but dig deeper and you'll find it's also related to similar problems users have had, such as yours.

EDIT: Stopping processes isn't a fix and I don't like recommending such things, so I found this patch that may actually FIX the problem that the OP encountered. Patch

It's been a while, hope you were able to duplicate the tests though. Maybe this'll helps others anyway.

Source Link

Is the instructor using a virtual environment also? If not, you may need to deviate from the exact steps he's using. Just an initial thought. Your output looks fine though.

I have a feeling you need to kill the network processes, that airmon-ng displayed, but I'd try other options first.

Stop monitor modes if any, change interface channel, then enter monitor mode. [wlan0 and mon0 will be your own interfaces]. Since it's a USB card, I'd personally go so far as to remove it and plug it back in. Make sure VM settings are kosher. Then bring it up. In Kali, ifconfig options should be up|down ie [ifconfig wlan0 up] I'm only including that because I think that's what Sergej intended, but put 'stop'.

airmon-ng stop mon0
iwconfig wlan0 channel 1
airmon-ng start wlan0

I'm not sure of Kali, but in Backtrack, yes, the order in which you performed the settings did matter. Won't hurt to try.

Confirm.

iwlist mon0 channel

If that failed, another option is to change channels using airmon-ng.

airmon-ng start wlan0 1

One more alternative is with airodump-ng, subsequent to creating a mon interface; which of course will also display traffic.

airodump-ng --channel 1 mon0

I have a feeling this final trick will do the job, but try the previous methods first. Run a command to kill background processes that sometimes interfere with aircrack's channel switching, including the well-known "-1 channel" error. The warning airmon-ng gave in your example includes the processes.

airmon-ng check kill

That command will take down network-manager, dhclient and/or all associated processes known to interfere with aircrack. Then try switching channels again using iwconfig. Your network connection will terminate, so if this is leading up to a MITM simulation, you'll need to take that into account.

service network-manager restart

...will bring network-manager back up again when you're finished.

As for MDK, I'm not sure if you need to know that software specifically for your testing, but aircrack suite has a tool called airbase-ng which offers the same capabilities as MDK, as far as creating a soft AP. I'd try MDK again after running the 'check kill' in airmon-ng, just to see.

Sorry I can't answer your question as to 'why'. If you query aircrack's monitor mode channel issues, there's tons of info regarding the channel -1 problem, but dig deeper and you'll find it's also related to similar problems users have had, such as yours.

It's been a while, hope you were able to duplicate the tests though. Maybe this'll helps others anyway.