Return-path: Received: from smtp-out.google.com ([216.239.44.51]:41091 "EHLO smtp-out.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752063Ab0JIAIa (ORCPT ); Fri, 8 Oct 2010 20:08:30 -0400 Received: from kpbe17.cbf.corp.google.com (kpbe17.cbf.corp.google.com [172.25.105.81]) by smtp-out.google.com with ESMTP id o9908UnR007168 for ; Fri, 8 Oct 2010 17:08:30 -0700 Received: from iwn5 (iwn5.prod.google.com [10.241.68.69]) by kpbe17.cbf.corp.google.com with ESMTP id o9908S0r010915 for ; Fri, 8 Oct 2010 17:08:29 -0700 Received: by iwn5 with SMTP id 5so142669iwn.15 for ; Fri, 08 Oct 2010 17:08:28 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: Date: Fri, 8 Oct 2010 17:08:28 -0700 Message-ID: Subject: Re: Roaming / offchannel enhancements for broadcast / multicast frames From: Paul Stewart To: "Luis R. Rodriguez" Cc: linux-wireless , linux-kernel@vger.kernel.org, Matt Smith , Srinivasa Duvvuri , Carolyn Waller , Amod Bodas , David Quan , Bennyam Malavazi , Cliff Holden , Aeolus Yang , Kevin Hayes Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-wireless-owner@vger.kernel.org List-ID: On Fri, Oct 8, 2010 at 12:54 PM, Luis R. Rodriguez 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