On Thu, Nov 20, 2014 at 5:22 PM, Johannes Berg
<[email protected]> wrote:
> On Sun, 2014-11-16 at 13:06 +0200, Arik Nemtsov wrote:
>
>> We intend to add a patch to wpa_s to always add the wiphy_idx to
>> NL80211_CMD_GET_REG. With the current approach only drivers with
>> SELF_MANAGED_REG will get wiphy->regd back. This is ok since these are
>> new drivers, which are familiar with this API.
>>
>> But if we use your suggestion and always return wiphy->regd, then some
>> driver like ath9k that uses regulatory_hint() will now get it's
>> private regd returned to the wpa_s that manages it. I'm not saying
>> it's necessarily bad, but it's different than what was returned
>> before. The cfg80211 regdomain is intersected with wiphy->regd, so now
>> ath9k will start getting more permissive channels in usermode.
>>
>> So we thought it's best to enable the new behavior only if the driver
>> explicitly wants it, using a new regulatory flag.
>
> How does this work the other way around - i.e. a newer wpa_s requesting
> per-wiphy information but it not being present?
Then it gets the global one, and it knows it via a wiphy attribute:
(wiphy->regulatory_flags & REGULATORY_WIPHY_SELF_MANAGED) &&
+ (nla_put_flag(msg, NL80211_ATTR_WIPHY_SELF_MANAGED_REG)))
+ goto nla_put_failure;
(we won't do this put_flag if it's global)
The supplicant patches are not up yet, but I think for now we will
just act according to the global one. Anyway it has the option to
change policy, since it knows.
>
> It seems to me that either way what the kernel should return is the
> information that will actually be applied when validated, which is of
> course not possible when there are wiphy-specific regdomains and a
> global one is requested (unless there's just one wiphy, which might be
> something to consider making work?)
Well the cfg80211 regdomain is always intersected with all wiphy->regd
in the system, so the global one is always less permissive.
This is of course true before REGULATORY_WIPHY_SELF_MANAGED - in this
case wiphy->regd will not affect the global regd.
With CUSTOM_REG we have a special case, since the regulatory code
doesn't set wiphy->regd, it just applies a user supplied regd to the
wiphy channels (which get validated).
If the user also happens to set wiphy->regd himself with CUSTOM_REG,
then it makes sense to return the per-wiphy one. The global regd is
meaningless anyway for CUSTOM_REG, and the per-wiphy one might be too.
But I guess we can return it if it's there?
>
> I also don't actually see a driver regulatory flag in this patch, as
> expected, so not sure what exactly you're talking about above?
The regulatory flag is in the previous patch and is called
REGULATORY_WIPHY_SELF_MANAGED. The relevant code here is:
+ if (wiphy->regulatory_flags & REGULATORY_WIPHY_SELF_MANAGED)
+ regdom = get_wiphy_regdom(wiphy);
Arik
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
