RE: RFC: Regulatory info in mac80211

RE: RFC: Regulatory info in mac80211

[Joerg Pommnitz]

Larry Finger wrote:



> 1. The regulatory information is too dynamic to be placed in the kernel.



And not all regulatory information is public: as I wrote in a previous message:

I work for a company that has special regulatory permission to use channels

outside those freely available with tx power of up to 4W. This is a legitimate

use case that should not be forbidden by a new regdomain framework (I can always

hack around this, but that's just a hack, not a clean solution).



Regarding a user space daemon: keep in mind special use cases like NFSroot over WLAN.



> 2. The regulatory database should be in an ASCII file for easy updating. This database should be 

> read by a userspace daemon that reformats the information and supplies it to mac80211 upon demand.



OK.



> 3. There should be some sort of checking to verify that the database has not been hacked to modify 

> transmission power, etc. in an illegal manner. Obviously, no foolproof means of enforcing this does 

> not exist; however, we should prevent the crudest form of modifications.

Define "illegal manner". For me it is perfectly legal to use channel 14 in Europe with 4W tx power. I admit that this is a

special interest, but nonetheless perfectly legal.





--  

Regards

 

       Joerg

 











       __________________________________ Yahoo! Clever - Der einfachste Weg, Fragen zu stellen und Wissenswertes mit Anderen zu teilen. www.yahoo.de/clever

RE: RFC: Regulatory info in mac80211

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 262 bytes --]

On Wed, 2007-06-06 at 03:00 -0700, Joerg Pommnitz wrote:

> Regarding a user space daemon: keep in mind special use cases like NFSroot over WLAN.

That isn't going to be possible in any case since we require userspace
to set up wireless links.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: RFC: Regulatory info in mac80211

[Larry Finger]

