| Message ID | 1402517314-20110-1-git-send-email-greearb@candelatech.com (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
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, greearb@candelatech.com wrote: > From: Ben Greear <greearb@candelatech.com> > > If one is UN-SET, use the other. Seems this would > be more correct that what we have now. > > Signed-off-by: Ben Greear <greearb@candelatech.com> > --- > > 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; > } > -- 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
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
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 -- 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
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
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 -- 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
>> 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
On Mon, Jun 23, 2014 at 7:35 PM, Ben Greear <greearb@candelatech.com> 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 -- 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
Ben Greear <greearb@candelatech.com> 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.
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
On Tue, Jun 24, 2014 at 08:47:46AM +0300, Kalle Valo wrote: > Ben Greear <greearb@candelatech.com> 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 Wed, Jun 25, 2014 at 9:48 AM, Ben Greear <greearb@candelatech.com> 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 -- 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
On 06/25/2014 10:20 AM, Luis R. Rodriguez wrote: > On Wed, Jun 25, 2014 at 9:48 AM, Ben Greear <greearb@candelatech.com> 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
On Wed, Jun 25, 2014 at 10:34 AM, Ben Greear <greearb@candelatech.com> 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 -- 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
"Luis R. Rodriguez" <mcgrof@do-not-panic.com> writes: > On Tue, Jun 24, 2014 at 08:47:46AM +0300, Kalle Valo wrote: >> Ben Greear <greearb@candelatech.com> 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.
On 25 June 2014 19:34, Ben Greear <greearb@candelatech.com> wrote: > On 06/25/2014 10:20 AM, Luis R. Rodriguez wrote: >> On Wed, Jun 25, 2014 at 9:48 AM, Ben Greear <greearb@candelatech.com> 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 -- 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
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; }