On Fri, Jan 29, 2010 at 6:46 PM, Paul Wise <p...@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 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