Joerg Pommnitz wrote:
> Larry Finger wrote:
> 
> And not all regulatory information is public: as I wrote in a previous message:
> I work for a company that has special regulatory permission to use channels
> outside those freely available with tx power of up to 4W. This is a legitimate
> use case that should not be forbidden by a new regdomain framework (I can always
> hack around this, but that's just a hack, not a clean solution).

As this usage is not allowed by any other user, I think it should be forbidden. Your hack will be to 
alter the database. As I stated earlier, it will be nearly possible to prevent such hacking, there 
will always be a back door for users like you.
> 
> Regarding a user space daemon: keep in mind special use cases like NFSroot over WLAN.

This is a "chicken and egg" problem. That may require limiting such usage to the default/fallback 
configuration.

>> 3. There should be some sort of checking to verify that the database has not been hacked to modify 
>> transmission power, etc. in an illegal manner. Obviously, no foolproof means of enforcing this does 
>> not exist; however, we should prevent the crudest form of modifications.
> 
> Define "illegal manner". For me it is perfectly legal to use channel 14 in Europe with 4W tx power. I admit that this is a
> special interest, but nonetheless perfectly legal.

If I did that, it would be illegal. Similarly, if I were to hack my AP to use channel 14 in the US, 
it would be illegal at any power. These are the kinds of things that should not be easy for just any 
user to change. I certainly hope that the final result of this effort can handle your special needs 
without any kernel changes, unlike with the current version of mac80211.

Larry

Re: RFC: Regulatory info in mac80211

[Joerg Pommnitz]

I think this is what initramfs is there for. I'm not sure whether runni=
ng from initramfs
places certain restrictions on programs like the proposed regdomain dae=
mon. If it
does, it would be important to keep these restrictions in mind when des=
igning the
new infrastructure.
=20
-- =20
Regards
=20
       Joerg
=20


----- Urspr=FCngliche Mail ----
Von: Johannes Berg <johannes@sipsolutions.net>
An: Joerg Pommnitz <pommnitz@yahoo.com>
CC: linux-wireless@vger.kernel.org
Gesendet: Mittwoch, den 6. Juni 2007, 13:41:45 Uhr
Betreff: RE: RFC: Regulatory info in mac80211

On Wed, 2007-06-06 at 03:00 -0700, Joerg Pommnitz wrote:

> Regarding a user space daemon: keep in mind special use cases like NF=
Sroot over WLAN.

That isn't going to be possible in any case since we require userspace
to set up wireless links.

johannes






      Heute schon einen Blick in die Zukunft von E-Mails wagen? Versuch=
en Sie=B4s mit dem neuen Yahoo! Mail. www.yahoo.de/mail
-
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RFC: Regulatory info in mac80211

[Larry Finger]

Given the recent discussions of regulatory/geographic domain compliance (or lack thereof) in 
mac80211, and the fact that the software is mainlined in 2.6.22, it seems a good time to start 
planning for full implementation of regulatory information in mac80211.

Roughly a year ago, I worked on such a scheme for ieee80211, but put the project on hold when I 
learned that ieee80211 and ieee80211_softmac, which is used by my driver of interest, would be 
replaced by mac80211. The project was far from complete; however, a number of individuals responded 
to my RFC's and suggested the following (the netdev archives should contain the E-mails):

1. The regulatory information is too dynamic to be placed in the kernel.

2. The regulatory database should be in an ASCII file for easy updating. This database should be 
read by a userspace daemon that reformats the information and supplies it to mac80211 upon demand.

3. There should be some sort of checking to verify that the database has not been hacked to modify 
transmission power, etc. in an illegal manner. Obviously, no foolproof means of enforcing this does 
not exist; however, we should prevent the crudest form of modifications.

4. The database should incorporate the parameters needed for 802.11a, 802.11b/g/n, 802.11d, and 802.11h.

5. There should be a scheme for translating country codes based on the outdated table 105 in 
Corrigendum 1 for 802.11b. This is the basis for the EEPROM data in the ZD1211 hardware. Note, this 
scheme is far too limited to be the only one available. If the translation code is needed for more 
than one driver, it should be placed in mac80211.

6. In case of errors such as the user daemon not running, database corruption, an illegal region 
code from the driver, etc., mac80211 should set a default set of parameters that are legal 
everywhere, and log a suitable error message.

7. ??

To begin such an undertaking, the following steps need to be done:

1. Decide what information is required. These data include, but are not limited to, the band, the 
maximum E.I.R.P. in dBm, whether the data are for indoors/outdoors/both, an indication regarding the 
use of active vs passive scans, allowed protocols, etc. I don't know enough about 802.11h to know 
what data will be required.

2. Accumulate the necessary regulatory data for the world. I found a source for such information. 
Although its price (2500 euro) was a significant problem, the NDA that went with it was a show 
stopper. The diversity of regulations is much greater than I expected. Although, I had only 
collected data on roughly half the countries in the ISO 3166 country codes, I had found 12 distinct 
sets of rules for the 2.4 GHz band and 17 sets in the 5 GHz bands, without any 802.11h information.

3. Decide on how to store this information within mac80211.

4. Decide on the structure of the ASCII database and the means of communication between the daemon 
and the kernel.

5. Prepare the data file and code the userspace and kernel components.

6. Other....

I welcome your comments.

Larry

Re: RFC: Regulatory info in mac80211

[Luis R. Rodriguez]

On 6/5/07, Larry Finger <Larry.Finger@lwfinger.net> wrote:
> Given the recent discussions of regulatory/geographic domain compliance (or lack thereof) in
> mac80211, and the fact that the software is mainlined in 2.6.22, it seems a good time to start
> planning for full implementation of regulatory information in mac80211.

Since we have a new userspace and driver API underway as well I think
we should instead focus on an overall regulatory framework for all
types of wireless devices and not just mac80211. Although some devices
do provide regulatory enforcement through firmware extending the
driver API to do an additional check for consistency amongst all
devices seems like a good idea.

> Roughly a year ago, I worked on such a scheme for ieee80211, but put the project on hold when I
> learned that ieee80211 and ieee80211_softmac, which is used by my driver of interest, would be
> replaced by mac80211. The project was far from complete; however, a number of individuals responded
> to my RFC's and suggested the following (the netdev archives should contain the E-mails):

I had started my own implementation as I noticed a few of the flaws
(and some more) you mention bellow:

http://kernel.org/pub/linux/kernel/people/mcgrof/patch-02-ieee80211_regdomains.diff

There is still some flaws to this but I am confident this is the right
direction. Let me see if I can address some of the points you make
with respect to this implementation and with the overall architectural
view I have of this now.

> 1. The regulatory information is too dynamic to be placed in the kernel.

ACK, at least some defaults can still be provided.

> 2. The regulatory database should be in an ASCII file for easy updating. This database should be
> read by a userspace daemon that reformats the information and supplies it to mac80211 upon demand.

Again -- I think we should think of an overall regulatory agent for
all wireless drivers, not just mac80211. But I do agree the main db
should be available in userspace and an interface provided for
updating the regulatory agent. The way I was going about this with my
implementation was to let userspace update ieee802111_regdomains
module through nl80211.

> 3. There should be some sort of checking to verify that the database has not been hacked to modify
> transmission power, etc. in an illegal manner. Obviously, no foolproof means of enforcing this does
> not exist; however, we should prevent the crudest form of modifications.

This is the hairy part (hey Alan :)). For devices that have additional
hardware checks in firmware we're OK as even if the user does try to
go out of regulatory compliance they won't be able to, that is unless
they change their regulatory domain and can do so with the device. For
these type of devices it means we should be able to get vendor support
(example is Intel). For devices where all regulatory enforcement is
expected to be done through the driver I think best effort should be
enough for in-kernel drivers.

