But mac80211 also does beacon loss detection. I'd much prefer more aggressive (shorter timeout) beacon loss parameters (perhaps configured that way only after end-of-scan, although I believe in general the timeout is rather generous even for the normal case) than to require round-trips with the AP just to find out if it's there. For the most part, I think beacons do the job of AP presence detection fairly well. -- Paul On Mon, Sep 20, 2010 at 3:13 PM, Dan Williams <dcbw@xxxxxxxxxx> wrote: > On Fri, 2010-09-17 at 20:01 -0700, Paul Stewart wrote: >> I found a small bit of behavior related in some vague way to >> connection monitoring: During the scan-completed notification >> (ieee80211_mlme_notify_scan_completed) we call >> ieee80211_restart_sta_timer() on all our interfaces, which in turn >> queues up the &ifmgd->monitor_work, which does a probe request of our >> AP. Why should we do a probe request of your associated AP every time >> a scan completes? Wouldn't the other active monitoring schemes (like >> beacon loss) be sufficient for a "scan finished" condition? > > One reason I can think of is to quickly determine whether your AP is > still around and active given that you may have just been off-channel > for a significant period of time. Not all drivers background scan yet. > But with any sane driver, you'd have already sent your "no longer in > powersave mode" NULL packet to the AP right after finishing the scan, so > perhaps the probe is redundant. > > Dan > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-wireless" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
