[pkg-wpa-devel] Debian 2.6.32 CONFIG_WIRELESS_OLD_REGULATORY, wireless-regdb and crda

[Luis R. Rodriguez]

On Fri, Jan 29, 2010 at 6:46 PM, Paul Wise <pabs at debian.org> wrote:
> On Fri, 2010-01-29 at 10:54 -0800, Luis R. Rodriguez wrote:

> Given the OpenSSL stuff in crda 1.1.1, I don't think there are any
> technical roadblocks before crda/wireless-regdb can be uploaded to
> Debian (once the packaging implements what I suggested). Debian just
> needs someone to be the maintainer for it. IIRC Kel doesn't have the
> time. I don't really want to take on yet more packages, but I could
> probably offer sponsorship if Kel or others wanted to join pkg-wpa to do
> the work. Someone on the Debian kernel team might also be willing to do
> either sponsoring or maintainer-ship on this.
>
> Please note that the Debian freeze for the squeeze release is planned
> for March, so this stuff needs to be done soon.

I can help with this only if no one else is up for it. I personally
however find building a key on the fly for each build pretty pointless
and would like to know if a package would be acceptable upstream on
Debian if OpenSSL is used to allow administrators to add their own
keys into the /etc/wireless-regdb/pubkeys/ dir for CRDA and from the
start only trust John's key.

>> > Any idea what proportion of wireless card firmware will respect what
>> > Linux and crda tell it?
>>
>> All wireless drivers respect this, regardless of if you have firmware or not.
>
> Cool, but I would imagine ultimately it is up to the firmware to decide
> if it will use its own regulatory data or trust what Linux says?

We have no way of overriding what firmware says, but in-kernel drivers
do follow cfg80211 regulatory data so if cfg80211 says to disallow
channel 13 because a user said so the driver will respect that. The
regulatory API provided cfg80211 allows for drivers which have their
own regulatory data to inform cfg80211 of this, whether that is that
the device was designed for a specific country or it has a custom
world regulatory domain.

In terms of actual use cases currently all cfg80211 drivers (and
therefore all mac80211 drivers) adhere to the regulatory domain that
cfg80211 is using. Only a few drivers actually pass along regulatory
information to cfg80211 for regulatory purposes. Those drivers are
ath5k, ath9k, zd1211rw, ar9170. zd1211rw just passes a country for a
few select possible countries it has allowed on the EEPROM. all other
Atheros drivers (ath5k, ath9k, ar9170) all share the same EEPROM
regulatory information and can either world roam, be part of a country
region, or specifically be marked for one country. I have tried
documenting this as best as possible here:

http://wireless.kernel.org/en/users/Drivers/ath/

In short, most Atheros cards (95%) world roam, as such follow the its
own custom world regulatory domain. The different custom world
regulatory domains are documented on the wiki.

All Intel cards world roam.

>> Actually all wireless drivers do benefit from it. Note that all new
>> wireless drivers upstream are expected to be either cfg80211 based or
>> mac80211 based, that's it. The new regulatory infrastructure is part
>> of cfg80211 and since all mac80211 drivers are cfg80211 drivers that
>> means *every* wireless driver benefits from this and uses it.
>
> Excellent.
>
>> I should note though that some firmware already have their regulatory
>> stuff built-in to the firmware, just as some cards are configured on
>> their EEPROM to use only one country. In those cases the regulatory
>> infrastructure just helps regulatory compliance further, it would
>> never allow more channels, for instance.
>
> Hmmm, OK. I guess that makes sense. I imagine it will definitely be the
> source of some annoyance for users in the future though.

Tell me about it, but changing that would mean first getting
regulatory agencies to allow regulatory compliance to fall down to the
user when they customize a device's regulatory settings. As it stands
that is not the case so all we can do upstream for now is allow users
to enhance compliance, never allow more. There is also the complexity
of calibration involved in allowing new channels but that is a
separate topic as well.

  Luis