I think perhaps the best suggestion for best effort right now was some
sort signing for a set of possible registers and have the microcode
verify this. Not too sure on all the details of the idea, this was
Alan's idea, Alan -- can you elaborate a bit on how this would work
exactly?

Previously a concern for vendors over if whether if regulatory
compliance is enforced in firmware or the driver was that it seemed
that if it implemented in firmware you can get away with FCC part 15
rules certification. But it seems that a new clarification by the FCC
on SDR rules seems to indicate that even if its done in firmware you
need to certify your device under SDR rules (someone correct me if
this seems wrong):

http://hraunfoss.fcc.gov/edocs_public/attachmatch/FCC-07-66A1.pdf

We're not concerned over certification but vendors are and we get some
vendor support when our implementations might allow them to get SDR
certification. Here is what the clarification says about security
measures with respect to regulatory compliance under SDR rules:

"A system that is wholly dependent on open source elements will have a
high burden to demonstrate that it is sufficiently secure to warrant
authorization as a software defined radio."

And that's all they say about that.

> 4. The database should incorporate the parameters needed for 802.11a, 802.11b/g/n, 802.11d, and 802.11h.

ACK on 802.11d, I added a bit of that. Can you elaborate a bit more on
what you mean by incorporating parameters needed for 802.11bg or n.
Then AFAICT 802.11h only applies to 802.11a, someone correct me if I'm
wrong.

> 5. There should be a scheme for translating country codes based on the outdated table 105 in
> Corrigendum 1 for 802.11b. This is the basis for the EEPROM data in the ZD1211 hardware.

Ah so that's where the mappings for to several regdomain numbers for
several devices came from (prism54, zydas, atheros)! Hm, some vendors
(Atheros) defined a rest set of values and I always wondered where
they got them from if they came up with them on their own. I figured
they would use iso3166-1 number mapping for specific countries but
nope.

> Note, this
> scheme is far too limited to be the only one available. If the translation code is needed for more
> than one driver, it should be placed in mac80211.

In my implementation I dealt with this shortcoming by just adopting
our own numbering scheme (the one on table 105) and letting the driver
either embrace this as default or provide their own mapping to ours.
See ieee80211_regulatory_map in my implementation.

> 6. In case of errors such as the user daemon not running, database corruption, an illegal region
> code from the driver, etc., mac80211 should set a default set of parameters that are legal
> everywhere, and log a suitable error message.

I wanted this to work too unfortunately I found that there is no world
decent acceptable regulatory domain. We'd have to allow only 802.11b
only and only allow a couple of channels IIRC. We could just ignore
this and increase the size of this to allow a few 802.11a channels as
well. See my add_regdomain_world().

> 7. ??

A few other things I added to my implementation:

* Break regulatory domains into supporting bands, not modes
specifically. Example of bands:

- ISM 2.4 GHz Band
- UNII-1 Band (5150 - 5250 MHz)
- UNII-2 Band (5250 - 5350 MHz)
- UNII-3 Band (5725 - 5825 MHz)

Then within each band add a list of subbands. For each subband allow
of type 'set' or 'range'

* For power restrictions have max_eirp_indoor and max_eirp_outdoor,
let user tell us where we are, assume indoor.

* Add environment capability for subbands (indoor, outdoor)

> To begin such an undertaking, the following steps need to be done:
>
> 1. Decide what information is required. These data include, but are not limited to, the band, the
> maximum E.I.R.P. in dBm, whether the data are for indoors/outdoors/both, an indication regarding the
> use of active vs passive scans, allowed protocols, etc. I don't know enough about 802.11h to know
> what data will be required.

I've dealt with all this except for the active/passive scan stuff.
Besides using mac80211's ieee80211_regulatory_map() as documentation
for this not sure where else to find more information on it.

