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).
> 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.
> 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. There's an additional issue about what happens
when we are in the middle of a bgscan and new tx traffic appears.
> 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.
--
Paul
--
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
