Re: issues with scanning in mac80211

[Helmut Schaa <helmut.schaa@googlemail.com>]

Am Friday 27 August 2010 schrieb Helmut Schaa:
> Am Thursday 26 August 2010 schrieb Luis R. Rodriguez:
> > Massaging this message a bit and putting it on the public
> > mailing list.
> > 
> > On Thu, Aug 26, 2010 at 01:14:36PM -0700, Amod Bodas wrote:
> > > Thanks Jouni. Even my observations are same i.e I see 1 sec or
> > > so scan before returning to home channel. Given background scan
> > > issue looks to be mac80211 related.
> > >
> > > Who is lead scan module expert in the community?
> > 
> > Well Helmut worked on it:
> > 
> > Author: Helmut Schaa <Helmut.Schaa@gmx.de>
> > Date:   Wed Feb 24 14:19:21 2010 +0100
> > 
> >     mac80211: Improve software scan timing
> >     
> >     The current software scan implemenation in mac80211 returns to the operating
> >     channel after each scanned channel. However, in some situations (e.g. no
> >     traffic) it would be nicer to scan a few channels in a row to speed up
> >     the scan itself.
> >     
> >     Hence, after scanning a channel, check if we have queued up any tx frames and
> >     return to the operating channel in that case.
> >     
> >     Unfortunately we don't know if the AP has buffered any frames for us. Hence,
> >     scan only as many channels in a row as the pm_qos latency and the negotiated
> >     listen interval allows us to.
> >     
> >     Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
> >     Signed-off-by: John W. Linville <linville@tuxdriver.com>
> > 
> > but AFAICT the issues documented below were likely not considered into the
> > architecture and its the first time I see them pointed out, unless I missed
> > something. 
> 
> The current implementation never intended to do proper DTIM beacon handling, it
> is only considering unicast traffic. And it tries to stay away of the operating
> channel as long as possible (listen_interfal & pm_qos latency). 
> 
> Changing that would require a bit of work. The delayed_work scheduling needs to
> take into account when the next DTIM beacon is expected and we most likely need
> to shorten the time for a passive channel based on the expected time we've got
> left. Furthermore, we need to know how long the channel switch will take (we
> had something like that but not anymore ...).

Oh, and that's gonna get a bit more difficult in scenarios with multiple STA
interfaces.