> 2. Accumulate the necessary regulatory data for the world. I found a source for such information.
> Although its price (2500 euro) was a significant problem, the NDA that went with it was a show
> stopper. The diversity of regulations is much greater than I expected. Although, I had only
> collected data on roughly half the countries in the ISO 3166 country codes, I had found 12 distinct
> sets of rules for the 2.4 GHz band and 17 sets in the 5 GHz bands, without any 802.11h information.

My source for this information has been standard cisco PDF docs lying
around and the Atheros openhal -- this is pretty outdated though. If
we put this in userland and XML'ize it we can let people patch at
will.

> 3. Decide on how to store this information within mac80211.

I think cfg80211 should essentially have the current
ieee80211_regdomain and then have cfg80211 do all the necessary checks
which switching channels or trying to switch power.

> 4. Decide on the structure of the ASCII database and the means of communication between the daemon
> and the kernel.

Here's some ideas:

* Kernel adopts default "world" regdomain supported by the kernel
* User logs in, uses network-manager/wpa_supplicant/foo-app to select
regdomain bar
* Userspace app talks to the kernel via nl80211 to update
ieee80211_regdomain db with regdomain data collected from userspace
for regdomain bar.
* Userspace app talks to the kernel via nl80211 to update cfg80211 to
switch to regdomain in its config

> 5. Prepare the data file and code the userspace and kernel components.
>
> 6. Other....
>
> I welcome your comments.

Besides having cfg80211 speak regulatory domains another idea is to
have a central frequency broker in the kernel so that besides just
working as a frequency broker for 802.11 regulatory compliance it can
also enhance interoperability between the different supported radio
types -- 802.11, bluetooth, ultrawideband (and any other that is added
to the kernel). This idea is still under development:

http://linuxwireless.org/en/developers/FrequencyBroker

  Luis

Re: RFC: Regulatory info in mac80211

[Iñaky Pérez-González]

On Tuesday 05 June 2007, Luis R. Rodriguez wrote:
> On 6/5/07, Larry Finger <Larry.Finger@lwfinger.net> wrote:


> Besides having cfg80211 speak regulatory domains another idea is to
> have a central frequency broker in the kernel so that besides just
> working as a frequency broker for 802.11 regulatory compliance it can
> also enhance interoperability between the different supported radio
> types -- 802.11, bluetooth, ultrawideband (and any other that is added
> to the kernel). This idea is still under development:
> 
> http://linuxwireless.org/en/developers/FrequencyBroker

Which reminds me I have to add a link to the code repos.

Thanks,

-- Inaky

Re: RFC: Regulatory info in mac80211

[Dan Williams]

On Tue, 2007-06-05 at 19:35 -0400, Luis R. Rodriguez wrote:
> On 6/5/07, Larry Finger <Larry.Finger@lwfinger.net> wrote:
> > Given the recent discussions of regulatory/geographic domain compliance (or lack thereof) in
> > mac80211, and the fact that the software is mainlined in 2.6.22, it seems a good time to start
> > planning for full implementation of regulatory information in mac80211.
> 
> Since we have a new userspace and driver API underway as well I think
> we should instead focus on an overall regulatory framework for all
> types of wireless devices and not just mac80211. Although some devices
> do provide regulatory enforcement through firmware extending the
> driver API to do an additional check for consistency amongst all
> devices seems like a good idea.

I'd like to echo the above.  I've got an interest in a few fullmac
drivers (airo, atmel, libertas) that have various bits of regulatory
info in the driver in static tables.  If we can push that out somewhere
that's a lot easier to update when regulations change, that's a huge
bonus and removes duplicated code.  So let's try to get something that
the fullmac drivers can plug into at some level too, even if it's just
"give me allowed power and channel values for France" or something like
that.  For example:

libertas: contains region and channel power mappings for 802.11d in
liberas/11d.c and libertas/main.c, and a pile of code to deal with
802.11d

atmel: contains channel tables and regulatory domain information,
validates channel changes

Maybe roll these sort of utility functions into "lib80211" that both
fullmac and mac80211 drivers can depend on.  And have various functions
to convert between channel, frequency, and band, etc, that every driver
seems to reimplement.

We should also have some mechanism (likely though nl80211/cfg80211) that
allows domain changes if the driver and firmware support it, or return
errors if you're not allowed to change the domain.

Dan


