In case no one is occupying a wiphy, all past regulatory data will be lost
as a result of reset to world reg domain.
This includes any channel that is currently in NOP time as well as
in AVAILABLE state.
This means that after detecting a radar on a channel the user might be
able to simply reset hostapd and get back to that channel,
this is a major issue.
To solve this I have added a check before doing any resets.
If the user (for example: hostapd) asks for a regdomain and we are
already in that regdomain, than we shouldn't reset that regdomain in case
of wiphy disconnection (for example: hostapd reset or killed).
That way the regulatory data will be saved as long as we are
in the same regdomain.
Since in that case we will anyway get back to the same regdomain
the only difference is we will now save the regulatory data,
won't lose it, and as a result won't get back to a channel that a radar
was detected on until NOP will be finished, as should be.
Signed-off-by: Orr Mazor <[email protected]>
---
net/wireless/reg.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index d18cc05061a0..5049c487950b 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -3180,6 +3180,16 @@ static void restore_regulatory_settings(bool reset_user, bool cached)
}
spin_unlock(®_indoor_lock);
+ /* If the user asks for a regdomain and we are
+ * already in that regdomain, than we shouldn't reset
+ * the regdomain in the case of wiphy disconnection.
+ */
+ if (cached && !reset_user &&
+ (!IS_ERR_OR_NULL(cfg80211_user_regdom)) &&
+ (!regdom_changes(cfg80211_user_regdom->alpha2))) {
+ return;
+ }
+
reset_regdomains(true, &world_regdom);
restore_alpha2(alpha2, reset_user);
--
2.17.1
On 15/01/2020, Orr Mazor <[email protected]> wrote:
> In case no one is occupying a wiphy, all past regulatory data will be lost
> as a result of reset to world reg domain.
>
> This includes any channel that is currently in NOP time as well as
> in AVAILABLE state.
>
> This means that after detecting a radar on a channel the user might be
> able to simply reset hostapd and get back to that channel,
> this is a major issue.
>
> To solve this I have added a check before doing any resets.
>
> If the user (for example: hostapd) asks for a regdomain and we are
> already in that regdomain, than we shouldn't reset that regdomain in case
> of wiphy disconnection (for example: hostapd reset or killed).
>
> That way the regulatory data will be saved as long as we are
> in the same regdomain.
>
> Since in that case we will anyway get back to the same regdomain
> the only difference is we will now save the regulatory data,
> won't lose it, and as a result won't get back to a channel that a radar
> was detected on until NOP will be finished, as should be.
>
> Signed-off-by: Orr Mazor <[email protected]>
> ---
> net/wireless/reg.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/net/wireless/reg.c b/net/wireless/reg.c
> index d18cc05061a0..5049c487950b 100644
> --- a/net/wireless/reg.c
> +++ b/net/wireless/reg.c
> @@ -3180,6 +3180,16 @@ static void restore_regulatory_settings(bool
> reset_user, bool cached)
> }
> spin_unlock(®_indoor_lock);
>
> + /* If the user asks for a regdomain and we are
> + * already in that regdomain, than we shouldn't reset
> + * the regdomain in the case of wiphy disconnection.
> + */
> + if (cached && !reset_user &&
> + (!IS_ERR_OR_NULL(cfg80211_user_regdom)) &&
> + (!regdom_changes(cfg80211_user_regdom->alpha2))) {
> + return;
> + }
> +
> reset_regdomains(true, &world_regdom);
> restore_alpha2(alpha2, reset_user);
>
> --
> 2.17.1
>
>
Which device have you tested this on?
>On 15/01/2020, Orr Mazor <[email protected]> wrote:
>> In case no one is occupying a wiphy, all past regulatory data will be
>> lost as a result of reset to world reg domain.
>>
>> This includes any channel that is currently in NOP time as well as in
>> AVAILABLE state.
>>
>> This means that after detecting a radar on a channel the user might be
>> able to simply reset hostapd and get back to that channel, this is a
>> major issue.
>>
>> To solve this I have added a check before doing any resets.
>>
>> If the user (for example: hostapd) asks for a regdomain and we are
>> already in that regdomain, than we shouldn't reset that regdomain in
>> case of wiphy disconnection (for example: hostapd reset or killed).
>>
>> That way the regulatory data will be saved as long as we are in the
>> same regdomain.
>>
>> Since in that case we will anyway get back to the same regdomain the
>> only difference is we will now save the regulatory data, won't lose
>> it, and as a result won't get back to a channel that a radar was
>> detected on until NOP will be finished, as should be.
>>
>> Signed-off-by: Orr Mazor <[email protected]>
>> ---
>> net/wireless/reg.c | 10 ++++++++++
>> 1 file changed, 10 insertions(+)
>>
>> diff --git a/net/wireless/reg.c b/net/wireless/reg.c index
>> d18cc05061a0..5049c487950b 100644
>> --- a/net/wireless/reg.c
>> +++ b/net/wireless/reg.c
>> @@ -3180,6 +3180,16 @@ static void restore_regulatory_settings(bool
>> reset_user, bool cached)
>> }
>> spin_unlock(®_indoor_lock);
>>
>> + /* If the user asks for a regdomain and we are
>> + * already in that regdomain, than we shouldn't reset
>> + * the regdomain in the case of wiphy disconnection.
>> + */
>> + if (cached && !reset_user &&
>> + (!IS_ERR_OR_NULL(cfg80211_user_regdom)) &&
>> + (!regdom_changes(cfg80211_user_regdom->alpha2))) {
>> + return;
>> + }
>> +
>> reset_regdomains(true, &world_regdom);
>> restore_alpha2(alpha2, reset_user);
>>
>> --
>> 2.17.1
>>
>>
>
>Which device have you tested this on?
Hi Tom,
I have tested this on mac80211_hwsim and on a intel proprietary device.
The issue (before the patch) is seen in both, and the patch solves it in both.
BR,
Orr
On Thu, 2020-01-16 at 12:23 +0000, Orr Mazor wrote:
> >
> I have tested this on mac80211_hwsim and on a intel proprietary device.
> The issue (before the patch) is seen in both, and the patch solves it in both.
However, it breaks hwsim tests, e.g. this one:
START he160b 1/1
wlan0: Country code not reset back to 00: is 98
Country code remains set - expect following test cases to fail
FAIL he160b 68.974926 2020-02-07 10:49:51.312663
failed tests: he160b
So maybe it wasn't quite right somehow?
johannes