On Fri, Oct 8, 2010 at 5:08 PM, Paul Stewart <pstew@xxxxxxxxxx> wrote:
> On Fri, Oct 8, 2010 at 12:54 PM, Luis R. Rodriguez <mcgrof@xxxxxxxxx> wrote:
>> We spoke about how to handle broadcast / multicast frames when going
>> offchannel at the Wireless Summit [1]. A lot of these talks were lead
>> due to a Chrome side open bug [2].
>
> Thanks for getting the ball rolling, Luis. ÂTechnically the bug is in
> ChromumOS ("Chrome" is a web browser).
Heh, yeah sorry.
>> Userspace may want to force a roam when this deadzone event hits.
>
> Why not just disassociate at this point? ÂI'm not sure what the
> difference is between a "dead zone" situation and a reason to
> completely disconnect.
Not sure what is best, but one reason for considering to just roam is
we are at least getting data while we roam. I hope we can iron out the
best algorithm through this thread.
>> Once we have these two in place we can then ignore bgscan requests
>> (when associated) unless a force scan command has been issued by
>> userspace, or unless we are idle.
>
> By "ignore" do you mean "postpone" or or "return an appropriate error
> to userspace"? ÂEither of those are acceptable. ÂNot doing anything at
> all wouldn't be good.
Good questions. If we postpone it means we end up queuing up all these
scan requests, unless we only let a few queue up, or just one?
> There's an additional issue about what happens
> when we are in the middle of a bgscan and new tx traffic appears.
We can force going back on channel in this case I think.
>> In the worst case scenario and unfortunately this seems to be the most
>> common one, a DTIM of 1 is used and we will have to be on channel and
>> awake every beacon interval. In this case we may want to optimize scan
>> time by not scanning passive scan channels.
>
> A compromise would be to go off-channel for less than a full beacon
> interval when doing background passive channel scans in DTIM=1
> networks. ÂIt's certainly better than (a) not scanning at all and (b)
> arguably better than intentionally dropping mcast. ÂAn 80% beacon-time
> passive listen will get you 80% of the beacons, assuming linear
> probability, and even more over time if you account for beacon skew
> between networks.
Sure it just also means our bgscans can take up ages, if they take up
ages and we queue up a few of them then we can get a backlog of
requests from userspace agents. I suppose we need to figure out this
fine line. But yeah -- you're right, we can do scanning for less than
a beacon interval if DTIM is 1. This can mean 1024 TUs, not sure how
long it takes for us to do a passive scan, this likely is
radio/chipset specific so we'd have to add those values maybe to the
wiphy characteristics. Worth trying and seeing if its possible.
Luis
--
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