> > Roughly a year ago, I worked on such a scheme for ieee80211, but put the project on hold when I
> > learned that ieee80211 and ieee80211_softmac, which is used by my driver of interest, would be
> > replaced by mac80211. The project was far from complete; however, a number of individuals responded
> > to my RFC's and suggested the following (the netdev archives should contain the E-mails):
> 
> I had started my own implementation as I noticed a few of the flaws
> (and some more) you mention bellow:
> 
> http://kernel.org/pub/linux/kernel/people/mcgrof/patch-02-ieee80211_regdomains.diff
> 
> There is still some flaws to this but I am confident this is the right
> direction. Let me see if I can address some of the points you make
> with respect to this implementation and with the overall architectural
> view I have of this now.
> 
> > 1. The regulatory information is too dynamic to be placed in the kernel.
> 
> ACK, at least some defaults can still be provided.
> 
> > 2. The regulatory database should be in an ASCII file for easy updating. This database should be
> > read by a userspace daemon that reformats the information and supplies it to mac80211 upon demand.
> 
> Again -- I think we should think of an overall regulatory agent for
> all wireless drivers, not just mac80211. But I do agree the main db
> should be available in userspace and an interface provided for
> updating the regulatory agent. The way I was going about this with my
> implementation was to let userspace update ieee802111_regdomains
> module through nl80211.
> 
> > 3. There should be some sort of checking to verify that the database has not been hacked to modify
> > transmission power, etc. in an illegal manner. Obviously, no foolproof means of enforcing this does
> > not exist; however, we should prevent the crudest form of modifications.
> 
> This is the hairy part (hey Alan :)). For devices that have additional
> hardware checks in firmware we're OK as even if the user does try to
> go out of regulatory compliance they won't be able to, that is unless
> they change their regulatory domain and can do so with the device. For
> these type of devices it means we should be able to get vendor support
> (example is Intel). For devices where all regulatory enforcement is
> expected to be done through the driver I think best effort should be
> enough for in-kernel drivers.
> 
> I think perhaps the best suggestion for best effort right now was some
> sort signing for a set of possible registers and have the microcode
> verify this. Not too sure on all the details of the idea, this was
> Alan's idea, Alan -- can you elaborate a bit on how this would work
> exactly?
> 
> Previously a concern for vendors over if whether if regulatory
> compliance is enforced in firmware or the driver was that it seemed
> that if it implemented in firmware you can get away with FCC part 15
> rules certification. But it seems that a new clarification by the FCC
> on SDR rules seems to indicate that even if its done in firmware you
> need to certify your device under SDR rules (someone correct me if
> this seems wrong):
> 
> http://hraunfoss.fcc.gov/edocs_public/attachmatch/FCC-07-66A1.pdf
> 
> We're not concerned over certification but vendors are and we get some
> vendor support when our implementations might allow them to get SDR
> certification. Here is what the clarification says about security
> measures with respect to regulatory compliance under SDR rules:
> 
> "A system that is wholly dependent on open source elements will have a
> high burden to demonstrate that it is sufficiently secure to warrant
> authorization as a software defined radio."
> 
> And that's all they say about that.
> 
> > 4. The database should incorporate the parameters needed for 802.11a, 802.11b/g/n, 802.11d, and 802.11h.
> 
> ACK on 802.11d, I added a bit of that. Can you elaborate a bit more on
> what you mean by incorporating parameters needed for 802.11bg or n.
> Then AFAICT 802.11h only applies to 802.11a, someone correct me if I'm
> wrong.
> 
> > 5. There should be a scheme for translating country codes based on the outdated table 105 in
> > Corrigendum 1 for 802.11b. This is the basis for the EEPROM data in the ZD1211 hardware.
> 
> Ah so that's where the mappings for to several regdomain numbers for
> several devices came from (prism54, zydas, atheros)! Hm, some vendors
> (Atheros) defined a rest set of values and I always wondered where
> they got them from if they came up with them on their own. I figured
> they would use iso3166-1 number mapping for specific countries but
> nope.
> 
> > Note, this
> > scheme is far too limited to be the only one available. If the translation code is needed for more
> > than one driver, it should be placed in mac80211.
> 
> In my implementation I dealt with this shortcoming by just adopting
> our own numbering scheme (the one on table 105) and letting the driver
> either embrace this as default or provide their own mapping to ours.
> See ieee80211_regulatory_map in my implementation.
> 
> > 6. In case of errors such as the user daemon not running, database corruption, an illegal region
> > code from the driver, etc., mac80211 should set a default set of parameters that are legal
> > everywhere, and log a suitable error message.
> 
> I wanted this to work too unfortunately I found that there is no world
> decent acceptable regulatory domain. We'd have to allow only 802.11b
> only and only allow a couple of channels IIRC. We could just ignore
> this and increase the size of this to allow a few 802.11a channels as
> well. See my add_regdomain_world().
> 
> > 7. ??
> 
> A few other things I added to my implementation:
> 
> * Break regulatory domains into supporting bands, not modes
> specifically. Example of bands:
> 
> - ISM 2.4 GHz Band
> - UNII-1 Band (5150 - 5250 MHz)
> - UNII-2 Band (5250 - 5350 MHz)
> - UNII-3 Band (5725 - 5825 MHz)
> 
> Then within each band add a list of subbands. For each subband allow
> of type 'set' or 'range'
> 
> * For power restrictions have max_eirp_indoor and max_eirp_outdoor,
> let user tell us where we are, assume indoor.
> 
> * Add environment capability for subbands (indoor, outdoor)
> 
> > To begin such an undertaking, the following steps need to be done:
> >
> > 1. Decide what information is required. These data include, but are not limited to, the band, the
> > maximum E.I.R.P. in dBm, whether the data are for indoors/outdoors/both, an indication regarding the
> > use of active vs passive scans, allowed protocols, etc. I don't know enough about 802.11h to know
> > what data will be required.
> 
> I've dealt with all this except for the active/passive scan stuff.
> Besides using mac80211's ieee80211_regulatory_map() as documentation
> for this not sure where else to find more information on it.
> 
> > 2. Accumulate the necessary regulatory data for the world. I found a source for such information.
> > Although its price (2500 euro) was a significant problem, the NDA that went with it was a show
> > stopper. The diversity of regulations is much greater than I expected. Although, I had only
> > collected data on roughly half the countries in the ISO 3166 country codes, I had found 12 distinct
> > sets of rules for the 2.4 GHz band and 17 sets in the 5 GHz bands, without any 802.11h information.
> 
> My source for this information has been standard cisco PDF docs lying
> around and the Atheros openhal -- this is pretty outdated though. If
> we put this in userland and XML'ize it we can let people patch at
> will.
> 
> > 3. Decide on how to store this information within mac80211.
> 
> I think cfg80211 should essentially have the current
> ieee80211_regdomain and then have cfg80211 do all the necessary checks
> which switching channels or trying to switch power.
> 
> > 4. Decide on the structure of the ASCII database and the means of communication between the daemon
> > and the kernel.
> 
> Here's some ideas:
> 
> * Kernel adopts default "world" regdomain supported by the kernel
> * User logs in, uses network-manager/wpa_supplicant/foo-app to select
> regdomain bar
> * Userspace app talks to the kernel via nl80211 to update
> ieee80211_regdomain db with regdomain data collected from userspace
> for regdomain bar.
> * Userspace app talks to the kernel via nl80211 to update cfg80211 to
> switch to regdomain in its config
> 
> > 5. Prepare the data file and code the userspace and kernel components.
> >
> > 6. Other....
> >
> > I welcome your comments.
> 
> Besides having cfg80211 speak regulatory domains another idea is to
> have a central frequency broker in the kernel so that besides just
> working as a frequency broker for 802.11 regulatory compliance it can
> also enhance interoperability between the different supported radio
> types -- 802.11, bluetooth, ultrawideband (and any other that is added
> to the kernel). This idea is still under development:
> 
> http://linuxwireless.org/en/developers/FrequencyBroker
> 
>   Luis
> -
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: RFC: Regulatory info in mac80211

