| Message ID | 1448303241-27747-5-git-send-email-sojkam1@fel.cvut.cz (mailing list archive) |
|---|---|
| State | Accepted |
| Delegated to: | Johannes Berg |
| Headers | show |
On Mon, 2015-11-23 at 19:27 +0100, Michal Sojka wrote: > Regulatory rules are applied to channels as if the channel is at > least > 20 MHz wide. This is a problem when dealing with 5 and 10 MHz > channels > because side channels of a regulatory rule get disabled even when > they > fall into rule's frequency range. > > This problem was already fixed in commit > 4edd56981c8fbb349b1529a2feaf772636eb1c83, but only for custom > regulatory > domains provided by drivers. Here we fix it also for all other (e.g. > user-supplied) regulatory domains. > > Before that, similar commit was > reverted (e33e2241e272eddc38339692500bd1c7d8753a77) due to it > allowing > running AP on channel 12 in the US regulatory domain. I have checked > that this is not possible with this change: > > # iw reg set US > # iw dev wlan0 interface add wlan0_ap type __ap > # iw dev wlan0_ap set channel 12 > command failed: Invalid argument (-22) > Applied, with some fixups to the commit message :) johannes -- 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
On Mon, Nov 23, 2015 at 07:27:17PM +0100, Michal Sojka wrote: > Regulatory rules are applied to channels as if the channel is at least > 20 MHz wide. This is a problem when dealing with 5 and 10 MHz channels > because side channels of a regulatory rule get disabled even when they > fall into rule's frequency range. > > This problem was already fixed in commit > 4edd56981c8fbb349b1529a2feaf772636eb1c83, but only for custom regulatory > domains provided by drivers. Here we fix it also for all other (e.g. > user-supplied) regulatory domains. > > Before that, similar commit was > reverted (e33e2241e272eddc38339692500bd1c7d8753a77) due to it allowing > running AP on channel 12 in the US regulatory domain. I'm afraid this new patch needs to be reverted as well since it allows active scanning on channel 12 in the US regulatory domain. I.e., every full scan with this commit included results in a Probe Request frame being sent on channel 12.. This 5 and 10 MHz channel case needs to be handled in a way that does not enable 20 MHz channels that go beyond the regdb rule. Channel 12 is 2457-2477 MHz and the regdb rule for US covers 2402-2472 MHz. This used to disable channel 12 correctly, but with this new change, that 5 MHz range going beyond the rule is not noticed and channel 12 gets included even with 20 MHz bandwidth. > I have checked that this is not possible with this change: > > # iw reg set US > # iw dev wlan0 interface add wlan0_ap type __ap > # iw dev wlan0_ap set channel 12 > command failed: Invalid argument (-22) That's not sufficient. Please take a look at a sniffer capture on what goes out when running iw reg set US iw dev wlan0 scan
On Mon, 2015-11-30 at 11:56 +0200, Jouni Malinen wrote: > On Mon, Nov 23, 2015 at 07:27:17PM +0100, Michal Sojka wrote: > > Regulatory rules are applied to channels as if the channel is at > > least > > 20 MHz wide. This is a problem when dealing with 5 and 10 MHz > > channels > > because side channels of a regulatory rule get disabled even when > > they > > fall into rule's frequency range. > > > > This problem was already fixed in commit > > 4edd56981c8fbb349b1529a2feaf772636eb1c83, but only for custom > > regulatory > > domains provided by drivers. Here we fix it also for all other > > (e.g. > > user-supplied) regulatory domains. > > > > Before that, similar commit was > > reverted (e33e2241e272eddc38339692500bd1c7d8753a77) due to it > > allowing > > running AP on channel 12 in the US regulatory domain. > > I'm afraid this new patch needs to be reverted as well since it > allows active scanning on channel 12 in the US regulatory domain. > I.e., every full scan with this commit included results in a Probe > Request frame being sent on channel 12.. > I've dropped it from my tree. johannes -- 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 0a4f548..35eaeeb 100644 --- a/net/wireless/reg.c +++ b/net/wireless/reg.c @@ -1201,11 +1201,6 @@ static uint32_t reg_rule_to_chan_bw_flags(const struct ieee80211_regdomain *regd return bw_flags; } -/* - * Note that right now we assume the desired channel bandwidth - * is always 20 MHz for each individual channel (HT40 uses 20 MHz - * per channel, the primary and the extension channel). - */ static void handle_channel(struct wiphy *wiphy, enum nl80211_reg_initiator initiator, struct ieee80211_channel *chan) @@ -1221,7 +1216,8 @@ static void handle_channel(struct wiphy *wiphy, flags = chan->orig_flags; - reg_rule = freq_reg_info(wiphy, MHZ_TO_KHZ(chan->center_freq)); + reg_rule = __freq_reg_info(wiphy, MHZ_TO_KHZ(chan->center_freq), + MHZ_TO_KHZ(5)); if (IS_ERR(reg_rule)) { /* * We will disable all channels that do not match our
Regulatory rules are applied to channels as if the channel is at least 20 MHz wide. This is a problem when dealing with 5 and 10 MHz channels because side channels of a regulatory rule get disabled even when they fall into rule's frequency range. This problem was already fixed in commit 4edd56981c8fbb349b1529a2feaf772636eb1c83, but only for custom regulatory domains provided by drivers. Here we fix it also for all other (e.g. user-supplied) regulatory domains. Before that, similar commit was reverted (e33e2241e272eddc38339692500bd1c7d8753a77) due to it allowing running AP on channel 12 in the US regulatory domain. I have checked that this is not possible with this change: # iw reg set US # iw dev wlan0 interface add wlan0_ap type __ap # iw dev wlan0_ap set channel 12 command failed: Invalid argument (-22) Cc: Felix Fietkau <nbd@openwrt.org> Signed-off-by: Michal Sojka <sojkam1@fel.cvut.cz> --- net/wireless/reg.c | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-)