From: Ben Greear <[email protected]>
If one is UN-SET, use the other. Seems this would
be more correct that what we have now.
Signed-off-by: Ben Greear <[email protected]>
---
Someone that understands this code better than I
do should review this well before it is considered
for upstream. I'm not sure it is actually needed.
net/wireless/reg.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 785e516..b87035f 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -727,8 +727,15 @@ static enum nl80211_dfs_regions
reg_intersect_dfs_region(const enum nl80211_dfs_regions dfs_region1,
const enum nl80211_dfs_regions dfs_region2)
{
- if (dfs_region1 != dfs_region2)
+ if (dfs_region1 != dfs_region2) {
+ pr_info("intersect-dfs-region, region1: %d region2: %d\n",
+ dfs_region1, dfs_region2);
+ if (dfs_region1 == NL80211_DFS_UNSET)
+ return dfs_region2;
+ if (dfs_region2 == NL80211_DFS_UNSET)
+ return dfs_region1;
return NL80211_DFS_UNSET;
+ }
return dfs_region1;
}
--
1.7.11.7
On Tue, Jun 24, 2014 at 08:47:46AM +0300, Kalle Valo wrote:
> Ben Greear <[email protected]> writes:
>
> > As for being confusing, the current code is nasty and it is very hard
> > to have any idea why things do or do not work, especially if you do not
> > have ability to add printk all over the place to figure out what the
> > code is actually doing.
>
> Heh, this is exatly what I do when I debug regulatory issues :)
CFG80211_REG_DEBUG isn't too chatty already?
> > I think some more effort should go into printing out a lot more
> > information about the regulator domain decisions, through printk
> > or related call if nothing better is found...
>
> IMHO the regulatory code is the most fragile part of Linux wireless
> stack
Changing anything on regulatory can have an impact on many things but
lets be clear of the difference on the nature of quality over impact due
to the nature of what the code does and its impact. I invite you to
compare the code quality on the existing regulatory infrastructure from
what was in place on the atheros driver HAL for regulatory control. Now
*that* was incomprensible and somehow we managed to evolve to something
central and shared on Linux.
Code needs to evolve though and I do agree we need to evolve things
to a more mature foundation. More details on that regards below.
> and needs a rewrite. It needs to be simple and easy to understand.
There is actually quite a bit of documentation:
http://wireless.kernel.org/en/developers/Regulatory
http://wireless.kernel.org/en/developers/Regulatory/processing_rules
http://wireless.kernel.org/en/developers/Regulatory/CRDA
http://wireless.kernel.org/en/developers/Regulatory/wireless-regdb
I'm not familiar with smaller pieces of code on the kernel with as much
documentation as this. The code actually also includes quite a bit of
kdoc and comments. Small code changes however can have an impact though
and as technologies advances we have more complex corner cases and
the state machine of regulatory keeps evolving as such a more evolved
infrastructure is indeed needed to help us cope and ensure we don't
have regressions as we evolve the code.
What we need is a full blown regulatory simulator. That would enable
us to stage things in userapce and provide an easy test suite for
changes, and also do easy test automation. I started work on this a
while ago and got somewhat far to at least call it a good start. It
should enable anyone wishing to work on a rewrite to have a good
base template. The last piece I worked on was making a regulatory
library extracted from CRDA and its why CRDA now has reglib. The
next piece would be making usage of reglib on regsim and then a full
effort on the rewrite can undergo.
The regulatory simulator:
https://github.com/mcgrof/regsim
I found at least one fix which I ended up porting upstream (a042994dd377d)
but since "regulatory rewrite" has always been on the lower end of priorities
I never got to finish this work. The basics are there though and having reglib
on CRDA available should also help with a new evolution on regulatory.
Note that the regsim does include the algorithm proposed by Johannes a
while ago as well (check git log), and in fact based on conversations
with Johannes it seems to there was some confusion over the exact
strategy for that, so my recommendation is to verify this with Johannes
(this might be a good candidate technical discussion at the workshop
being discussed elsewhere).
Lastly, we should check with FreeBSD to see if they really care on
sharing, its why we went through the trouble and relicensed all the
regulatory code to ISC. Last I checked with Adrian sharing was a nice
thought but I don't think it was going to happen, if that's the case
the only other reason to use ISC was to help enable regulatory code
to be used on firmware as well. If that's not something really tangible
we should just end the ISC practice on regulatory and embrace GPLv2
as we do with other kernel code.
Happy to help anyone wishing to undertake this :) Any volunteers?
Luis
On Mon, Jun 23, 2014 at 02:20:15PM -0700, Ben Greear wrote:
> On 06/23/2014 01:54 PM, Luis R. Rodriguez wrote:
> > On Mon, Jun 23, 2014 at 01:37:37PM -0700, Ben Greear wrote:
> >> On 06/23/2014 12:15 PM, Luis R. Rodriguez wrote:
> >>>
> >>> Adding wireless-regdb.
> >>>
> >>> Regulatory folks:
> >>>
> >>> if two cards are present on a system, in the worst case consider
> >>> two different cards for AP mode, and one has a DFS region set for the
> >>> country its on but the other does not, do we want to use the DFS region
> >>> for both? DFS would not be allowed on system unless the DFS region is
> >>> set. DFS operation requires a card to explicitly support DFS though so
> >>> even though it can be set as an intersection each card would still
> >>> require DFS suport for that region.
> >>>
> >>> As I see it this will depend on what we want cards to do if the DFS
> >>> region is unknown for a region. If the DFS region is not known can
> >>> we use any DFS algorithm? If we cannot then I think a DFS intersection
> >>> would require agreement on the DFS region. That would also mean though
> >>> that when shipping products if a system is built with one card that has
> >>> DFS for ETSI for example, and then a secondary card is present and its
> >>> regulatory domain does not have DFS then the first card would not be
> >>> able to operate on the DFS. I think this is reasonable given that
> >>> the two cards must at least agree on the regulatory domain, otherwise
> >>> the folks doing system integration probably did a bad job at thinking
> >>> of things ahead of time. Even though this can be technically true I
> >>> foresee folks this misconfiguration happening in the future and folks
> >>> beingp puzzled by this as an issue. This means this should be documented
> >>> for folks selling devices in a combined wifi system.
> >>
> >> Maybe some stuff should be per-NIC instead of per OS instance. It would
> >> suck if adding some ancient USB wifi NIC to a system disabled shiny new
> >> features on already-existing NICs.
> >
> > That indeed is a good example corner case that is needs to be thought of
> > here. Say a system is designed that is DFS certified for DFS-ETSI and
> > then someone plugs in a card that had a regulatory domain for a a
> > country where the DFS region is not known -- what should we do with the
> > system in terms of DFS support? Disable DFS ? Or force the DFS-ETSI for
> > both devices? The safe thing IMHO is to disable DFS and ensure folks
> > are aware of this, and to help add a print to the system logs to ensure
> > its understood what just happened.
>
> Why not let the DFS-ETSI NIC do DFS-ETSI, and let the other one not do
> DFS at all?
That would entail not intersecting but we do interesection so we need
to pick a suitable intersection algorithm. So since we are intersecting
we need to pick something, since not having a DFS region means not
allowing DFS the intersection currently does not allow DFS. Note that
the issue you originally reported is different though -- the world
regulatory domain does have no DFS region set so if the user did
request a regulatory change to a specific country that DFS region
should be used. A fix for that is addressed in another thread. Let's
keep this thread to address the case where an intersection is
required between two regulatory domains, one that does have a DFS
region and one that does not.
I'll let regulatory folks chime in on what they want to do. Right
now an intersection means in the above situatio means not allowing
DFS. Since I no longer work for a silicon company the regulatory folks
are hopefully going to be a bit more vocal about these types of things.
Possibly they won't address this question until the real world situation
happens and a customer demands a fix ;)
> As soon as you get two different NICS with different regulatory domains,
> you basically should assume that the regulatory info based on those
> NICs is close to worthless, so one shouldn't be able to impede the other.
You can always do what you want with your custom systems enable ONUS
thing, ATH_REG_DYNAMIC_USER_REG_HINTS, if you're really daring
ATH_REG_DYNAMIC_USER_CERT_TESTING and go take your systems to a lab,
ceritfy and good luck. By default upstream we'll be careful.
> Maybe just use time-zone or user hints in this case since NICs cannot
> be fully trusted.
WTF no, the regulatory hint stuff should all be automated and user input
should really only come from trusted sources, see the cell base station
hint as a good example use case. The NICs are trusted as that's what
regulatory bodies like folks to do. Hell even the country IEs are only
trusted for the alpha2, the actual contents are disregarded. Regular
user input should only help compliance further, that's it.
Luis
I started trying to do some more DFS testing on a 3.14.8+ kernel,
and from what I can tell, the US region is configured for
DFS-Unset. I was assuming this should be set to DFS_FCC.
I tried installing the latest regulatory.bin. crda is whatever
is standard on Fedora 19.
Do you know if DFS is supposed to work at all in the 3.14 kernel?
I'm certain I had this working earlier on this machine,
but I was on a somewhat patched linux.ath tree at the
time it seems....
Thanks,
Ben
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com
On 06/25/2014 10:20 AM, Luis R. Rodriguez wrote:
> On Wed, Jun 25, 2014 at 9:48 AM, Ben Greear <[email protected]> wrote:
>> I started trying to do some more DFS testing on a 3.14.8+ kernel,
>> and from what I can tell, the US region is configured for
>> DFS-Unset. I was assuming this should be set to DFS_FCC.
>>
>> I tried installing the latest regulatory.bin. crda is whatever
>> is standard on Fedora 19.
>>
>> Do you know if DFS is supposed to work at all in the 3.14 kernel?
>
> DFS region support was added upstream via 8b60b07805
>
> mcgrof@ergon ~/linux (git::master)$ git describe --contains 8b60b07805
> v3.3-rc1~182^2~44^2~384
>
> Now, that doesn't mean a driver will have DFS support of course. I'm
> not going to treasure hunt that for you.
The driver (ath10k) works, and if I manually force the 'US' regulatory domain
to use DFS-FCC in set_regdom in reg.c, then it shows up as DFS-FCC in 'iw reg get'
and hostapd & driver properly detects radar since airport is nearby, hostapd
chooses a different channel, and things go on working.
>> I'm certain I had this working earlier on this machine,
>> but I was on a somewhat patched linux.ath tree at the
>> time it seems....
>
> There's an issue Krishna reported about internal db now parsing the
> new db.txt format properly after the antenna gain removal but a patch
> is supposed to be on the way. You don't seem to be using that though
> so you may want to debug things a bit further.
Is the 'regulatory.bin' from today's wireless-regdb repository
correct? I did not try regenerating it..I just did a git pull...
Thanks,
Ben
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com
On Wed, Jun 25, 2014 at 9:48 AM, Ben Greear <[email protected]> wrote:
> I started trying to do some more DFS testing on a 3.14.8+ kernel,
> and from what I can tell, the US region is configured for
> DFS-Unset. I was assuming this should be set to DFS_FCC.
>
> I tried installing the latest regulatory.bin. crda is whatever
> is standard on Fedora 19.
>
> Do you know if DFS is supposed to work at all in the 3.14 kernel?
DFS region support was added upstream via 8b60b07805
mcgrof@ergon ~/linux (git::master)$ git describe --contains 8b60b07805
v3.3-rc1~182^2~44^2~384
Now, that doesn't mean a driver will have DFS support of course. I'm
not going to treasure hunt that for you.
> I'm certain I had this working earlier on this machine,
> but I was on a somewhat patched linux.ath tree at the
> time it seems....
There's an issue Krishna reported about internal db now parsing the
new db.txt format properly after the antenna gain removal but a patch
is supposed to be on the way. You don't seem to be using that though
so you may want to debug things a bit further.
Luis
On 25 June 2014 19:34, Ben Greear <[email protected]> wrote:
> On 06/25/2014 10:20 AM, Luis R. Rodriguez wrote:
>> On Wed, Jun 25, 2014 at 9:48 AM, Ben Greear <[email protected]> wrote:
>>> I started trying to do some more DFS testing on a 3.14.8+ kernel,
>>> and from what I can tell, the US region is configured for
>>> DFS-Unset. I was assuming this should be set to DFS_FCC.
>>>
>>> I tried installing the latest regulatory.bin. crda is whatever
>>> is standard on Fedora 19.
>>>
>>> Do you know if DFS is supposed to work at all in the 3.14 kernel?
>>
>> DFS region support was added upstream via 8b60b07805
>>
>> mcgrof@ergon ~/linux (git::master)$ git describe --contains 8b60b07805
>> v3.3-rc1~182^2~44^2~384
>>
>> Now, that doesn't mean a driver will have DFS support of course. I'm
>> not going to treasure hunt that for you.
>
> The driver (ath10k) works, and if I manually force the 'US' regulatory domain
> to use DFS-FCC in set_regdom in reg.c, then it shows up as DFS-FCC in 'iw reg get'
> and hostapd & driver properly detects radar since airport is nearby, hostapd
> chooses a different channel, and things go on working.
>
>>> I'm certain I had this working earlier on this machine,
>>> but I was on a somewhat patched linux.ath tree at the
>>> time it seems....
>>
>> There's an issue Krishna reported about internal db now parsing the
>> new db.txt format properly after the antenna gain removal but a patch
>> is supposed to be on the way. You don't seem to be using that though
>> so you may want to debug things a bit further.
>
> Is the 'regulatory.bin' from today's wireless-regdb repository
> correct? I did not try regenerating it..I just did a git pull...
>
Best get latest regdb, crda:
wireless-regd/ make; make install
crda/ make ; make install (skip warning about world regulatory domain
- I think we will fix this soon).
Next:
modprobe cfg80211
iw reg set US
dmesg (check reg messages)
iw reg get
You should get correct DFS region.
BR
Janusz
On 06/23/2014 12:15 PM, Luis R. Rodriguez wrote:
>
> Adding wireless-regdb.
>
> Regulatory folks:
>
> if two cards are present on a system, in the worst case consider
> two different cards for AP mode, and one has a DFS region set for the
> country its on but the other does not, do we want to use the DFS region
> for both? DFS would not be allowed on system unless the DFS region is
> set. DFS operation requires a card to explicitly support DFS though so
> even though it can be set as an intersection each card would still
> require DFS suport for that region.
>
> As I see it this will depend on what we want cards to do if the DFS
> region is unknown for a region. If the DFS region is not known can
> we use any DFS algorithm? If we cannot then I think a DFS intersection
> would require agreement on the DFS region. That would also mean though
> that when shipping products if a system is built with one card that has
> DFS for ETSI for example, and then a secondary card is present and its
> regulatory domain does not have DFS then the first card would not be
> able to operate on the DFS. I think this is reasonable given that
> the two cards must at least agree on the regulatory domain, otherwise
> the folks doing system integration probably did a bad job at thinking
> of things ahead of time. Even though this can be technically true I
> foresee folks this misconfiguration happening in the future and folks
> beingp puzzled by this as an issue. This means this should be documented
> for folks selling devices in a combined wifi system.
Maybe some stuff should be per-NIC instead of per OS instance. It would
suck if adding some ancient USB wifi NIC to a system disabled shiny new
features on already-existing NICs.
As for being confusing, the current code is nasty and it is very hard
to have any idea why things do or do not work, especially if you do not
have ability to add printk all over the place to figure out what the
code is actually doing.
I think some more effort should go into printing out a lot more
information about the regulator domain decisions, through printk
or related call if nothing better is found...
Thanks,
Ben
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com
Adding wireless-regdb.
Regulatory folks:
if two cards are present on a system, in the worst case consider
two different cards for AP mode, and one has a DFS region set for the
country its on but the other does not, do we want to use the DFS region
for both? DFS would not be allowed on system unless the DFS region is
set. DFS operation requires a card to explicitly support DFS though so
even though it can be set as an intersection each card would still
require DFS suport for that region.
As I see it this will depend on what we want cards to do if the DFS
region is unknown for a region. If the DFS region is not known can
we use any DFS algorithm? If we cannot then I think a DFS intersection
would require agreement on the DFS region. That would also mean though
that when shipping products if a system is built with one card that has
DFS for ETSI for example, and then a secondary card is present and its
regulatory domain does not have DFS then the first card would not be
able to operate on the DFS. I think this is reasonable given that
the two cards must at least agree on the regulatory domain, otherwise
the folks doing system integration probably did a bad job at thinking
of things ahead of time. Even though this can be technically true I
foresee folks this misconfiguration happening in the future and folks
beingp puzzled by this as an issue. This means this should be documented
for folks selling devices in a combined wifi system.
As such NACK for now.
Luis
On Wed, Jun 11, 2014 at 01:08:34PM -0700, [email protected] wrote:
> From: Ben Greear <[email protected]>
>
> If one is UN-SET, use the other. Seems this would
> be more correct that what we have now.
>
> Signed-off-by: Ben Greear <[email protected]>
> ---
>
> Someone that understands this code better than I
> do should review this well before it is considered
> for upstream. I'm not sure it is actually needed.
>
> net/wireless/reg.c | 9 ++++++++-
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/net/wireless/reg.c b/net/wireless/reg.c
> index 785e516..b87035f 100644
> --- a/net/wireless/reg.c
> +++ b/net/wireless/reg.c
> @@ -727,8 +727,15 @@ static enum nl80211_dfs_regions
> reg_intersect_dfs_region(const enum nl80211_dfs_regions dfs_region1,
> const enum nl80211_dfs_regions dfs_region2)
> {
> - if (dfs_region1 != dfs_region2)
> + if (dfs_region1 != dfs_region2) {
> + pr_info("intersect-dfs-region, region1: %d region2: %d\n",
> + dfs_region1, dfs_region2);
> + if (dfs_region1 == NL80211_DFS_UNSET)
> + return dfs_region2;
> + if (dfs_region2 == NL80211_DFS_UNSET)
> + return dfs_region1;
> return NL80211_DFS_UNSET;
> + }
> return dfs_region1;
> }
>
Ben Greear <[email protected]> writes:
> As for being confusing, the current code is nasty and it is very hard
> to have any idea why things do or do not work, especially if you do not
> have ability to add printk all over the place to figure out what the
> code is actually doing.
Heh, this is exatly what I do when I debug regulatory issues :)
> I think some more effort should go into printing out a lot more
> information about the regulator domain decisions, through printk
> or related call if nothing better is found...
IMHO the regulatory code is the most fragile part of Linux wireless
stack and needs a rewrite. It needs to be simple and easy to understand.
--
Kalle Valo
>> Maybe just use time-zone or user hints in this case since NICs cannot
>> be fully trusted.
>
> WTF no, the regulatory hint stuff should all be automated and user input
> should really only come from trusted sources, see the cell base station
> hint as a good example use case. The NICs are trusted as that's what
> regulatory bodies like folks to do. Hell even the country IEs are only
> trusted for the alpha2, the actual contents are disregarded. Regular
> user input should only help compliance further, that's it.
NICs just aren't that reliable, seems you can buy NICs with any number
of regulatory domains on the interweb, and then you can hop on a plane
and go other interesting places.
If you ever have a system with NICs with two different regulatory domains,
I assume it is very likely that it was not certified in that configuration.
Maybe the user's input (and AP's beacons and such) are more reliable in this
case.
But, not worth arguing about at this point. As long as the basic regulatory
bugs are fixed (as per the other thread), then my problems should be solveable.
Thanks,
Ben
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com
On Mon, Jun 23, 2014 at 01:37:37PM -0700, Ben Greear wrote:
> On 06/23/2014 12:15 PM, Luis R. Rodriguez wrote:
> >
> > Adding wireless-regdb.
> >
> > Regulatory folks:
> >
> > if two cards are present on a system, in the worst case consider
> > two different cards for AP mode, and one has a DFS region set for the
> > country its on but the other does not, do we want to use the DFS region
> > for both? DFS would not be allowed on system unless the DFS region is
> > set. DFS operation requires a card to explicitly support DFS though so
> > even though it can be set as an intersection each card would still
> > require DFS suport for that region.
> >
> > As I see it this will depend on what we want cards to do if the DFS
> > region is unknown for a region. If the DFS region is not known can
> > we use any DFS algorithm? If we cannot then I think a DFS intersection
> > would require agreement on the DFS region. That would also mean though
> > that when shipping products if a system is built with one card that has
> > DFS for ETSI for example, and then a secondary card is present and its
> > regulatory domain does not have DFS then the first card would not be
> > able to operate on the DFS. I think this is reasonable given that
> > the two cards must at least agree on the regulatory domain, otherwise
> > the folks doing system integration probably did a bad job at thinking
> > of things ahead of time. Even though this can be technically true I
> > foresee folks this misconfiguration happening in the future and folks
> > beingp puzzled by this as an issue. This means this should be documented
> > for folks selling devices in a combined wifi system.
>
> Maybe some stuff should be per-NIC instead of per OS instance. It would
> suck if adding some ancient USB wifi NIC to a system disabled shiny new
> features on already-existing NICs.
That indeed is a good example corner case that is needs to be thought of
here. Say a system is designed that is DFS certified for DFS-ETSI and
then someone plugs in a card that had a regulatory domain for a a
country where the DFS region is not known -- what should we do with the
system in terms of DFS support? Disable DFS ? Or force the DFS-ETSI for
both devices? The safe thing IMHO is to disable DFS and ensure folks
are aware of this, and to help add a print to the system logs to ensure
its understood what just happened.
> As for being confusing, the current code is nasty and it is very hard
> to have any idea why things do or do not work, especially if you do not
> have ability to add printk all over the place to figure out what the
> code is actually doing.
Patches welcomed. The state machine should be easy to see if someone
wanted to by registering to the multicast regulatory group and showing
a change as things move forward.
> I think some more effort should go into printing out a lot more
> information about the regulator domain decisions, through printk
> or related call if nothing better is found...
There's already tons of debug prints, I think better time is spent
on userespace keeping track of the regulatory state machine and
making it easy for folks to follow. Adding diagrams, colors, whatever.
Luis
On Wed, Jun 25, 2014 at 10:34 AM, Ben Greear <[email protected]> wrote:
> Is the 'regulatory.bin' from today's wireless-regdb repository
> correct? I did not try regenerating it..I just did a git pull...
John?
Luis
"Luis R. Rodriguez" <[email protected]> writes:
> On Tue, Jun 24, 2014 at 08:47:46AM +0300, Kalle Valo wrote:
>> Ben Greear <[email protected]> writes:
>>
>> > As for being confusing, the current code is nasty and it is very hard
>> > to have any idea why things do or do not work, especially if you do not
>> > have ability to add printk all over the place to figure out what the
>> > code is actually doing.
>>
>> Heh, this is exatly what I do when I debug regulatory issues :)
>
> CFG80211_REG_DEBUG isn't too chatty already?
Unfortunately it's not enough. Sometimes I need to debug the regulatory
code line by line, it's just that difficult to understand. There are all
sort of odd checks everywhere in the code which affect behaviour.
>> > I think some more effort should go into printing out a lot more
>> > information about the regulator domain decisions, through printk
>> > or related call if nothing better is found...
>>
>> IMHO the regulatory code is the most fragile part of Linux wireless
>> stack
>
> Changing anything on regulatory can have an impact on many things but
> lets be clear of the difference on the nature of quality over impact due
> to the nature of what the code does and its impact. I invite you to
> compare the code quality on the existing regulatory infrastructure from
> what was in place on the atheros driver HAL for regulatory control. Now
> *that* was incomprensible and somehow we managed to evolve to something
> central and shared on Linux.
Sure. I haven't looked at HAL, but I'm sure what we have in cfg80211 is
better. But the way I'm seeing is that everyone are just submitting
random fixes for their issues and the code is getting more convuluted in
every release :/ And I also see that some of the functionality in
regulatory code seems to happen by accident, not by design. So I'm
getting very worried about this.
> Code needs to evolve though and I do agree we need to evolve things
> to a more mature foundation. More details on that regards below.
>
>> and needs a rewrite. It needs to be simple and easy to understand.
>
> There is actually quite a bit of documentation:
>
> http://wireless.kernel.org/en/developers/Regulatory
> http://wireless.kernel.org/en/developers/Regulatory/processing_rules
> http://wireless.kernel.org/en/developers/Regulatory/CRDA
> http://wireless.kernel.org/en/developers/Regulatory/wireless-regdb
>
> I'm not familiar with smaller pieces of code on the kernel with as much
> documentation as this. The code actually also includes quite a bit of
> kdoc and comments. Small code changes however can have an impact though
> and as technologies advances we have more complex corner cases and
> the state machine of regulatory keeps evolving as such a more evolved
> infrastructure is indeed needed to help us cope and ensure we don't
> have regressions as we evolve the code.
I don't think documentation is the solution here. Documentation is
always behind the actual implementation and it doesn't really help to
fix bugs. The best is if the code is simple enough so that it documents
itself.
--
Kalle Valo
On Mon, Jun 23, 2014 at 7:35 PM, Ben Greear <[email protected]> wrote:
>
>>> Maybe just use time-zone or user hints in this case since NICs cannot
>>> be fully trusted.
>>
>>
>> WTF no, the regulatory hint stuff should all be automated and user input
>> should really only come from trusted sources, see the cell base station
>> hint as a good example use case. The NICs are trusted as that's what
>> regulatory bodies like folks to do. Hell even the country IEs are only
>> trusted for the alpha2, the actual contents are disregarded. Regular
>> user input should only help compliance further, that's it.
>
>
> NICs just aren't that reliable, seems you can buy NICs with any number
> of regulatory domains on the interweb, and then you can hop on a plane
> and go other interesting places.
You can also reverse engineer firmware, also design RW support on OTPs
and EEPROMs, so there's tons of ways one can circumvent regulatory,
its not meant to be perfect, specially since tons of software is
required for hugely complex regulatory compliance rules such as in
DFS. We however do the best to enable all types of devices to be
compliant, we do the very best, and its also why we get vendor support
upstream even with open firmware designs. Location information is also
important for a device that get calibrated for a specific region --
the architecture on some devices mandates that you can only fit
certain things into hardware / OTP / EEPOM and some folks optimize
functionality of a card so that that very specific tuning applies only
to a specific region it got certified for, so the ideal operation of a
device is for what area it was designed for. If folks repuropose them
it may not work as well.What ends up in the market will vary and what
folks do in their basement or lab is up to them -- enable onus kernel
flag stuff and go to town.
There's tons of good resources an operating system can rely on to
guarantee the region other than a stupid EEPROM / OTP / Country IE,
the ideal solution folks should strive for would be a series of
heuristics that can guarantee this and only use the OTP / whatever for
when the location cannot be known for sure.
An easy start up idea would be to find a really cheap way to ensure
this for hardware other than GPS. The resolution would suffice to be
ISO3166 specific to the most popular countries.
> If you ever have a system with NICs with two different regulatory domains,
Folks should not be selling these and if they end up with them the
intersection is taken, and additionally user input is welcomed.
> I assume it is very likely that it was not certified in that configuration.
A device *sold* under that configuration would need to be certified.
> Maybe the user's input (and AP's beacons and such) are more reliable in this
> case.
Location information should use a series of heuristics, and a degree
of trust should be used to quality them. Userespace input for hints
coming from cell base stations are of a good source, as an example and
some folks ship products using it. Users should only be allowed to
help compliance further, that's it. The default stuff should be done
without any user input.
> But, not worth arguing about at this point. As long as the basic regulatory
> bugs are fixed (as per the other thread), then my problems should be
> solveable.
Yes, lets use our time effectively please.
Luis
On 06/23/2014 01:54 PM, Luis R. Rodriguez wrote:
> On Mon, Jun 23, 2014 at 01:37:37PM -0700, Ben Greear wrote:
>> On 06/23/2014 12:15 PM, Luis R. Rodriguez wrote:
>>>
>>> Adding wireless-regdb.
>>>
>>> Regulatory folks:
>>>
>>> if two cards are present on a system, in the worst case consider
>>> two different cards for AP mode, and one has a DFS region set for the
>>> country its on but the other does not, do we want to use the DFS region
>>> for both? DFS would not be allowed on system unless the DFS region is
>>> set. DFS operation requires a card to explicitly support DFS though so
>>> even though it can be set as an intersection each card would still
>>> require DFS suport for that region.
>>>
>>> As I see it this will depend on what we want cards to do if the DFS
>>> region is unknown for a region. If the DFS region is not known can
>>> we use any DFS algorithm? If we cannot then I think a DFS intersection
>>> would require agreement on the DFS region. That would also mean though
>>> that when shipping products if a system is built with one card that has
>>> DFS for ETSI for example, and then a secondary card is present and its
>>> regulatory domain does not have DFS then the first card would not be
>>> able to operate on the DFS. I think this is reasonable given that
>>> the two cards must at least agree on the regulatory domain, otherwise
>>> the folks doing system integration probably did a bad job at thinking
>>> of things ahead of time. Even though this can be technically true I
>>> foresee folks this misconfiguration happening in the future and folks
>>> beingp puzzled by this as an issue. This means this should be documented
>>> for folks selling devices in a combined wifi system.
>>
>> Maybe some stuff should be per-NIC instead of per OS instance. It would
>> suck if adding some ancient USB wifi NIC to a system disabled shiny new
>> features on already-existing NICs.
>
> That indeed is a good example corner case that is needs to be thought of
> here. Say a system is designed that is DFS certified for DFS-ETSI and
> then someone plugs in a card that had a regulatory domain for a a
> country where the DFS region is not known -- what should we do with the
> system in terms of DFS support? Disable DFS ? Or force the DFS-ETSI for
> both devices? The safe thing IMHO is to disable DFS and ensure folks
> are aware of this, and to help add a print to the system logs to ensure
> its understood what just happened.
Why not let the DFS-ETSI NIC do DFS-ETSI, and let the other one not do
DFS at all?
As soon as you get two different NICS with different regulatory domains,
you basically should assume that the regulatory info based on those
NICs is close to worthless, so one shouldn't be able to impede the other.
Maybe just use time-zone or user hints in this case since NICs cannot
be fully trusted.
Thanks,
Ben
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com