[Stefano Brivio]

On Tue, 05 Jun 2007 15:51:51 -0500
Larry Finger <Larry.Finger@lwfinger.net> wrote:

> 3. There should be some sort of checking to verify that the database has
> not been hacked to modify transmission power, etc. in an illegal manner.
> Obviously, no foolproof means of enforcing this does not exist; however,
> we should prevent the crudest form of modifications.

Why should this be enforced at all? What the Linux kernel has to do with
enforcing legality?

I see implementation of regulatory information in mac80211 as a convenient
way in order to avoid issues for the end user. Those issues includes:
1) violating the regulatory domain compliance without noticing;
2) losing time in order to get around domain compliance checks, when
this is done with perfect consciousness.


--
Ciao
Stefano

Re: RFC: Regulatory info in mac80211

[Luis R. Rodriguez]

On 6/7/07, Stefano Brivio <stefano.brivio@polimi.it> wrote:
> On Tue, 05 Jun 2007 15:51:51 -0500
> Larry Finger <Larry.Finger@lwfinger.net> wrote:
>
> > 3. There should be some sort of checking to verify that the database has
> > not been hacked to modify transmission power, etc. in an illegal manner.
> > Obviously, no foolproof means of enforcing this does not exist; however,
> > we should prevent the crudest form of modifications.
>
> Why should this be enforced at all? What the Linux kernel has to do with
> enforcing legality?
>
> I see implementation of regulatory information in mac80211 as a convenient
> way in order to avoid issues for the end user. Those issues includes:
> 1) violating the regulatory domain compliance without noticing;
> 2) losing time in order to get around domain compliance checks, when
> this is done with perfect consciousness.

