Kismet Wireless

Kismet Forums


Posted by:smaskell
Subject:It seems that I have solve the problem that kismet can run only for a few minuts
Date:21:44:38 01/11/2007

Can you explain what is happening and why calling the ath_hal_reset funtion twice fixes/works around the problem?

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?
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