From patchwork Wed Jun 10 12:26:13 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Matthias May X-Patchwork-Id: 6578961 X-Patchwork-Delegate: johannes@sipsolutions.net Return-Path: X-Original-To: patchwork-linux-wireless@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 87A81C0020 for ; Wed, 10 Jun 2015 12:26:36 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 8ADC8205D8 for ; Wed, 10 Jun 2015 12:26:35 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id D99C5205E1 for ; Wed, 10 Jun 2015 12:26:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754245AbbFJM0a (ORCPT ); Wed, 10 Jun 2015 08:26:30 -0400 Received: from mail.neratec.com ([46.140.151.2]:61772 "EHLO mail.neratec.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933277AbbFJM0R (ORCPT ); Wed, 10 Jun 2015 08:26:17 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.neratec.com (Postfix) with ESMTP id 67CE8A000E3; Wed, 10 Jun 2015 14:26:14 +0200 (CEST) Received: from mail.neratec.com ([127.0.0.1]) by localhost (mail.neratec.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id Ij-EffJXOl1C; Wed, 10 Jun 2015 14:26:13 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.neratec.com (Postfix) with ESMTP id DB70EA0010C; Wed, 10 Jun 2015 14:26:13 +0200 (CEST) X-Virus-Scanned: amavisd-new at neratec.com Received: from mail.neratec.com ([127.0.0.1]) by localhost (mail.neratec.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id POyJqLbnvDrv; Wed, 10 Jun 2015 14:26:13 +0200 (CEST) Received: from [192.168.11.50] (CHD500279.neratec.local [192.168.11.50]) by mail.neratec.com (Postfix) with ESMTPSA id B9080A000E3; Wed, 10 Jun 2015 14:26:13 +0200 (CEST) Message-ID: <55782CE5.9010300@neratec.com> Date: Wed, 10 Jun 2015 14:26:13 +0200 From: Matthias May User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0 MIME-Version: 1.0 To: Johannes Berg CC: linux-wireless@vger.kernel.org Subject: Re: [PATCH] cfg80211: check correct maximum bandwidth for quarter and half rate. References: <1433863625-30579-1-git-send-email-matthias.may@neratec.com> (sfid-20150609_173523_482237_45077999) <1433881789.1892.29.camel@sipsolutions.net> In-Reply-To: <1433881789.1892.29.camel@sipsolutions.net> Sender: linux-wireless-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, T_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 On 09/06/15 22:29, Johannes Berg wrote: > On Tue, 2015-06-09 at 17:27 +0200, Matthias May wrote: >> When using quarter and half rates we might want to use self defined >> frequencies with self defined country codes closer to the border. >> To avoid these frequencies to be disabled, we need to check if >> the frequency fits the band with the actual bandwidth. >> +++ b/net/wireless/reg.c >> @@ -1016,6 +1016,7 @@ freq_reg_info_regd(struct wiphy *wiphy, u32 center_freq, >> for (i = 0; i < regd->n_reg_rules; i++) { >> const struct ieee80211_reg_rule *rr; >> const struct ieee80211_freq_range *fr = NULL; >> + u32 max_bw = MHZ_TO_KHZ(20); >> >> rr = ®d->reg_rules[i]; >> fr = &rr->freq_range; >> @@ -1028,8 +1028,10 @@ freq_reg_info_regd(struct wiphy *wiphy, u32 center_freq, >> */ >> if (!band_rule_found) >> band_rule_found = freq_in_rule_band(fr, center_freq); >> + if (fr->max_bandwidth_khz < max_bw) >> + max_bw = fr->max_bandwidth_khz; >> >> - bw_fits = reg_does_bw_fit(fr, center_freq, MHZ_TO_KHZ(20)); >> + bw_fits = reg_does_bw_fit(fr, center_freq, max_bw); > So the old code here assumes 20 MHz channel bandwidth, which was > reasonable until 5/10 MHz were supported. > > However, your change looks very odd. > > Consider a situation where for some reason you have a regulatory domain > without 20 MHz channels at all, only allowing a max bandwidth of 10 MHz. > Then, this code will cause all checks for "channels" to be erroneously > successful, since you're not really checking the request against the > regd. > > What's needed instead is to actually pass in the requested bandwidth > from the caller. Additionally, it seems that at least the caller in > handle_channel_custom() must loop through the available bandwidths > (5/10/20) and disable those that don't fit, instead of disabling the > channel if 20 MHz doesn't fit. > > johannes > Hi The scenario you describe, is actually what i'm working on. I have some self defined country codes and some self defined frequencies. Constructed scenario: I run a single 5Mhz wide channel on the frequency 5175. I created a dummy countrycode XS which only allows 5MHz wide channels. root@RM2:~# iw reg get country XS: DFS-UNSET (5172 - 5247 @ 5), (N/A, 15), (N/A) Without the patch the channel 5175 and 5180 would be disabled because the check sees that 20MHz won't fit. I'm not sure what exactly you mean that the handle_channel_custom needs to loop through 5/10/20. The freq_reg_info_regd sets the disabled flag on the channel at init. This is not while trying to start operation on a channel, because the channel is already disabled. Or do you mean to actually have different sets of flags for the different bandwidths? I see that it's erroneously possible to run a 10/20MHz channel on 5175, even though this shouldn't be allowed. However setting the proper flags bw_flags should fix this. Expanding the patch with the patch below ensures that one can't start operation on a channel which it's not allowed on. Or is there a better way? if (max_bandwidth_khz < MHZ_TO_KHZ(160)) Matthias --- 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/net/wireless/reg.c b/net/wireless/reg.c index c8fabda..4f96563 100644 --- a/net/wireless/reg.c +++ b/net/wireless/reg.c @@ -1139,9 +1139,12 @@ static void handle_channel(struct wiphy *wiphy, /* Check if auto calculation requested */ if (reg_rule->flags & NL80211_RRF_AUTO_BW) max_bandwidth_khz = reg_get_max_bandwidth(regd, reg_rule); - + if (max_bandwidth_khz < MHZ_TO_KHZ(10)) + bw_flags = IEEE80211_CHAN_NO_10MHZ; + if (max_bandwidth_khz < MHZ_TO_KHZ(20)) + bw_flags |= IEEE80211_CHAN_NO_20MHZ; if (max_bandwidth_khz < MHZ_TO_KHZ(40)) - bw_flags = IEEE80211_CHAN_NO_HT40; + bw_flags |= IEEE80211_CHAN_NO_HT40; if (max_bandwidth_khz < MHZ_TO_KHZ(80)) bw_flags |= IEEE80211_CHAN_NO_80MHZ; if (max_bandwidth_khz < MHZ_TO_KHZ(160)) @@ -1575,8 +1578,12 @@ static void handle_channel_custom(struct wiphy *wiphy, if (reg_rule->flags & NL80211_RRF_AUTO_BW) max_bandwidth_khz = reg_get_max_bandwidth(regd, reg_rule); + if (max_bandwidth_khz < MHZ_TO_KHZ(10)) + bw_flags = IEEE80211_CHAN_NO_10MHZ; + if (max_bandwidth_khz < MHZ_TO_KHZ(20)) + bw_flags |= IEEE80211_CHAN_NO_20MHZ; if (max_bandwidth_khz < MHZ_TO_KHZ(40)) - bw_flags = IEEE80211_CHAN_NO_HT40; + bw_flags |= IEEE80211_CHAN_NO_HT40; if (max_bandwidth_khz < MHZ_TO_KHZ(80)) bw_flags |= IEEE80211_CHAN_NO_80MHZ;