A bigger issue for users is support. As you very well know reverse
engineering is a long tedious process; we are essentially doomed to
reverse engineering  wireless drivers for some wireless devices where
regulatory compliance sits in the driver due to vendor fears on legal
liability. I'm not saying their fears are justified by any means I'm
just saying those fears do exist by some vendors and unfortunately we
suffer the consequences. So if we can do some sort of best effort,
perhaps we can steer some vendors to support us.

  Luis

Re: RFC: Regulatory info in mac80211

[stefano.brivio]

Quoting "Luis R. Rodriguez" <mcgrof@gmail.com>:

> A bigger issue for users is support. As you very well know reverse
> engineering is a long tedious process; we are essentially doomed to
> reverse engineering  wireless drivers for some wireless devices where
> regulatory compliance sits in the driver due to vendor fears on legal
> liability. I'm not saying their fears are justified by any means I'm
> just saying those fears do exist by some vendors and unfortunately we
> suffer the consequences. So if we can do some sort of best effort,
> perhaps we can steer some vendors to support us.

I would say that we should do our best in supporting users instead.

Furthermore, I understand your concerns, but:
1) I think that a weak regulatory domain support (such as commented  
defines in the mac80211 code) is sufficient to claim we comply with  
regulatory domains, while avoiding to hassle users.
2) We won't get any vendor to support us thanks to regulatory  
compliance. There are just some weird vendors such as Broadcom and  
some friendly vendors such as Realtek: it's unrealistic that vendors  
such as Broadcom would ever change their mind. You may say my point is  
short-sighted, but I really can't think that we can steer a vendor to  
support us just by complying to regulatory domains: it looks clear to  
me that Broadcom and other weird vendors such as TI are just  
ridicolously trying to protect IP. Or are you talking about the  
almost-friendly vendors like Intel?
3) The GPL license, in my humble opinion, aims at the most possible  
freedom. I don't care if vendors support us if we don't aim at this.

However, as you can see, I CC'ed Theo DeRaadt, who, being an expert  
about these issues, will sure provide us with the best advice about  
what to do.


--
Ciao
Stefano

Re: RFC: Regulatory info in mac80211

[Luis R. Rodriguez]

On 6/7/07, stefano.brivio@polimi.it <stefano.brivio@polimi.it> wrote:
> Quoting "Luis R. Rodriguez" <mcgrof@gmail.com>:
>
> > A bigger issue for users is support. As you very well know reverse
> > engineering is a long tedious process; we are essentially doomed to
> > reverse engineering  wireless drivers for some wireless devices where
> > regulatory compliance sits in the driver due to vendor fears on legal
> > liability. I'm not saying their fears are justified by any means I'm
> > just saying those fears do exist by some vendors and unfortunately we
> > suffer the consequences. So if we can do some sort of best effort,
> > perhaps we can steer some vendors to support us.
>
> I would say that we should do our best in supporting users instead.
>
> Furthermore, I understand your concerns, but:
> 1) I think that a weak regulatory domain support (such as commented
> defines in the mac80211 code) is sufficient to claim we comply with
> regulatory domains, while avoiding to hassle users.

Current mac80211 regdomain support is a joke. Once we get something
more decent I'd be inclined to agree with you. But to comply with is
not sufficient to gain vendor support and that's what I'd like more of
and why I think Larry mentioned it as well.

> 2) We won't get any vendor to support us thanks to regulatory
> compliance.

For just a FOSS implementation of it with no security measures in
place, you are right. Some vendors want some sort of security measure
on top of such regulatory compliance agents though. A perfect example
was Atheros' belief in the Hardware Abstraction Layer model as
sufficient for regulatory compliance. I'm inclined to believe some
vendors may vouch for support should such type of models still be
used. I'm inclined to believe that we can get some more vendor support
should we come up with an alternative to this which still allows full
FOSS drivers. Henry, can you perhaps comment a bit on Broadcom's
position on this?

