Search Linux Wireless

Re: [RFC PATCH v2 1/4] mac80211: decrease execution of the associated timer

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Johannes Berg <johannes@xxxxxxxxxxxxxxxx> writes:

> On Fri, 2009-03-20 at 11:22 +0200, Kalle Valo wrote:
>
>> Now I remember what this test was about. In ieee80211_associated()
>> there are two tests: probe request check after an data idle period
>> (currently 60 secs) and beacon loss check for drivers not supporting
>> filtering (2 secs).
>> 
>> The former test has been originally (even before my beacon filter
>> patches) implemented so that the probe request is sent even though we
>> are receiving beacons. mod_timer() is called only for unicast traffic
>> so that the probe request test will trigger when we are still
>> receiving beacons.
>
> Why would we not want to change that? I don't see a reason to send a
> probe request when we're still receiving beacons. It was meant to be
> used when beacons got lost _during_ a data idle period to verify that
> the AP is still there, afaict.

The original (or current) implementation sends probe requests even
when beacons are received or there is unicast traffic going on. My
patches change this so that the probe request is only sent when there
is data idle period (ie. no unicast traffic).

Like we discussed earlier, I think the most optimal solution would be
to send nullfunc frames during data idle periods just to check that the
connection is working bothways.

What should AP do if it receives a nullfunc frame from a station which
is not associated? Send a deauth frame back to the station? It would
be nice to check the association state also during the data idle
period. Sometimes I have noticed that AP might deauthenticate the
station without station noticing it. It would be just perfect if
nullfunc frame would do the assocition also during data idle periods.

>> I'll add a proper comment explaining all this.
>> 
>> Also currently ieee80211_associated() is called every two seconds, we
>> need to fix this in future to avoid waking up cpu needlessly. I don't
>> want to make too intrusive changes right now.
>
> I thought you already did that too :)

Sorry, I did that only for the period when there is data transmission.
To get rid of unncessary wakeups altogether I need to do something
more advanced, like using two timers or something. I haven't thought
that yet.

I'll mention this in the commit logs.

-- 
Kalle Valo
--
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

[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]
  Powered by Linux