airodump-ng stop working after 30 min

[guardianx]

i dont know what the problem is but airodump- will stop capturing the data after 30 min or so .. i have to remove the wireless air with
airmon-ng stop ath0
airmon-ng start wifi0
and airodump will work again .. and it will stop working after 30-45 min?
does anyone know what is going on?

i updated to the latest madwifi
and used .9 of the aircrack suite.

[-=Xploitz=-]

1.

Do you have any power saving settings on? If so , disable them all.

2.

I also have heard that you can't have the wireless assistant on as well, as that causes connection problems like your experiencing. So turn that off as well.


EDIT:....


Also ensure that all connection managers are killed off. This can cause problems as well.

If possible, try the 1.0dev version and see if that fixes the problem.




1. Madwifi-ng known issue: after some time (can be 5 minutes or 50 minutes or more), it doesn't report a packet anymore, you have to unload and reload all modules
2. When Airodump-ng doesn't get a packet from a client/AP anymore, it is removed from the screen after some time (but still shown in text file)



Hopefully, with luck, one of these ideas will fix your problem..

[ExitOnly@]

Yes, this happens for me time to time (amadwifi-ng latest and aircrack-ng 1.0dev latest), reloading the drivers helps.

[guardianx]

1.

Do you have any power saving settings on? If so , disable them all.

2.

I also have heard that you can't have the wireless assistant on as well, as that causes connection problems like your experiencing. So turn that off as well.


EDIT:....


Also ensure that all connection managers are killed off. This can cause problems as well.

If possible, try the 1.0dev version and see if that fixes the problem.

i dont have any power setting so that takes care of that. but the wireless assistant was on.. how do i turn it off ?

[shamanvirtuel]

the little cross on your right up in wlan assistant (yes the cross to CLOSE !!!) LOL

[guardianx]

the little cross on your right up in wlan assistant (yes the cross to CLOSE !!!) LOL

oh it wasnt running at that time. I thought updating aircrack to 1.0 would fix the problem but it didnt

[balding_parrot]

oh it wasnt running at that time. I thought updating aircrack to 1.0 would fix the problem but it didnt

Check wlassistant isn't running in the background, and kill it if it is.

[chrisrace]

I have the same probs as mentioned here and in other posts (Kismet stops capturing packets after a few seconds, a few minutes --> whenever it wants )

I tested a small workaround (also posted here in the forum) with continous commands like "iwpriv ath0 sleep 0" I put in a script, but I wonder if there's another (better ?) way...

By googling around I found this message on w*w*w.kismetwireless.net/Forum/General/Messages/1193299906.832582 :

With the help of our clever colleagues, it seems that I have found the reasons.
If we do the channel change quickly(for example, 10 times per second), madwifi could not recieve any packet.
After an almost exhaustive experiment, we found that this will occur in some cards with some kind of atheros chipset except for the ones with atheros super AG chipset.
The reason is in the driver of madwifi(of course we use the newest version of madwifi).
We add these code in the function of "ath_chan_set",and the problem seems disappear.
///////////////////////////////////////////////////
if (!ath_hal_reset(ah, sc->sc_opmode, &hchan, AH_FALSE, &status)) {
printk("%s: %s: unable to reset channel %u (%u MHz) "
"flags 0x%x '%s' (HAL status %u)\n",
dev->name, __func__,
ieee80211_chan2ieee(ic, chan), chan->ic_freq,
hchan.channelFlags,
ath_get_hal_status_desc(status), status);
return -EIO;
}
///////////////////////////////////////////////////

I would like to try this, but I couldn't find the file to edit . Can somebody help me (or do I completely misunderstand the problem...)

Chris

[Plasmator]

Chris,

The madwifi source file is "if_ath.c" at line 7782 to 7790 within the madwifi-0.9.3.3 latest driver.

So it looks like its already incorporated in the latest driver. You just have to compile and load it.

Maybe someone can help us with this part ...
.

[Cybersqu]

I've actually had this happen to me on many occasions, and I've found that locking airodump on a specific channel # helps.. Using the -c<channel#> flag usually does the trick.

Also, I've been told by owners of my same card(AR5005GS) that airmon-ng sometimes doesn't work as intended, which I've also noticed. airmon-ng uses iwconfig to create the interface, i've been told to use wlanconfig instead. I don't know if it makes a difference with others, but it did with me. (can anyone else confirm this?)

I manualy add my interface in monitor mode like this:

wlanconfig ath0 destroy # if the interface exists already
wlanconfig ath0 create wlandev wifi0 wlanmode monitor
ifconfig ath0 up