| Message ID | 871324710.20131211191104@eikelenboom.it |
|---|---|
| State | Not Applicable, archived |
| Delegated to: | David Miller |
| Headers | show |
On Wed, Dec 11, 2013 at 7:11 PM, Sander Eikelenboom <linux@eikelenboom.it> wrote: > > Wednesday, December 11, 2013, 6:53:07 PM, you wrote: > >> The best way to address all this is by automatic region awareness and >> doing the right thing on devices, this however requires good >> architecture / calibration data / etc and all that needs to be >> verified by the system integrators, and finally they need to be >> certified. If you want to hack your firmware and software go at it, >> just be aware there are reasons for things. > > Well the general problem seems to be "we don't trust the user" so we FORCE him to the lowest > common denominator (without a way to overrule that) so he is forced to operate *well* within the law. Its simply stupid to have the user be involved, period, the fact that a user would be involved should only be for testing or helping compliance for a busted device, development, research and obviously hacking. Linux allows all these but by default a device with firmware and a custom regdomain that will barf if you try to use a channel that is not allowed is a restriction in firmware. Feel free to reverse engineer that if you don't like it but it just won't be supported or go upstream. Now, the common denominator is generally optimized for best performance as well so you shouldn't have to do anything, and for APs -- this is typically carefully crafted for a region, also highly optimized. >>>> It doesn't seem like you are getting your original requests getting >>>> processed, so I don't think CRDA is passing it. Can you verify running >>>> from CRDA code: >>> >>> They don't get processed unless i remove the return from the code as i indicated. >>> If i remove that return it processes the request. >>> >>>> ./regdbdump /usr/lib/crda/regulatory.bin >>> >>> Although it's in a different location on Debian, /lib/crda/regulatory.bin >>> the dump seems fine. > >> OK thanks. Can you send a patch of what exact change you made, it was >> unclear from the paste you made. > >> diff -u file.c.orig file.c > > Well i just did a pull from wireless-next, to try Avinash Patil's patch. > net/wireless/reg.c had already changed much so i couldn't apply his patch without. > > With his patch it sets the regulatory domain, although as now expected i still can not use channels 12 and 13 yet, > probably due to those firmware restrictions. Its unclear what results you got, and yeah if the device is restricted then its just the fw telling the driver its channels and you can't use them. That's it. You won't be able to override information then unless you hack the firmware. Luis -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Wednesday, December 11, 2013, 7:38:50 PM, you wrote: > On Wed, Dec 11, 2013 at 7:11 PM, Sander Eikelenboom > <linux@eikelenboom.it> wrote: >> >> Wednesday, December 11, 2013, 6:53:07 PM, you wrote: >> >>> The best way to address all this is by automatic region awareness and >>> doing the right thing on devices, this however requires good >>> architecture / calibration data / etc and all that needs to be >>> verified by the system integrators, and finally they need to be >>> certified. If you want to hack your firmware and software go at it, >>> just be aware there are reasons for things. >> >> Well the general problem seems to be "we don't trust the user" so we FORCE him to the lowest >> common denominator (without a way to overrule that) so he is forced to operate *well* within the law. > Its simply stupid to have the user be involved, period, the fact that > a user would be involved should only be for testing or helping > compliance for a busted device, development, research and obviously > hacking. Linux allows all these but by default a device with firmware > and a custom regdomain that will barf if you try to use a channel that > is not allowed is a restriction in firmware. Feel free to reverse > engineer that if you don't like it but it just won't be supported or > go upstream. Now, the common denominator is generally optimized for > best performance as well so you shouldn't have to do anything, and for > APs -- this is typically carefully crafted for a region, also highly > optimized. Well how about a car maker shipping al his cars capped to say 10 miles an hour, because somewhere in the world that's the lowest. So to prevent you from breaking the law we will cap your 500HP engine, owh in your country you have a higher speedlimit, ah wel bad luck for you then. We need to enforce this so no one is going to brake any law any where. It's just plain stupid in my opinion (but not something linux can do much about, but it's about enforcing this stuff in firmware in general and thinking too much for the user (fine if you are capable to do so, but in this case clearly not, since there is no automatic way to detect in which country the device is, except by relying on user input). Why just don't set the safe and restricted value on boot and let the user overrule that if he wishes. (that means the user has to invoke a action, so he also should be aware of the consequences). >>>>> It doesn't seem like you are getting your original requests getting >>>>> processed, so I don't think CRDA is passing it. Can you verify running >>>>> from CRDA code: >>>> >>>> They don't get processed unless i remove the return from the code as i indicated. >>>> If i remove that return it processes the request. >>>> >>>>> ./regdbdump /usr/lib/crda/regulatory.bin >>>> >>>> Although it's in a different location on Debian, /lib/crda/regulatory.bin >>>> the dump seems fine. >> >>> OK thanks. Can you send a patch of what exact change you made, it was >>> unclear from the paste you made. >> >>> diff -u file.c.orig file.c >> >> Well i just did a pull from wireless-next, to try Avinash Patil's patch. >> net/wireless/reg.c had already changed much so i couldn't apply his patch without. >> >> With his patch it sets the regulatory domain, although as now expected i still can not use channels 12 and 13 yet, >> probably due to those firmware restrictions. > Its unclear what results you got, and yeah if the device is restricted > then its just the fw telling the driver its channels and you can't use > them. That's it. You won't be able to override information then unless > you hack the firmware. Without the patch: - "iw reg get" gives country 00 - now do a "iw reg set US", no error so it should be fine - now do a "iw reg get" .. gives country 00 again, so it has not been set to the country requested. With the patch: - "iw reg get" gives country 00 - now do a "iw reg set US", no error so it should be fine - now do a "iw reg get" .. gives country US, so it has been set to the country requested. > Luis -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Wednesday, December 11, 2013, 7:38:50 PM, you wrote: > On Wed, Dec 11, 2013 at 7:11 PM, Sander Eikelenboom > <linux@eikelenboom.it> wrote: >> >> Wednesday, December 11, 2013, 6:53:07 PM, you wrote: >> >>> The best way to address all this is by automatic region awareness and >>> doing the right thing on devices, this however requires good >>> architecture / calibration data / etc and all that needs to be >>> verified by the system integrators, and finally they need to be >>> certified. If you want to hack your firmware and software go at it, >>> just be aware there are reasons for things. >> >> Well the general problem seems to be "we don't trust the user" so we FORCE him to the lowest >> common denominator (without a way to overrule that) so he is forced to operate *well* within the law. > Its simply stupid to have the user be involved, period, the fact that > a user would be involved should only be for testing or helping > compliance for a busted device, development, research and obviously > hacking. Linux allows all these but by default a device with firmware > and a custom regdomain that will barf if you try to use a channel that > is not allowed is a restriction in firmware. Feel free to reverse > engineer that if you don't like it but it just won't be supported or > go upstream. Now, the common denominator is generally optimized for > best performance as well so you shouldn't have to do anything, and for > APs -- this is typically carefully crafted for a region, also highly > optimized. >>>>> It doesn't seem like you are getting your original requests getting >>>>> processed, so I don't think CRDA is passing it. Can you verify running >>>>> from CRDA code: >>>> >>>> They don't get processed unless i remove the return from the code as i indicated. >>>> If i remove that return it processes the request. >>>> >>>>> ./regdbdump /usr/lib/crda/regulatory.bin >>>> >>>> Although it's in a different location on Debian, /lib/crda/regulatory.bin >>>> the dump seems fine. >> >>> OK thanks. Can you send a patch of what exact change you made, it was >>> unclear from the paste you made. >> >>> diff -u file.c.orig file.c >> >> Well i just did a pull from wireless-next, to try Avinash Patil's patch. >> net/wireless/reg.c had already changed much so i couldn't apply his patch without. >> >> With his patch it sets the regulatory domain, although as now expected i still can not use channels 12 and 13 yet, >> probably due to those firmware restrictions. > Its unclear what results you got, and yeah if the device is restricted > then its just the fw telling the driver its channels and you can't use > them. That's it. You won't be able to override information then unless > you hack the firmware Ping ? Is there anymore information you need to *fix* the problem ? > Luis -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 12/16/2013 12:22 PM, Sander Eikelenboom wrote: > > Wednesday, December 11, 2013, 7:38:50 PM, you wrote: > >> On Wed, Dec 11, 2013 at 7:11 PM, Sander Eikelenboom >> <linux@eikelenboom.it> wrote: >>> >>> Wednesday, December 11, 2013, 6:53:07 PM, you wrote: >>> >>>> The best way to address all this is by automatic region awareness and >>>> doing the right thing on devices, this however requires good >>>> architecture / calibration data / etc and all that needs to be >>>> verified by the system integrators, and finally they need to be >>>> certified. If you want to hack your firmware and software go at it, >>>> just be aware there are reasons for things. >>> >>> Well the general problem seems to be "we don't trust the user" so we FORCE him to the lowest >>> common denominator (without a way to overrule that) so he is forced to operate *well* within the law. > >> Its simply stupid to have the user be involved, period, the fact that >> a user would be involved should only be for testing or helping >> compliance for a busted device, development, research and obviously >> hacking. Linux allows all these but by default a device with firmware >> and a custom regdomain that will barf if you try to use a channel that >> is not allowed is a restriction in firmware. Feel free to reverse >> engineer that if you don't like it but it just won't be supported or >> go upstream. Now, the common denominator is generally optimized for >> best performance as well so you shouldn't have to do anything, and for >> APs -- this is typically carefully crafted for a region, also highly >> optimized. > >>>>>> It doesn't seem like you are getting your original requests getting >>>>>> processed, so I don't think CRDA is passing it. Can you verify running >>>>>> from CRDA code: >>>>> >>>>> They don't get processed unless i remove the return from the code as i indicated. >>>>> If i remove that return it processes the request. >>>>> >>>>>> ./regdbdump /usr/lib/crda/regulatory.bin >>>>> >>>>> Although it's in a different location on Debian, /lib/crda/regulatory.bin >>>>> the dump seems fine. >>> >>>> OK thanks. Can you send a patch of what exact change you made, it was >>>> unclear from the paste you made. >>> >>>> diff -u file.c.orig file.c >>> >>> Well i just did a pull from wireless-next, to try Avinash Patil's patch. >>> net/wireless/reg.c had already changed much so i couldn't apply his patch without. >>> >>> With his patch it sets the regulatory domain, although as now expected i still can not use channels 12 and 13 yet, >>> probably due to those firmware restrictions. > >> Its unclear what results you got, and yeah if the device is restricted >> then its just the fw telling the driver its channels and you can't use >> them. That's it. You won't be able to override information then unless >> you hack the firmware > > Ping ? > > Is there anymore information you need to *fix* the problem ? Maybe you did not get the essence of the response from Luis: There is *no* problem to be fixed. Gr. AvS -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Dec 16, 2013 at 12:22:00PM +0100, Sander Eikelenboom wrote: > > Wednesday, December 11, 2013, 7:38:50 PM, you wrote: > > > On Wed, Dec 11, 2013 at 7:11 PM, Sander Eikelenboom > > <linux@eikelenboom.it> wrote: > >> > >> Wednesday, December 11, 2013, 6:53:07 PM, you wrote: > >> > >>> The best way to address all this is by automatic region awareness and > >>> doing the right thing on devices, this however requires good > >>> architecture / calibration data / etc and all that needs to be > >>> verified by the system integrators, and finally they need to be > >>> certified. If you want to hack your firmware and software go at it, > >>> just be aware there are reasons for things. > >> > >> Well the general problem seems to be "we don't trust the user" so we FORCE him to the lowest > >> common denominator (without a way to overrule that) so he is forced to operate *well* within the law. > > > Its simply stupid to have the user be involved, period, the fact that > > a user would be involved should only be for testing or helping > > compliance for a busted device, development, research and obviously > > hacking. Linux allows all these but by default a device with firmware > > and a custom regdomain that will barf if you try to use a channel that > > is not allowed is a restriction in firmware. Feel free to reverse > > engineer that if you don't like it but it just won't be supported or > > go upstream. Now, the common denominator is generally optimized for > > best performance as well so you shouldn't have to do anything, and for > > APs -- this is typically carefully crafted for a region, also highly > > optimized. > > >>>>> It doesn't seem like you are getting your original requests getting > >>>>> processed, so I don't think CRDA is passing it. Can you verify running > >>>>> from CRDA code: > >>>> > >>>> They don't get processed unless i remove the return from the code as i indicated. > >>>> If i remove that return it processes the request. > >>>> > >>>>> ./regdbdump /usr/lib/crda/regulatory.bin > >>>> > >>>> Although it's in a different location on Debian, /lib/crda/regulatory.bin > >>>> the dump seems fine. > >> > >>> OK thanks. Can you send a patch of what exact change you made, it was > >>> unclear from the paste you made. > >> > >>> diff -u file.c.orig file.c > >> > >> Well i just did a pull from wireless-next, to try Avinash Patil's patch. > >> net/wireless/reg.c had already changed much so i couldn't apply his patch without. > >> > >> With his patch it sets the regulatory domain, although as now expected i still can not use channels 12 and 13 yet, > >> probably due to those firmware restrictions. > > > Its unclear what results you got, and yeah if the device is restricted > > then its just the fw telling the driver its channels and you can't use > > them. That's it. You won't be able to override information then unless > > you hack the firmware > > Ping ? > > Is there anymore information you need to *fix* the problem ? I was away on Travel back home, and will soon be traveling to visit family so e-mail replies will be delayed, I'll jump on this thread now but in short: You are confusing the main issue you reported (cannot override regulatory) as a software issue rather than a firmware issue with intel firmware, you are also making claims and making people believe things work in different ways (I'll clarify things there, proper regulatory support without CRDA works, CRDA is just a helper, we also do have a timeout on requests). Lastly there is one issue that may be a software issue but I cannot reproduce which I am interested in getting down to the bottom to. I'll dive into the different things now. Luis -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Wednesday, December 18, 2013, 7:29:10 PM, you wrote: > On Mon, Dec 16, 2013 at 12:22:00PM +0100, Sander Eikelenboom wrote: >> >> Wednesday, December 11, 2013, 7:38:50 PM, you wrote: >> >> > On Wed, Dec 11, 2013 at 7:11 PM, Sander Eikelenboom >> > <linux@eikelenboom.it> wrote: >> >> >> >> Wednesday, December 11, 2013, 6:53:07 PM, you wrote: >> >> >> >>> The best way to address all this is by automatic region awareness and >> >>> doing the right thing on devices, this however requires good >> >>> architecture / calibration data / etc and all that needs to be >> >>> verified by the system integrators, and finally they need to be >> >>> certified. If you want to hack your firmware and software go at it, >> >>> just be aware there are reasons for things. >> >> >> >> Well the general problem seems to be "we don't trust the user" so we FORCE him to the lowest >> >> common denominator (without a way to overrule that) so he is forced to operate *well* within the law. >> >> > Its simply stupid to have the user be involved, period, the fact that >> > a user would be involved should only be for testing or helping >> > compliance for a busted device, development, research and obviously >> > hacking. Linux allows all these but by default a device with firmware >> > and a custom regdomain that will barf if you try to use a channel that >> > is not allowed is a restriction in firmware. Feel free to reverse >> > engineer that if you don't like it but it just won't be supported or >> > go upstream. Now, the common denominator is generally optimized for >> > best performance as well so you shouldn't have to do anything, and for >> > APs -- this is typically carefully crafted for a region, also highly >> > optimized. >> >> >>>>> It doesn't seem like you are getting your original requests getting >> >>>>> processed, so I don't think CRDA is passing it. Can you verify running >> >>>>> from CRDA code: >> >>>> >> >>>> They don't get processed unless i remove the return from the code as i indicated. >> >>>> If i remove that return it processes the request. >> >>>> >> >>>>> ./regdbdump /usr/lib/crda/regulatory.bin >> >>>> >> >>>> Although it's in a different location on Debian, /lib/crda/regulatory.bin >> >>>> the dump seems fine. >> >> >> >>> OK thanks. Can you send a patch of what exact change you made, it was >> >>> unclear from the paste you made. >> >> >> >>> diff -u file.c.orig file.c >> >> >> >> Well i just did a pull from wireless-next, to try Avinash Patil's patch. >> >> net/wireless/reg.c had already changed much so i couldn't apply his patch without. >> >> >> >> With his patch it sets the regulatory domain, although as now expected i still can not use channels 12 and 13 yet, >> >> probably due to those firmware restrictions. >> >> > Its unclear what results you got, and yeah if the device is restricted >> > then its just the fw telling the driver its channels and you can't use >> > them. That's it. You won't be able to override information then unless >> > you hack the firmware >> >> Ping ? >> >> Is there anymore information you need to *fix* the problem ? > I was away on Travel back home, and will soon be traveling to > visit family so e-mail replies will be delayed, I'll jump on this > thread now but in short: > You are confusing the main issue you reported (cannot override regulatory) > as a software issue rather than a firmware issue with intel firmware, you are > also making claims and making people believe things work in different ways > (I'll clarify things there, proper regulatory support without CRDA works, CRDA > is just a helper, we also do have a timeout on requests). Lastly there is one > issue that may be a software issue but I cannot reproduce which I am > interested in getting down to the bottom to. To hopefully save you some time ... I would suggest reading the thread from bottom to top ;-) A summary .. it's now limited to: Problem: Not being able to set the regulator domain with userspace tools after boot although CRDA works. Condition: This only occurs when i build the modules in, when i use loadable modules all is fine. What seems to happen: - This seems to be due to the fact that when the modules are built-in the modules are initialized *before* the root-filesystem is mounted. - Since the root-filesystem isn't mounted, the CRDA is also not accessible. - The world regulatory domain is now set and the boot continues, but somehow the request keeps pending doesn't seem to be cleared. - *All* subsequent requests to change the regulatory domain, also when the CRDA has become accessible, also keep pending because that first request (at boot) was never fullfilled (or cleared) And IMHO that's a bug. > I'll dive into the different things now. > Luis -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Dec 11, 2013 at 08:06:51PM +0100, Sander Eikelenboom wrote: > > Wednesday, December 11, 2013, 7:38:50 PM, you wrote: > > > On Wed, Dec 11, 2013 at 7:11 PM, Sander Eikelenboom > > <linux@eikelenboom.it> wrote: > >> > >> Wednesday, December 11, 2013, 6:53:07 PM, you wrote: > >> > >>> The best way to address all this is by automatic region awareness and > >>> doing the right thing on devices, this however requires good > >>> architecture / calibration data / etc and all that needs to be > >>> verified by the system integrators, and finally they need to be > >>> certified. If you want to hack your firmware and software go at it, > >>> just be aware there are reasons for things. > >> > >> Well the general problem seems to be "we don't trust the user" so we FORCE him to the lowest > >> common denominator (without a way to overrule that) so he is forced to operate *well* within the law. > > > Its simply stupid to have the user be involved, period, the fact that > > a user would be involved should only be for testing or helping > > compliance for a busted device, development, research and obviously > > hacking. Linux allows all these but by default a device with firmware > > and a custom regdomain that will barf if you try to use a channel that > > is not allowed is a restriction in firmware. Feel free to reverse > > engineer that if you don't like it but it just won't be supported or > > go upstream. Now, the common denominator is generally optimized for > > best performance as well so you shouldn't have to do anything, and for > > APs -- this is typically carefully crafted for a region, also highly > > optimized. > > Well how about a car maker shipping al his cars capped to say 10 miles > an hour, because somewhere in the world that's the lowest. So to > prevent you from breaking the law we will cap your 500HP engine, owh > in your country you have a higher speedlimit, ah wel bad luck for you > then. We need to enforce this so no one is going to brake any law any > where. Don't mix apples and oranges as in this case it does not help. Some 802.11 devices are capable of doing things dynamically and the dynamics of that can exist in firmware or the driver. We have to create APIs to support both, and we have no control over devices that have restrictions in firmware unless the firmware is open as with ath9k_htc or if the firmware is reversed engineered. In the end my own advice to 802.11 vendors has always been that the restictions should be kept in the driver as otherwise they cannot grow / extend to support new regulatory rules / changes or new countries, the code is also complex and simply a true waste in firmware. What vendors do is up to them though, Linux just needs to support all these different types of choices well. > It's just plain stupid in my opinion (but not something linux can do > much about, but it's about enforcing this stuff in firmware in general > and thinking too much for the user (fine if you are capable to do so, > but in this case clearly not, since there is no automatic way to > detect in which country the device is, except by relying on user > input). If you are arguing against regulatory in firmware -- I agree, that's plainly stupid, but we can't do anything about it other than reverse engineer the solutions or proove that we can remain regulatory sane even if we have implemented the solution in the driver, which I can clearly stand behind that statement today. What you say about user knowing better or having to be involved is debatable and I think its frankly stupid to require any user input for location. The future architecture for regulatory should simply be fully automatic with a huge bunch of heuristics to figure out the exact ISO3166-alpha2, today we have that either programmed in, rely on it from the country IE, or we get it from the cellular network (LTE, etc). User input is another source but in the US and JP its now allowed. Cellular input for trusting regulatory is new and in the US its expected you go to some extra lenghts with the FCC to get that device complaint. Linux allows for all these, and we can grow to support more. Keep in mind that in Linux we also allow users to say fsck it, and insist that they know what is best but that then will depend on what the firmware allows too. Linux allows for it all, what vendors do is out of our control unless we have influence. Fortunately we've had quite a bit of influence though and its all been for the better for users. Your main issue is where regulatory is in firmware and I also agree that's silly. We can't do anything over that unless we had firmware source code or the firmware was reversed engineered. We can also convince folks that code is simply a waste in firmware and that we have better controls and features in kernel, which we do. > Why just don't set the safe and restricted value on boot and > let the user overrule that if he wishes. (that means the user has to > invoke a action, so he also should be aware of the consequences). Some countries explicitly don't allow user input for regulatory. JP And US are two of those countries. Drivers can allow support for this and give developers / testers the flexibility to test things in controlled ways, see CONFIG_ATH_REG_DYNAMIC_USER_REG_HINTS and also see CONFIG_ATH_REG_DYNAMIC_USER_CERT_TESTING. This is purely driver specific though and its up to each device driver to use APIs that give this flexibility in ways that are suitable and agreeable with their strategy. We can't change laws, but we can at least provide proper architecture to address all possibilities. We support it all. Vendors have to decide what to do and that is out of our direct control. > >>>>> It doesn't seem like you are getting your original requests getting > >>>>> processed, so I don't think CRDA is passing it. Can you verify running > >>>>> from CRDA code: > >>>> > >>>> They don't get processed unless i remove the return from the code as i indicated. > >>>> If i remove that return it processes the request. > >>>> > >>>>> ./regdbdump /usr/lib/crda/regulatory.bin > >>>> > >>>> Although it's in a different location on Debian, /lib/crda/regulatory.bin > >>>> the dump seems fine. > >> > >>> OK thanks. Can you send a patch of what exact change you made, it was > >>> unclear from the paste you made. > >> > >>> diff -u file.c.orig file.c > >> > >> Well i just did a pull from wireless-next, to try Avinash Patil's patch. > >> net/wireless/reg.c had already changed much so i couldn't apply his patch without. > >> > >> With his patch it sets the regulatory domain, although as now expected i still can not use channels 12 and 13 yet, > >> probably due to those firmware restrictions. > > > Its unclear what results you got, and yeah if the device is restricted > > then its just the fw telling the driver its channels and you can't use > > them. That's it. You won't be able to override information then unless > > you hack the firmware. > > Without the patch: > > - "iw reg get" gives country 00 > - now do a "iw reg set US", no error so it should be fine > - now do a "iw reg get" .. gives country 00 again, so it has not been set to the country requested. > > With the patch: > > - "iw reg get" gives country 00 > - now do a "iw reg set US", no error so it should be fine > - now do a "iw reg get" .. gives country US, so it has been set to the country requested. I'd like to get to the bottom of this. Lets focus on this now. Can you provide the kernel you used? I'd like to reproduce, I can't right now. Luis -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Dec 18, 2013 at 07:54:46PM +0100, Sander Eikelenboom wrote: > > Wednesday, December 18, 2013, 7:29:10 PM, you wrote: > > > On Mon, Dec 16, 2013 at 12:22:00PM +0100, Sander Eikelenboom wrote: > >> > >> Wednesday, December 11, 2013, 7:38:50 PM, you wrote: > >> > >> > On Wed, Dec 11, 2013 at 7:11 PM, Sander Eikelenboom > >> > <linux@eikelenboom.it> wrote: > >> >> > >> >> Wednesday, December 11, 2013, 6:53:07 PM, you wrote: > >> >> > >> >>> The best way to address all this is by automatic region awareness and > >> >>> doing the right thing on devices, this however requires good > >> >>> architecture / calibration data / etc and all that needs to be > >> >>> verified by the system integrators, and finally they need to be > >> >>> certified. If you want to hack your firmware and software go at it, > >> >>> just be aware there are reasons for things. > >> >> > >> >> Well the general problem seems to be "we don't trust the user" so we FORCE him to the lowest > >> >> common denominator (without a way to overrule that) so he is forced to operate *well* within the law. > >> > >> > Its simply stupid to have the user be involved, period, the fact that > >> > a user would be involved should only be for testing or helping > >> > compliance for a busted device, development, research and obviously > >> > hacking. Linux allows all these but by default a device with firmware > >> > and a custom regdomain that will barf if you try to use a channel that > >> > is not allowed is a restriction in firmware. Feel free to reverse > >> > engineer that if you don't like it but it just won't be supported or > >> > go upstream. Now, the common denominator is generally optimized for > >> > best performance as well so you shouldn't have to do anything, and for > >> > APs -- this is typically carefully crafted for a region, also highly > >> > optimized. > >> > >> >>>>> It doesn't seem like you are getting your original requests getting > >> >>>>> processed, so I don't think CRDA is passing it. Can you verify running > >> >>>>> from CRDA code: > >> >>>> > >> >>>> They don't get processed unless i remove the return from the code as i indicated. > >> >>>> If i remove that return it processes the request. > >> >>>> > >> >>>>> ./regdbdump /usr/lib/crda/regulatory.bin > >> >>>> > >> >>>> Although it's in a different location on Debian, /lib/crda/regulatory.bin > >> >>>> the dump seems fine. > >> >> > >> >>> OK thanks. Can you send a patch of what exact change you made, it was > >> >>> unclear from the paste you made. > >> >> > >> >>> diff -u file.c.orig file.c > >> >> > >> >> Well i just did a pull from wireless-next, to try Avinash Patil's patch. > >> >> net/wireless/reg.c had already changed much so i couldn't apply his patch without. > >> >> > >> >> With his patch it sets the regulatory domain, although as now expected i still can not use channels 12 and 13 yet, > >> >> probably due to those firmware restrictions. > >> > >> > Its unclear what results you got, and yeah if the device is restricted > >> > then its just the fw telling the driver its channels and you can't use > >> > them. That's it. You won't be able to override information then unless > >> > you hack the firmware > >> > >> Ping ? > >> > >> Is there anymore information you need to *fix* the problem ? > > > I was away on Travel back home, and will soon be traveling to > > visit family so e-mail replies will be delayed, I'll jump on this > > thread now but in short: > > > You are confusing the main issue you reported (cannot override regulatory) > > as a software issue rather than a firmware issue with intel firmware, you are > > also making claims and making people believe things work in different ways > > (I'll clarify things there, proper regulatory support without CRDA works, CRDA > > is just a helper, we also do have a timeout on requests). Lastly there is one > > issue that may be a software issue but I cannot reproduce which I am > > interested in getting down to the bottom to. > > To hopefully save you some time ... > > I would suggest reading the thread from bottom to top ;-) > > A summary .. it's now limited to: > > Problem: Not being able to set the regulator domain with userspace tools after boot although CRDA works. > Condition: This only occurs when i build the modules in, when i use loadable modules all is fine. > What seems to happen: > - This seems to be due to the fact that when the modules are built-in the modules are initialized *before* the root-filesystem is mounted. > - Since the root-filesystem isn't mounted, the CRDA is also not accessible. > - The world regulatory domain is now set and the boot continues, but somehow the request keeps pending doesn't seem to be cleared. > - *All* subsequent requests to change the regulatory domain, also when the CRDA has become accessible, also keep pending because that first request (at boot) was never fullfilled (or cleared) > > And IMHO that's a bug. Thanks for the summary ! Luis -- To unsubscribe from this list: send the line "unsubscribe netdev" 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 ec54e1a..70a8f0a 100644 --- a/net/wireless/reg.c +++ b/net/wireless/reg.c @@ -1670,6 +1670,8 @@ static void reg_process_hint(struct regulatory_request *reg_request) switch (reg_request->initiator) { case NL80211_REGDOM_SET_BY_CORE: reg_process_hint_core(reg_request); + nl80211_send_reg_change_event(reg_request); + reg_set_request_processed(); return; case NL80211_REGDOM_SET_BY_USER: