Re: [RFC] cfg80211 and nl80211

[James Ketrenos <jketreno@linux.intel.com>]

Johannes Berg wrote:

>  * Should the userspace daemon be allowed to unilaterally update the
>    regulatory information if it learns something new (via the user)?

Many countries forbid users (root is still a user) being enabled to
override the parameters set up by the hardware vendor as tested for use
with a specific device.

If the hardware and/or driver for the hardware advertises a set of
operating parameters, user space should honor those settings and the
kernel should enforce them.

User space should be able to shrink the set of available spectrum
parameters but should not expand it.

>    Or why not even just publish the regulatory information APs might
>    broadcast in the scan results, and let the userspace daemon pick
>    that apart? Then the kernel need not ask for anything at all...

I think exposing this information to the user would be useful, and
indicate which capabilities are restricted based on information provided
by the kernel and/or hardware driver.  When channel 13 doesn't work, it
should be clear to the user why so they know who to get mad at.

>  * I seem to have read between the lines that the EEPROM data is
>    pretty much useless. Is that generally true, or should the userspace
>    daemon be told what it contains (somehow)?

The EEPROM contents typically represent the configuration and operating
parameters which have been tested and certified to be operational.

These would represent the only settings which a user can operate with
and still be covered by existing certifications.

Regardless of which country you are operating a device in, the device
was intended for sale within a specific geographic and regulatory region
-- it was tested and certified accordingly.  The EEPROM contents
typically provide the information on what was tested and what the
approved operating parameters are for that device.

>  * Should the kernel perform some kind of validation on the regulatory
>    data the daemon gives it as well?

The kernel should enforce the parameters as specified by the
hardware/driver.  In the event that a driver does not advertise a set of
capabilities, the kernel should select the minimal "safe set", which
would be a subset of the 2.4Ghz spectrum and likely exclude all of 5.2Ghz.

> Right now I'd think that it would make sense to just leave the whole
> task to our userspace daemon, iow. nl80211 just provides a command
> to update the kernel's knowledge about regulory and the daemon periodically
> checks the scan results for country information, asks the user for
> the country, or similar. If it's not running, the kernel simply starts
> from a generic no-frills set.

With hardware that restricts operation to the capabilities it was tested
and calibrated for, this will likely result in a broken user experience
-- if they try and use a device on channel 13 and the device restricts
operation to channels 1 - 11, tuning operations will fail.

James