| Message ID | 1416754941-4439-1-git-send-email-arik@wizery.com (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
On Sun, Nov 23, 2014 at 05:02:19PM +0200, Arik Nemtsov wrote: > When the regulatory settings change, some channels might become invalid. > Disconnect interfaces acting on these channels, after giving userspace > code a grace period to leave them. > > This mode is currently opt-in, and not all interface operating modes are > supported for regulatory-enforcement checks. A wiphy that wishes to use > the new enforcement code must specify an appropriate regulatory flag, > and all its supported interface modes must be supported by the chekcing > code. This is all looking beter now, since I had a few requests for the last patch I'll ask for some other things here without asking to negage the flag purpose as I originally wanted. > Signed-off-by: Arik Nemtsov <arikx.nemtsov@intel.com> > --- > include/net/regulatory.h | 6 +++ > net/wireless/core.c | 13 ++++++ > net/wireless/reg.c | 106 ++++++++++++++++++++++++++++++++++++++++++++++- > 3 files changed, 124 insertions(+), 1 deletion(-) > > diff --git a/include/net/regulatory.h b/include/net/regulatory.h > index dad7ab2..701177c 100644 > --- a/include/net/regulatory.h > +++ b/include/net/regulatory.h > @@ -136,6 +136,11 @@ struct regulatory_request { > * otherwise initiating radiation is not allowed. This will enable the > * relaxations enabled under the CFG80211_REG_RELAX_NO_IR configuration > * option > + * @REGULATORY_ENFORCE_CHANNELS: the regulatory core will make sure all > + * interfaces on this wiphy reside on allowed channels. Upon a regdomain > + * change, the interfaces are given a grace period to disconnect or move > + * to an allowed channels. Interfaces on forbidden channels are forcibly > + * disconnected. Please rename to REGULATORY_IGNORE_STALE_KICKOFF, also please add some information about the amount current of grace period used, and types of interfaces supported. Since this is a regulatory flag this information will help folks decide whether to enable or not. Also encourage its use, and mention that once all supported devices get support for this will be enabled by default. In the meantime I'd prefer if this feature was enabled by default if the supported interface types of a dveice match the white list of supported interfaces. Luis -- 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 Tue, Nov 25, 2014 at 9:38 PM, Luis R. Rodriguez <mcgrof@suse.com> wrote: > > Please rename to REGULATORY_IGNORE_STALE_KICKOFF, also please add > some information about the amount current of grace period used, > and types of interfaces supported. Since this is a regulatory flag > this information will help folks decide whether to enable or not. > Also encourage its use, and mention that once all supported devices > get support for this will be enabled by default. In the meantime > I'd prefer if this feature was enabled by default if the supported > interface types of a dveice match the white list of supported > interfaces. Will do. Arik -- 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 Tue, Nov 25, 2014 at 9:38 PM, Luis R. Rodriguez <mcgrof@suse.com> wrote: > On Sun, Nov 23, 2014 at 05:02:19PM +0200, Arik Nemtsov wrote: >> When the regulatory settings change, some channels might become invalid. >> Disconnect interfaces acting on these channels, after giving userspace >> code a grace period to leave them. >> >> This mode is currently opt-in, and not all interface operating modes are >> supported for regulatory-enforcement checks. A wiphy that wishes to use >> the new enforcement code must specify an appropriate regulatory flag, >> and all its supported interface modes must be supported by the chekcing >> code. > > This is all looking beter now, since I had a few requests for the last patch > I'll ask for some other things here without asking to negage the flag purpose > as I originally wanted. > >> Signed-off-by: Arik Nemtsov <arikx.nemtsov@intel.com> >> --- >> include/net/regulatory.h | 6 +++ >> net/wireless/core.c | 13 ++++++ >> net/wireless/reg.c | 106 ++++++++++++++++++++++++++++++++++++++++++++++- >> 3 files changed, 124 insertions(+), 1 deletion(-) >> >> diff --git a/include/net/regulatory.h b/include/net/regulatory.h >> index dad7ab2..701177c 100644 >> --- a/include/net/regulatory.h >> +++ b/include/net/regulatory.h >> @@ -136,6 +136,11 @@ struct regulatory_request { >> * otherwise initiating radiation is not allowed. This will enable the >> * relaxations enabled under the CFG80211_REG_RELAX_NO_IR configuration >> * option >> + * @REGULATORY_ENFORCE_CHANNELS: the regulatory core will make sure all >> + * interfaces on this wiphy reside on allowed channels. Upon a regdomain >> + * change, the interfaces are given a grace period to disconnect or move >> + * to an allowed channels. Interfaces on forbidden channels are forcibly >> + * disconnected. > > Please rename to REGULATORY_IGNORE_STALE_KICKOFF, also please add > some information about the amount current of grace period used, > and types of interfaces supported. Since this is a regulatory flag > this information will help folks decide whether to enable or not. > Also encourage its use, and mention that once all supported devices > get support for this will be enabled by default. In the meantime > I'd prefer if this feature was enabled by default if the supported > interface types of a dveice match the white list of supported > interfaces. btw, I think you meant REGULATORY_STALE_KICKOFF, since it's an opt-in flag. Arik -- 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 Wed, Nov 26, 2014 at 05:06:37PM +0200, Arik Nemtsov wrote: > On Tue, Nov 25, 2014 at 9:38 PM, Luis R. Rodriguez <mcgrof@suse.com> wrote: > > On Sun, Nov 23, 2014 at 05:02:19PM +0200, Arik Nemtsov wrote: > >> When the regulatory settings change, some channels might become invalid. > >> Disconnect interfaces acting on these channels, after giving userspace > >> code a grace period to leave them. > >> > >> This mode is currently opt-in, and not all interface operating modes are > >> supported for regulatory-enforcement checks. A wiphy that wishes to use > >> the new enforcement code must specify an appropriate regulatory flag, > >> and all its supported interface modes must be supported by the chekcing > >> code. > > > > This is all looking beter now, since I had a few requests for the last patch > > I'll ask for some other things here without asking to negage the flag purpose > > as I originally wanted. > > > >> Signed-off-by: Arik Nemtsov <arikx.nemtsov@intel.com> > >> --- > >> include/net/regulatory.h | 6 +++ > >> net/wireless/core.c | 13 ++++++ > >> net/wireless/reg.c | 106 ++++++++++++++++++++++++++++++++++++++++++++++- > >> 3 files changed, 124 insertions(+), 1 deletion(-) > >> > >> diff --git a/include/net/regulatory.h b/include/net/regulatory.h > >> index dad7ab2..701177c 100644 > >> --- a/include/net/regulatory.h > >> +++ b/include/net/regulatory.h > >> @@ -136,6 +136,11 @@ struct regulatory_request { > >> * otherwise initiating radiation is not allowed. This will enable the > >> * relaxations enabled under the CFG80211_REG_RELAX_NO_IR configuration > >> * option > >> + * @REGULATORY_ENFORCE_CHANNELS: the regulatory core will make sure all > >> + * interfaces on this wiphy reside on allowed channels. Upon a regdomain > >> + * change, the interfaces are given a grace period to disconnect or move > >> + * to an allowed channels. Interfaces on forbidden channels are forcibly > >> + * disconnected. > > > > Please rename to REGULATORY_IGNORE_STALE_KICKOFF, also please add > > some information about the amount current of grace period used, > > and types of interfaces supported. Since this is a regulatory flag > > this information will help folks decide whether to enable or not. > > Also encourage its use, and mention that once all supported devices > > get support for this will be enabled by default. In the meantime > > I'd prefer if this feature was enabled by default if the supported > > interface types of a dveice match the white list of supported > > interfaces. > > btw, I think you meant REGULATORY_STALE_KICKOFF, since it's an opt-in flag. Indeed, the REGULATORY_IGNORE_STALE_KICKOFF would be the inversion, which is really a better way to deal with this but Johannes considered it more work. I'll leave it up to you but if the supported interfaces on a driver work with it we should enable this by default. This is why the inversion (REGULATORY_IGNORE_STALE_KICKOFF) would work better in the end, as we want to keep this on by default and only let folks opt out. Luis -- 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 Wed, Nov 26, 2014 at 5:28 PM, Luis R. Rodriguez <mcgrof@suse.com> wrote: > On Wed, Nov 26, 2014 at 05:06:37PM +0200, Arik Nemtsov wrote: >> On Tue, Nov 25, 2014 at 9:38 PM, Luis R. Rodriguez <mcgrof@suse.com> wrote: >> > On Sun, Nov 23, 2014 at 05:02:19PM +0200, Arik Nemtsov wrote: >> >> When the regulatory settings change, some channels might become invalid. >> >> Disconnect interfaces acting on these channels, after giving userspace >> >> code a grace period to leave them. >> >> >> >> This mode is currently opt-in, and not all interface operating modes are >> >> supported for regulatory-enforcement checks. A wiphy that wishes to use >> >> the new enforcement code must specify an appropriate regulatory flag, >> >> and all its supported interface modes must be supported by the chekcing >> >> code. >> > >> > This is all looking beter now, since I had a few requests for the last patch >> > I'll ask for some other things here without asking to negage the flag purpose >> > as I originally wanted. >> > >> >> Signed-off-by: Arik Nemtsov <arikx.nemtsov@intel.com> >> >> --- >> >> include/net/regulatory.h | 6 +++ >> >> net/wireless/core.c | 13 ++++++ >> >> net/wireless/reg.c | 106 ++++++++++++++++++++++++++++++++++++++++++++++- >> >> 3 files changed, 124 insertions(+), 1 deletion(-) >> >> >> >> diff --git a/include/net/regulatory.h b/include/net/regulatory.h >> >> index dad7ab2..701177c 100644 >> >> --- a/include/net/regulatory.h >> >> +++ b/include/net/regulatory.h >> >> @@ -136,6 +136,11 @@ struct regulatory_request { >> >> * otherwise initiating radiation is not allowed. This will enable the >> >> * relaxations enabled under the CFG80211_REG_RELAX_NO_IR configuration >> >> * option >> >> + * @REGULATORY_ENFORCE_CHANNELS: the regulatory core will make sure all >> >> + * interfaces on this wiphy reside on allowed channels. Upon a regdomain >> >> + * change, the interfaces are given a grace period to disconnect or move >> >> + * to an allowed channels. Interfaces on forbidden channels are forcibly >> >> + * disconnected. >> > >> > Please rename to REGULATORY_IGNORE_STALE_KICKOFF, also please add >> > some information about the amount current of grace period used, >> > and types of interfaces supported. Since this is a regulatory flag >> > this information will help folks decide whether to enable or not. >> > Also encourage its use, and mention that once all supported devices >> > get support for this will be enabled by default. In the meantime >> > I'd prefer if this feature was enabled by default if the supported >> > interface types of a dveice match the white list of supported >> > interfaces. >> >> btw, I think you meant REGULATORY_STALE_KICKOFF, since it's an opt-in flag. > > Indeed, the REGULATORY_IGNORE_STALE_KICKOFF would be the inversion, which > is really a better way to deal with this but Johannes considered it more > work. I'll leave it up to you but if the supported interfaces on a driver > work with it we should enable this by default. This is why the inversion > (REGULATORY_IGNORE_STALE_KICKOFF) would work better in the end, as we want > to keep this on by default and only let folks opt out. I thought we agreed this to be opt-in, even if all interfaces are supported? I still think an untested driver might be hurt by this patch. For instance if it requires a different grace period, etc. Arik -- 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 Wed, Nov 26, 2014 at 10:39 AM, Arik Nemtsov <arik@wizery.com> wrote: > On Wed, Nov 26, 2014 at 5:28 PM, Luis R. Rodriguez <mcgrof@suse.com> wrote: >> On Wed, Nov 26, 2014 at 05:06:37PM +0200, Arik Nemtsov wrote: >>> On Tue, Nov 25, 2014 at 9:38 PM, Luis R. Rodriguez <mcgrof@suse.com> wrote: >>> > On Sun, Nov 23, 2014 at 05:02:19PM +0200, Arik Nemtsov wrote: >>> >> When the regulatory settings change, some channels might become invalid. >>> >> Disconnect interfaces acting on these channels, after giving userspace >>> >> code a grace period to leave them. >>> >> >>> >> This mode is currently opt-in, and not all interface operating modes are >>> >> supported for regulatory-enforcement checks. A wiphy that wishes to use >>> >> the new enforcement code must specify an appropriate regulatory flag, >>> >> and all its supported interface modes must be supported by the chekcing >>> >> code. >>> > >>> > This is all looking beter now, since I had a few requests for the last patch >>> > I'll ask for some other things here without asking to negage the flag purpose >>> > as I originally wanted. >>> > >>> >> Signed-off-by: Arik Nemtsov <arikx.nemtsov@intel.com> >>> >> --- >>> >> include/net/regulatory.h | 6 +++ >>> >> net/wireless/core.c | 13 ++++++ >>> >> net/wireless/reg.c | 106 ++++++++++++++++++++++++++++++++++++++++++++++- >>> >> 3 files changed, 124 insertions(+), 1 deletion(-) >>> >> >>> >> diff --git a/include/net/regulatory.h b/include/net/regulatory.h >>> >> index dad7ab2..701177c 100644 >>> >> --- a/include/net/regulatory.h >>> >> +++ b/include/net/regulatory.h >>> >> @@ -136,6 +136,11 @@ struct regulatory_request { >>> >> * otherwise initiating radiation is not allowed. This will enable the >>> >> * relaxations enabled under the CFG80211_REG_RELAX_NO_IR configuration >>> >> * option >>> >> + * @REGULATORY_ENFORCE_CHANNELS: the regulatory core will make sure all >>> >> + * interfaces on this wiphy reside on allowed channels. Upon a regdomain >>> >> + * change, the interfaces are given a grace period to disconnect or move >>> >> + * to an allowed channels. Interfaces on forbidden channels are forcibly >>> >> + * disconnected. >>> > >>> > Please rename to REGULATORY_IGNORE_STALE_KICKOFF, also please add >>> > some information about the amount current of grace period used, >>> > and types of interfaces supported. Since this is a regulatory flag >>> > this information will help folks decide whether to enable or not. >>> > Also encourage its use, and mention that once all supported devices >>> > get support for this will be enabled by default. In the meantime >>> > I'd prefer if this feature was enabled by default if the supported >>> > interface types of a dveice match the white list of supported >>> > interfaces. >>> >>> btw, I think you meant REGULATORY_STALE_KICKOFF, since it's an opt-in flag. >> >> Indeed, the REGULATORY_IGNORE_STALE_KICKOFF would be the inversion, which >> is really a better way to deal with this but Johannes considered it more >> work. I'll leave it up to you but if the supported interfaces on a driver >> work with it we should enable this by default. This is why the inversion >> (REGULATORY_IGNORE_STALE_KICKOFF) would work better in the end, as we want >> to keep this on by default and only let folks opt out. > > I thought we agreed this to be opt-in, We agreed to not have to require this to be opt-out, that's different than having it enabled by default for supported devices. > even if all interfaces are > supported? I still think an untested driver might be hurt by this > patch. For instance if it requires a different grace period, etc. This is a generic feature and I think its important to enable it by default, if a different grace period can be used it sounds like you can easily fold that in as an alternative to override the default. Luis -- 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 Wed, Nov 26, 2014 at 5:58 PM, Luis R. Rodriguez <mcgrof@suse.com> wrote: > On Wed, Nov 26, 2014 at 10:39 AM, Arik Nemtsov <arik@wizery.com> wrote: >> On Wed, Nov 26, 2014 at 5:28 PM, Luis R. Rodriguez <mcgrof@suse.com> wrote: >>> On Wed, Nov 26, 2014 at 05:06:37PM +0200, Arik Nemtsov wrote: >>>> On Tue, Nov 25, 2014 at 9:38 PM, Luis R. Rodriguez <mcgrof@suse.com> wrote: >>>> > On Sun, Nov 23, 2014 at 05:02:19PM +0200, Arik Nemtsov wrote: >>>> >> When the regulatory settings change, some channels might become invalid. >>>> >> Disconnect interfaces acting on these channels, after giving userspace >>>> >> code a grace period to leave them. >>>> >> >>>> >> This mode is currently opt-in, and not all interface operating modes are >>>> >> supported for regulatory-enforcement checks. A wiphy that wishes to use >>>> >> the new enforcement code must specify an appropriate regulatory flag, >>>> >> and all its supported interface modes must be supported by the chekcing >>>> >> code. >>>> > >>>> > This is all looking beter now, since I had a few requests for the last patch >>>> > I'll ask for some other things here without asking to negage the flag purpose >>>> > as I originally wanted. >>>> > >>>> >> Signed-off-by: Arik Nemtsov <arikx.nemtsov@intel.com> >>>> >> --- >>>> >> include/net/regulatory.h | 6 +++ >>>> >> net/wireless/core.c | 13 ++++++ >>>> >> net/wireless/reg.c | 106 ++++++++++++++++++++++++++++++++++++++++++++++- >>>> >> 3 files changed, 124 insertions(+), 1 deletion(-) >>>> >> >>>> >> diff --git a/include/net/regulatory.h b/include/net/regulatory.h >>>> >> index dad7ab2..701177c 100644 >>>> >> --- a/include/net/regulatory.h >>>> >> +++ b/include/net/regulatory.h >>>> >> @@ -136,6 +136,11 @@ struct regulatory_request { >>>> >> * otherwise initiating radiation is not allowed. This will enable the >>>> >> * relaxations enabled under the CFG80211_REG_RELAX_NO_IR configuration >>>> >> * option >>>> >> + * @REGULATORY_ENFORCE_CHANNELS: the regulatory core will make sure all >>>> >> + * interfaces on this wiphy reside on allowed channels. Upon a regdomain >>>> >> + * change, the interfaces are given a grace period to disconnect or move >>>> >> + * to an allowed channels. Interfaces on forbidden channels are forcibly >>>> >> + * disconnected. >>>> > >>>> > Please rename to REGULATORY_IGNORE_STALE_KICKOFF, also please add >>>> > some information about the amount current of grace period used, >>>> > and types of interfaces supported. Since this is a regulatory flag >>>> > this information will help folks decide whether to enable or not. >>>> > Also encourage its use, and mention that once all supported devices >>>> > get support for this will be enabled by default. In the meantime >>>> > I'd prefer if this feature was enabled by default if the supported >>>> > interface types of a dveice match the white list of supported >>>> > interfaces. >>>> >>>> btw, I think you meant REGULATORY_STALE_KICKOFF, since it's an opt-in flag. >>> >>> Indeed, the REGULATORY_IGNORE_STALE_KICKOFF would be the inversion, which >>> is really a better way to deal with this but Johannes considered it more >>> work. I'll leave it up to you but if the supported interfaces on a driver >>> work with it we should enable this by default. This is why the inversion >>> (REGULATORY_IGNORE_STALE_KICKOFF) would work better in the end, as we want >>> to keep this on by default and only let folks opt out. >> >> I thought we agreed this to be opt-in, > > We agreed to not have to require this to be opt-out, that's different > than having it enabled by default for supported devices. > >> even if all interfaces are >> supported? I still think an untested driver might be hurt by this >> patch. For instance if it requires a different grace period, etc. > > This is a generic feature and I think its important to enable it by > default, if a different grace period can be used it sounds like you > can easily fold that in as an alternative to override the default. Let's not start adding features out of speculation. I was just proving my point. Everything can be easily added, but perhaps not easily predicted. But sure, I can make this default-on if only supported interfaces are present. And for that case, I'll set the flag as opt-out. Arik -- 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 Wed, Nov 26, 2014 at 11:16 AM, Arik Nemtsov <arik@wizery.com> wrote: > On Wed, Nov 26, 2014 at 5:58 PM, Luis R. Rodriguez <mcgrof@suse.com> wrote: >> On Wed, Nov 26, 2014 at 10:39 AM, Arik Nemtsov <arik@wizery.com> wrote: >>> On Wed, Nov 26, 2014 at 5:28 PM, Luis R. Rodriguez <mcgrof@suse.com> wrote: >>>> On Wed, Nov 26, 2014 at 05:06:37PM +0200, Arik Nemtsov wrote: >>>>> On Tue, Nov 25, 2014 at 9:38 PM, Luis R. Rodriguez <mcgrof@suse.com> wrote: >>>>> > On Sun, Nov 23, 2014 at 05:02:19PM +0200, Arik Nemtsov wrote: >>>>> >> When the regulatory settings change, some channels might become invalid. >>>>> >> Disconnect interfaces acting on these channels, after giving userspace >>>>> >> code a grace period to leave them. >>>>> >> >>>>> >> This mode is currently opt-in, and not all interface operating modes are >>>>> >> supported for regulatory-enforcement checks. A wiphy that wishes to use >>>>> >> the new enforcement code must specify an appropriate regulatory flag, >>>>> >> and all its supported interface modes must be supported by the chekcing >>>>> >> code. >>>>> > >>>>> > This is all looking beter now, since I had a few requests for the last patch >>>>> > I'll ask for some other things here without asking to negage the flag purpose >>>>> > as I originally wanted. >>>>> > >>>>> >> Signed-off-by: Arik Nemtsov <arikx.nemtsov@intel.com> >>>>> >> --- >>>>> >> include/net/regulatory.h | 6 +++ >>>>> >> net/wireless/core.c | 13 ++++++ >>>>> >> net/wireless/reg.c | 106 ++++++++++++++++++++++++++++++++++++++++++++++- >>>>> >> 3 files changed, 124 insertions(+), 1 deletion(-) >>>>> >> >>>>> >> diff --git a/include/net/regulatory.h b/include/net/regulatory.h >>>>> >> index dad7ab2..701177c 100644 >>>>> >> --- a/include/net/regulatory.h >>>>> >> +++ b/include/net/regulatory.h >>>>> >> @@ -136,6 +136,11 @@ struct regulatory_request { >>>>> >> * otherwise initiating radiation is not allowed. This will enable the >>>>> >> * relaxations enabled under the CFG80211_REG_RELAX_NO_IR configuration >>>>> >> * option >>>>> >> + * @REGULATORY_ENFORCE_CHANNELS: the regulatory core will make sure all >>>>> >> + * interfaces on this wiphy reside on allowed channels. Upon a regdomain >>>>> >> + * change, the interfaces are given a grace period to disconnect or move >>>>> >> + * to an allowed channels. Interfaces on forbidden channels are forcibly >>>>> >> + * disconnected. >>>>> > >>>>> > Please rename to REGULATORY_IGNORE_STALE_KICKOFF, also please add >>>>> > some information about the amount current of grace period used, >>>>> > and types of interfaces supported. Since this is a regulatory flag >>>>> > this information will help folks decide whether to enable or not. >>>>> > Also encourage its use, and mention that once all supported devices >>>>> > get support for this will be enabled by default. In the meantime >>>>> > I'd prefer if this feature was enabled by default if the supported >>>>> > interface types of a dveice match the white list of supported >>>>> > interfaces. >>>>> >>>>> btw, I think you meant REGULATORY_STALE_KICKOFF, since it's an opt-in flag. >>>> >>>> Indeed, the REGULATORY_IGNORE_STALE_KICKOFF would be the inversion, which >>>> is really a better way to deal with this but Johannes considered it more >>>> work. I'll leave it up to you but if the supported interfaces on a driver >>>> work with it we should enable this by default. This is why the inversion >>>> (REGULATORY_IGNORE_STALE_KICKOFF) would work better in the end, as we want >>>> to keep this on by default and only let folks opt out. >>> >>> I thought we agreed this to be opt-in, >> >> We agreed to not have to require this to be opt-out, that's different >> than having it enabled by default for supported devices. >> >>> even if all interfaces are >>> supported? I still think an untested driver might be hurt by this >>> patch. For instance if it requires a different grace period, etc. >> >> This is a generic feature and I think its important to enable it by >> default, if a different grace period can be used it sounds like you >> can easily fold that in as an alternative to override the default. > > Let's not start adding features out of speculation. I was just proving my point. > Everything can be easily added, but perhaps not easily predicted. OK > But sure, I can make this default-on if only supported interfaces are > present. And for that case, I'll set the flag as opt-out. Thanks for the work. Its highly appreciated. Luis -- 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/include/net/regulatory.h b/include/net/regulatory.h index dad7ab2..701177c 100644 --- a/include/net/regulatory.h +++ b/include/net/regulatory.h @@ -136,6 +136,11 @@ struct regulatory_request { * otherwise initiating radiation is not allowed. This will enable the * relaxations enabled under the CFG80211_REG_RELAX_NO_IR configuration * option + * @REGULATORY_ENFORCE_CHANNELS: the regulatory core will make sure all + * interfaces on this wiphy reside on allowed channels. Upon a regdomain + * change, the interfaces are given a grace period to disconnect or move + * to an allowed channels. Interfaces on forbidden channels are forcibly + * disconnected. */ enum ieee80211_regulatory_flags { REGULATORY_CUSTOM_REG = BIT(0), @@ -144,6 +149,7 @@ enum ieee80211_regulatory_flags { REGULATORY_COUNTRY_IE_FOLLOW_POWER = BIT(3), REGULATORY_COUNTRY_IE_IGNORE = BIT(4), REGULATORY_ENABLE_RELAX_NO_IR = BIT(5), + REGULATORY_ENFORCE_CHANNELS = BIT(6), }; struct ieee80211_freq_range { diff --git a/net/wireless/core.c b/net/wireless/core.c index 4c2e501..5295456 100644 --- a/net/wireless/core.c +++ b/net/wireless/core.c @@ -546,6 +546,19 @@ int wiphy_register(struct wiphy *wiphy) !rdev->ops->tdls_cancel_channel_switch))) return -EINVAL; + /* + * a wiphy that wishes to enable channel enforcement must have only + * modes where enforcement is supported. + */ + if (WARN_ON((wiphy->regulatory_flags & REGULATORY_ENFORCE_CHANNELS) && + (wiphy->interface_modes & ~(BIT(NL80211_IFTYPE_STATION) | + BIT(NL80211_IFTYPE_P2P_CLIENT) | BIT(NL80211_IFTYPE_AP) | + BIT(NL80211_IFTYPE_P2P_GO) | BIT(NL80211_IFTYPE_ADHOC) | + BIT(NL80211_IFTYPE_P2P_DEVICE) | + BIT(NL80211_IFTYPE_AP_VLAN) | + BIT(NL80211_IFTYPE_MONITOR))))) + return -EINVAL; + if (WARN_ON(wiphy->coalesce && (!wiphy->coalesce->n_rules || !wiphy->coalesce->n_patterns) && diff --git a/net/wireless/reg.c b/net/wireless/reg.c index 32d8310..922d00a 100644 --- a/net/wireless/reg.c +++ b/net/wireless/reg.c @@ -56,6 +56,7 @@ #include <net/cfg80211.h> #include "core.h" #include "reg.h" +#include "rdev-ops.h" #include "regdb.h" #include "nl80211.h" @@ -66,6 +67,12 @@ #define REG_DBG_PRINT(args...) #endif +/* + * Grace period we give before making sure all current interfaces reside on + * channels allowed by the current regulatory domain. + */ +#define REG_ENFORCE_GRACE_MS 60000 + /** * enum reg_request_treatment - regulatory request treatment * @@ -210,6 +217,9 @@ struct reg_beacon { struct ieee80211_channel chan; }; +static void reg_check_chans_work(struct work_struct *work); +static DECLARE_DELAYED_WORK(reg_check_chans, reg_check_chans_work); + static void reg_todo(struct work_struct *work); static DECLARE_WORK(reg_work, reg_todo); @@ -1518,6 +1528,95 @@ static void reg_call_notifier(struct wiphy *wiphy, wiphy->reg_notifier(wiphy, request); } +static bool reg_wdev_chan_valid(struct wiphy *wiphy, struct wireless_dev *wdev) +{ + struct ieee80211_channel *ch; + struct cfg80211_chan_def chandef; + struct cfg80211_registered_device *rdev = wiphy_to_rdev(wiphy); + bool ret = true; + + wdev_lock(wdev); + + if (!wdev->netdev || !netif_running(wdev->netdev)) + goto out; + + switch (wdev->iftype) { + case NL80211_IFTYPE_AP: + case NL80211_IFTYPE_P2P_GO: + if (!wdev->beacon_interval) + goto out; + + ret = cfg80211_reg_can_beacon(wiphy, + &wdev->chandef, wdev->iftype); + break; + case NL80211_IFTYPE_STATION: + case NL80211_IFTYPE_P2P_CLIENT: + case NL80211_IFTYPE_ADHOC: + if (!wdev->current_bss || + !wdev->current_bss->pub.channel) + goto out; + + ch = wdev->current_bss->pub.channel; + if (rdev->ops->get_channel && + !rdev_get_channel(rdev, wdev, &chandef)) + ret = cfg80211_chandef_usable(wiphy, &chandef, + IEEE80211_CHAN_DISABLED); + else + ret = !(ch->flags & IEEE80211_CHAN_DISABLED); + break; + case NL80211_IFTYPE_MONITOR: + case NL80211_IFTYPE_AP_VLAN: + case NL80211_IFTYPE_P2P_DEVICE: + /* no enforcement required */ + break; + default: + /* others not implemented for now */ + WARN_ON(1); + break; + } + +out: + wdev_unlock(wdev); + return ret; +} + +static void reg_leave_invalid_chans(struct wiphy *wiphy) +{ + struct wireless_dev *wdev; + struct cfg80211_registered_device *rdev = wiphy_to_rdev(wiphy); + + ASSERT_RTNL(); + + list_for_each_entry(wdev, &rdev->wdev_list, list) + if (!reg_wdev_chan_valid(wiphy, wdev)) + cfg80211_leave(rdev, wdev); +} + +static void reg_check_chans_work(struct work_struct *work) +{ + struct cfg80211_registered_device *rdev; + + REG_DBG_PRINT("Verifying active interfaces after reg change\n"); + rtnl_lock(); + + list_for_each_entry(rdev, &cfg80211_rdev_list, list) + if (rdev->wiphy.regulatory_flags & REGULATORY_ENFORCE_CHANNELS) + reg_leave_invalid_chans(&rdev->wiphy); + + rtnl_unlock(); +} + +static void reg_check_channels(void) +{ + /* + * Give usermode a chance to do something nicer (move to another + * channel, orderly disconnection), before forcing a disconnection. + */ + mod_delayed_work(system_power_efficient_wq, + ®_check_chans, + msecs_to_jiffies(REG_ENFORCE_GRACE_MS)); +} + static void wiphy_update_regulatory(struct wiphy *wiphy, enum nl80211_reg_initiator initiator) { @@ -1557,6 +1656,8 @@ static void update_all_wiphy_regulatory(enum nl80211_reg_initiator initiator) wiphy = &rdev->wiphy; wiphy_update_regulatory(wiphy, initiator); } + + reg_check_channels(); } static void handle_channel_custom(struct wiphy *wiphy, @@ -1976,8 +2077,10 @@ static void reg_process_hint(struct regulatory_request *reg_request) /* This is required so that the orig_* parameters are saved */ if (treatment == REG_REQ_ALREADY_SET && wiphy && - wiphy->regulatory_flags & REGULATORY_STRICT_REG) + wiphy->regulatory_flags & REGULATORY_STRICT_REG) { wiphy_update_regulatory(wiphy, reg_request->initiator); + reg_check_channels(); + } return; @@ -2858,6 +2961,7 @@ void regulatory_exit(void) cancel_work_sync(®_work); cancel_delayed_work_sync(®_timeout); + cancel_delayed_work_sync(®_check_chans); /* Lock to suppress warnings */ rtnl_lock();
When the regulatory settings change, some channels might become invalid. Disconnect interfaces acting on these channels, after giving userspace code a grace period to leave them. This mode is currently opt-in, and not all interface operating modes are supported for regulatory-enforcement checks. A wiphy that wishes to use the new enforcement code must specify an appropriate regulatory flag, and all its supported interface modes must be supported by the chekcing code. Signed-off-by: Arik Nemtsov <arikx.nemtsov@intel.com> --- include/net/regulatory.h | 6 +++ net/wireless/core.c | 13 ++++++ net/wireless/reg.c | 106 ++++++++++++++++++++++++++++++++++++++++++++++- 3 files changed, 124 insertions(+), 1 deletion(-)