From patchwork Wed Feb 5 10:20:20 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Blaise Gassend X-Patchwork-Id: 3585541 Return-Path: X-Original-To: patchwork-linux-wireless@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 293A39F2E9 for ; Wed, 5 Feb 2014 10:21:05 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 07B6A20181 for ; Wed, 5 Feb 2014 10:21:04 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id DF52920163 for ; Wed, 5 Feb 2014 10:21:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751316AbaBEKUn (ORCPT ); Wed, 5 Feb 2014 05:20:43 -0500 Received: from mail-pa0-f41.google.com ([209.85.220.41]:62810 "EHLO mail-pa0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751118AbaBEKUl (ORCPT ); Wed, 5 Feb 2014 05:20:41 -0500 Received: by mail-pa0-f41.google.com with SMTP id fa1so185745pad.0 for ; Wed, 05 Feb 2014 02:20:41 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=v/auVItwW07DnWEsN0PuiAXBSPFSYp76CLrYLTUrGts=; b=iwycwwCtXLThUD7/QE4UrI1y7UWZBumqOA4qiu4VX8LZx2jpqj8kj0b/BLgIiFUcgI DUFGnu+urzBWModWzq5j7uI5W2kidqPIXugT3tE3OlTirK5Or1VcYc8QaQM6Dt8RxnCa diEKo8kov21csxa7KJUH2OW7N0pa8D+6/cL/iKMewLpsz+WPebPANajkDXJ46ZzecRNP ibCWngOYGjPLi8FZNWyvTvSTcKPYHJOxENwiamrsO2aDXI95cGoy1BYdab+Yk3JkIUgF IxzWt7sdC3KhoAnImYxUTFwrTPq/UNDkTWG8FdncKXJ9R+IoXGGWpe6ZGMiAD2IoKEjG OD3Q== X-Gm-Message-State: ALoCoQnwrUAkYi4Dd29a1Jl2YNgWHTVyx1rlKN5SYeQ920ahf5ywMOIiSpg0NL/ltxyy6vbXew0A X-Received: by 10.66.148.230 with SMTP id tv6mr648273pab.155.1391595640900; Wed, 05 Feb 2014 02:20:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.70.1.81 with HTTP; Wed, 5 Feb 2014 02:20:20 -0800 (PST) In-Reply-To: References: From: Blaise Gassend Date: Wed, 5 Feb 2014 02:20:20 -0800 Message-ID: Subject: Re: [RFC] Allow active scanning while associated with custom world regulatory domain To: linux-wireless@vger.kernel.org, Catalin Drula Sender: linux-wireless-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org X-Spam-Status: No, score=-7.4 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP An alternative proposal that just came to mind: It appears that only world regulatory domains actually have IEEE80211_CHAN_PASSIVE_SCAN set. Given that this is the case, why not allow beacon hints to work no matter what the regulatory domain is? The only case where you have IEEE80211_CHAN_PASSIVE_SCAN on a non-world regulatory domain is when you have merged a world regulatory domain into a country IE regulatory domain. In that case, continuing to use beacon hints to remove IEEE80211_CHAN_PASSIVE_SCAN seems legitimate, since that flag was set by the world regulatory domain side of the merge. On Wed, Feb 5, 2014 at 2:12 AM, Blaise Gassend wrote: > Hi Folks, > > I have noticed that with the ath9k boards I use, I am unable to do > active scanning while associated. > > I have tracked down the problem to the following causes: > > 1. The ath9k driver has a custom regulatory domain. It is a world > regulatory domain that has passive scanning > (IEEE80211_CHAN_PASSIVE_SCAN) on most (all?) of the 5GHz band. > > 2. When I associate, that world regulatory domain is merged with the > country IE regulatory domain to determine what the actual regulatory > domain should be. As part of this merge, the channel flags are ORed > together, so most of the 5GHz band ends up having > IEEE80211_CHAN_PASSIVE_SCAN. > > 3. When I am associated to an AP with a non-world regulatory domain, > regulatory hints are disabled so there is no mechanism to clear > IEEE80211_CHAN_PASSIVE_SCAN (as there was when I was unassociated and > operating on the driver's world regulatory domain). > > This is particularly annoying if you are on a hidden SSID and you are > trying to use multiple interfaces, or if you are trying to do > background scanning to roam to a different BSS, as it is now > impossible to send out the probe requests you need to see BSSes for > your SSID. > > I'd be interested in comments on the patch below. It is based on the > assumption that drivers may need to set a custom regulatory domain to > prevent access to certain channels (if the hardware isn't calibrated > for that channel, for instance), but that a driver never needs to > restrict passive scanning beyond what is allowed by the country IE > regulatory domain. > > So, are there cases where IEEE80211_CHAN_PASSIVE_SCAN is set in > orig_flags, but not for the country IE regulatory domain and where we > actually do want to prevent active scanning after we associate? Any > other flaws in the proposal below? > > Best regards, > Blaise Gassend > > Signed-off-by: Blaise Gassend > diff --git a/modules/backports-20131025/net/wireless/reg.c > b/modules/backports-20131025/net/wireless/reg.c > --- a/modules/backports-20131025/net/wireless/reg.c > +++ b/modules/backports-20131025/net/wireless/reg.c > @@ -837,8 +837,6 @@ static void handle_channel(struct wiphy > > request_wiphy = wiphy_idx_to_wiphy(lr->wiphy_idx); > > - flags = chan->orig_flags; > - > reg_rule = freq_reg_info(wiphy, MHZ_TO_KHZ(chan->center_freq)); > if (IS_ERR(reg_rule)) { > /* > @@ -892,7 +890,16 @@ static void handle_channel(struct wiphy > chan->dfs_state = NL80211_DFS_USABLE; > chan->dfs_state_entered = jiffies; > > - chan->beacon_found = false; > + /* > + * Clear IEEE80211_CHAN_PASSIVE_SCAN from the driver's flags to > + * allow the associated country IE to permit active scanning on > + * frequencies that only allow passive scanning according to the > + * driver's world regulatory domain. Prior to association, beacon > + * hints would enable active scanning on these channels. > + */ > + flags = chan->orig_flags & ~IEEE80211_CHAN_PASSIVE_SCAN; > + > + chan->beacon_found = false; > chan->flags = flags | bw_flags | map_regdom_flags(reg_rule->flags); > chan->max_antenna_gain = > min_t(int, chan->orig_mag, --- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/modules/backports-20131025/net/wireless/reg.c b/modules/backports-20131025/net/wireless/reg.c --- a/modules/backports-20131025/net/wireless/reg.c +++ b/modules/backports-20131025/net/wireless/reg.c @@ -1058,9 +1058,6 @@ static void handle_reg_beacon(struct wip chan->beacon_found = true; - if (!reg_is_world_roaming(wiphy)) - return; - if (wiphy->flags & WIPHY_FLAG_DISABLE_BEACON_HINTS) return;