Kismet Wireless

Kismet Forums

 

Posted by:bazaari
Subject:It seems that I have solve the problem that kismet can run only for a few minuts
Date:01:16:37 02/11/2007

> Can you explain what is happening and why calling the ath_hal_reset funtion twice fixes/works around the problem?
When calling the ath_hal_reset function twice,the kismet will continually works and the STOPING CAPTURE PACKET phenomenon will not happen again.
I am not completely sure why this could fixed the problem.But I GUESEE it the bug of the ath_hal or the hardware.When the channel changed frequently very much,some registers especially the registers which could produce the interrupt to tell the arrival of the packet will be invalidated and so the kismet could not get any packet.They need to be reseted.We have traced that when Kismet do not capture any packet, the correspond interrupt function (which is ath_rx_tasklet()) of the madwifi will not be called. So I add the ath_hal_reset function.
As the message I posted before, this probem will happen in a few cards not all.
> Also, your code seems to have no semicolon at the end of the statement. Did you intend to make the following "if" statement contingent on the return?
Maybe I have gived a mixed post.Actually, I add the code as follow:
///////////////////////////////////////////////////////////////////////////
if (!ath_hal_reset(ah, sc->sc_opmode, &hchan, AH_TRUE, &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;
}

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 call ath_hal_reset function twice. The first one is the called by madwifi originally and the second one is added by me.The difference is that the paremete of "_outdoor".In the first one, it is TRUE,but in the second, it is FALSE.I am not sure why setting to TRUE not works and setting to FALSE is OK.
I am looking for the reasonable explaination too.
Wish these will be help to you.
> As posted the code will execute like this:
> if (!ath_hal_reset(ah, sc->sc_opmode, &hchan, AH_TRUE, &status))
> if (sc->sc_softled)
> ath_hal_gpioCfgOutput(ah, sc->sc_ledpin);
>
> Is that the intent?
>
> > 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;
> > }
> > ///////////////////////////////////////////////////
> > These codes follows "if (!ath_hal_reset(ah, sc->sc_opmode, &hchan, AH_TRUE, &status))",which reset the ath_hal.
> >
> > Thank you to dragor again. Thanks for your advices and your tiny patients.


Reply to this message