> There are just some weird vendors such as Broadcom and
> some friendly vendors such as Realtek: it's unrealistic that vendors
> such as Broadcom would ever change their mind. You may say my point is
> short-sighted, but I really can't think that we can steer a vendor to
> support us just by complying to regulatory domains:

The idea is not just try to get vendor support by simply complying to
regulatory domain control but to try to see if we can provide some
sort of security measure to prevent modifications of such agent. I'm
not even saying that such security features are the right thing to do
-- in fact I think its ridiculous -- I'm just saying this is what some
vendors are asking for should we want support for FOSS drivers on some
devices where regulatory domain control is enforced at the driver
level RIGHT NOW.

IMO the long term goal should be to change legislation so that a
complete FOSS solution to regulatory compliance is sufficient for
802.11 and if such regulatory compliance is violated by the user
(regulatory, even if modifying the device such as adding a new antenna
which makes the device go out of compliance) liability is passed onto
the user, not the OEM or vendor. Note that this argument is made
purely for 802.11, not WiMAX ;) I think it may be something possible
for us to accomplish.

> it looks clear to
> me that Broadcom and other weird vendors such as TI are just
> ridicolously trying to protect IP.

I think "old-school" is a more appropriate description for them -- but
anyway, I have not yet heard one argument from a vendor which does
emphasize this as a reason to not support us. On the contrary the main
issue vendors have expressed concerns over support has been regulatory
compliance and way to assure the user cannot circumvent this due to
legal concerns over liability in the worst case scenarios in markets
where their products are sold (Singapore, Japan?).

>Or are you talking about the
> almost-friendly vendors like Intel?

I think Intel is as friendly as they'll get. And anyway -- no, Intel
has acknowledged the mess with regulatory compliance and I do believe
their developers strive as much as possible to get us proper support
and as close to a FOSS driver as possible. Their solution to the mess
is to put regulatory compliance in microcode, which most regulatory
agencies do seem to tolerate for a FOSS driver.

> 3) The GPL license, in my humble opinion, aims at the most possible
> freedom. I don't care if vendors support us if we don't aim at this.

You don't. Many people don't. But Aunt Tillie wants support for her
wireless card. And if it means switching back to Mac OS X to get
support for it she'll do it. I also don't think its fair for us to
have to reverse engineer all of our wireless drivers. To avoid this we
should try to listen to vendor concerns and see if we can address and
deal with them, for Aunt Tillie's sake. And if we determine such
concerns are unreasonable for a FOSS driver then I think in terms of
support we can only try to seriously lobby for a change in legislation
in our own locales to address this.

> However, as you can see, I CC'ed Theo DeRaadt, who, being an expert
> about these issues, will sure provide us with the best advice about
> what to do.

CC'd now, for real this time. He may actually have some useful
feedback on the topic.

  Luis

Re: RFC: Regulatory info in mac80211

[Daniel Drake]

Larry Finger wrote:
> 5. There should be a scheme for translating country codes based on the 
> outdated table 105 in Corrigendum 1 for 802.11b. This is the basis for 
> the EEPROM data in the ZD1211 hardware. Note, this scheme is far too 
> limited to be the only one available. If the translation code is needed 
> for more than one driver, it should be placed in mac80211.

You might wish to treat the fact that the ZD1211 EEPROM regdomain field 
appears to correspond to the 802.11b specs as just a coincidence. Some 
newer devices have regdomain values that are not in that table (and are 
not even mentioned in the vendor driver...)

Daniel

Re: RFC: Regulatory info in mac80211

[Larry Finger]

Daniel Drake wrote:
> Larry Finger wrote:
>> 5. There should be a scheme for translating country codes based on the 
>> outdated table 105 in Corrigendum 1 for 802.11b. This is the basis for 
>> the EEPROM data in the ZD1211 hardware. Note, this scheme is far too 
>> limited to be the only one available. If the translation code is 
>> needed for more than one driver, it should be placed in mac80211.
> 
> You might wish to treat the fact that the ZD1211 EEPROM regdomain field 
> appears to correspond to the 802.11b specs as just a coincidence. Some 
> newer devices have regdomain values that are not in that table (and are 
> not even mentioned in the vendor driver...)

That was my intent from the start. The two European countries (France and Spain) that are mentioned 
in that table have the wrong channels assigned; however, if some driver asked for either of those 
regions, we will supply the channel data that is current today.

Larry