diff mbox

[cfg80211,/,iwlwifi] setting wireless regulatory domain doesn't work.

Message ID 871324710.20131211191104@eikelenboom.it (mailing list archive)
State Not Applicable, archived
Headers show

Commit Message

Sander Eikelenboom Dec. 11, 2013, 6:11 p.m. UTC
Wednesday, December 11, 2013, 6:53:07 PM, you wrote:

> On Wed, Dec 11, 2013 at 6:28 PM, Sander Eikelenboom
> <linux@eikelenboom.it> wrote:
>> Wednesday, December 11, 2013, 6:14:16 PM, you wrote:
>>> Yeap, that's the case for Intel Atheros, and I think nowadays new
>>> broadcom upstream drivers too. Users should not have to be involved on
>>> setting the regulatory domain, everything should just work
>>> automatically.
>>
>> Erhmm yes that works, under the assumption that the device is not leaving the country it was programmed for at the factory.

> Moving out of a region that you purchased a device is called to "world
> roam". Believe it or not some devices are designed with the intent you
> do not take it out of a country. The Playstation comes to mind as an
> example but I believe some Apple tablets are also in the same
> situation. Some devices like mobile phones obviously need to support
> world roaming and they do, what they do then is build architecture to
> support a base set and then rely on your APs around to see the country
> IE to determine region. Some other devices rely on cellular base
> station information, but that is allowed only in a few countries right
> now and in the US at least this requires some sort of special review
> from FCC on the design. We support all this in the Linux kernel today,
> its up to system integrators to do things and certify things properly.

>> (Or you like to be limited in your abilities, channel 12 and 13 are legal here)
>> That there is a restriction on boot or on first use, i can understand. Crippling a device for it's life time though.

> 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.

>>> 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.

His patch is copy pasted below.


>   Luis


---------- Forwarded message ----------
From: "Avinash Patil" <patila@marvell.com>
Date: Dec 6, 2013 8:31 PM
Subject: [RFC] cfg80211: set regulatory request processed for initiator core
To: <johannes@sipsolutions.net>, <linux-wireless@vger.kernel.org>
Cc:

During cfg80211 init, cfg80211 initializes regulatory to set to
world domain. Here we dont set last request processed flag.
This results into further request set to pending indefinitely.

This patch fixes this by setting last request to processed.

Signed-off-by: Avinash Patil <patila@marvell.com>
---
 net/wireless/reg.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

                treatment = reg_process_hint_user(reg_request);
--
1.7.3.4

--
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

--
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

Comments

Luis R. Rodriguez Dec. 11, 2013, 6:38 p.m. UTC | #1
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 linux-wireless" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Sander Eikelenboom Dec. 11, 2013, 7:06 p.m. UTC | #2
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 linux-wireless" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Sander Eikelenboom Dec. 16, 2013, 11:22 a.m. UTC | #3
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 linux-wireless" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Arend van Spriel Dec. 16, 2013, 11:37 a.m. UTC | #4
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 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 Dec. 18, 2013, 6:29 p.m. UTC | #5
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 linux-wireless" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Sander Eikelenboom Dec. 18, 2013, 6:54 p.m. UTC | #6
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 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 Dec. 18, 2013, 6:54 p.m. UTC | #7
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 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 Dec. 18, 2013, 7:42 p.m. UTC | #8
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 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 mbox

Patch

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: