Hi,
On Tuesday, April 18, 2017 2:36:54 PM CEST Kalle Valo wrote:
> Simon Wunderlich <[email protected]> wrote:
> > From: Ben Greear <[email protected]>
> >
> > Many chips support channels in licensed bands. Add support for those,
> > along with a corresponding kernel config option to disable them by
> > default. Note that these channels are not selectable even if the
> > option has been compiled unless the user modifies the regulatory
> > database to explicitly enable the corresponding channels.
> >
> > NOTE: These channels must not be used in most regulatory
> > domains unless you have a license from the FCC or similar!
> >
> > Signed-off-by: Ben Greear <[email protected]>
> > [Hide this support behind a Kconfig option]
> > Signed-off-by: Julian Calaby <[email protected]>
> > [only use the 20 mhz channels, add 5 ghz, change to 4.9ghz to licensed
> > bands, simplify] Signed-off-by: Simon Wunderlich <[email protected]>
> > Signed-off-by: Mathias Kretschmer <[email protected]>
>
> I am not sure that we should support unlicensed bands in Linux and hence
> hesitant to apply these. My view is that due to regulatory restrictions we
> should not make it too easy to use unlicensed bands. But I'm open for
> discussion, this is a challenging area and my knowledge here is limited.
thanks for your reply! I agree that we should not make it too easy, and
therefore there are the following "obstacles" which should avoid accidental
use of license bands:
* we have the kernel CONFIG option which features a big fat warning
* regulatory database must be tampered with to enabel the channels. In
distributions, the regdb also gets signed. There is also the "internal regdb"
CONFIG option if you compile your own kernel (rarely used, except for
OpenWRT). In each case, a user must actively add the 4.9 GHz channels into it,
because they are not included in the default regdb (and this should not
change).
* CFG80211_CERTIFICATION_ONUS is also required, which also says "you are on
your own".
I had a comparison with ath5k, which also allows using those channels without
at least the special configuration option (there is one enabling even more
channels). The regdb "obstacle" is in place as well. However, ath5k is for
very old chips and therefore the threat is limited.
In my personal view, we have quite a few obstacles which I consider "enough",
but would be interesting to hear others opinions ...
Cheers,
Simon
Hi,
(sorry, resending due to my not noticing that gmail had changed my
default compose mode to HTML. Why does it randomly do that
sometimes?!?!)
On Tue, Apr 18, 2017 at 7:50 AM, Simon Wunderlich <[email protected]> wrote:
>
> Hi,
>
> On Tuesday, April 18, 2017 2:36:54 PM CEST Kalle Valo wrote:
> > Simon Wunderlich <[email protected]> wrote:
> > > From: Ben Greear <[email protected]>
> > >
> > > Many chips support channels in licensed bands. Add support for those,
> > > along with a corresponding kernel config option to disable them by
...
> > I am not sure that we should support unlicensed bands in Linux and hence
> > hesitant to apply these. My view is that due to regulatory restrictions we
> > should not make it too easy to use unlicensed bands. But I'm open for
> > discussion, this is a challenging area and my knowledge here is limited.
>
...
>
>
> In my personal view, we have quite a few obstacles which I consider "enough",
> but would be interesting to hear others opinions ...
>
I'll throw in my 2-cents. This patch is treading on very dangerous
ground. I can't speak to other regulatory environments, but at least
the FCC is cracking down on even the possibility that anyone can
operate a WiFi device outside the regulatory bounds.
I know this is going to be TLDR, but please bear with me.
The testing groups are (incorrectly in my opinion) interpreting the
current FCC guidelines to be that no one with the device could ever
get in and change it to operate outside the permitted frequencies and
powers. And I'm not even talking about having a command-line interface
and issuing a command as sudo. To the degree that if it's even
possible to recompile a driver or otherwise change the source code and
put that changed code on the device they're denying modular
certifications.
The end result is we have a lot of chip manufacturers' scrambling to
do things like require eeproms, signed board files, etc. Module
manufacturers (think of things like Laird's msd45nbt, msd50nbt, or the
Sterling LWB) are scrambling even harder trying to think of ways to
force chips to fail to function if they aren't using their regulatory
file or other strategies to manage to fulfill their customer's needs
while still getting it to pass through the regulatory agencies.
@Simon, with much respect: With the current regulatory environment,
those obstacles which you are considering "enough", the testing boards
aren't considering "enough".
I happen to agree with you that it's more than enough. And just
because it's possible for a customer of a module who is integrating a
device to operate it out of the regulatory bounds, doesn't mean it
shouldn't get the modular certification. In fact, depending on the
exact situations, it might be _necessary_ for them to make setting
adjustments for their products. And the reality is, anyone with a
soldering iron can make the thing operate outside the regulatory
domain anyway. The whole thing just makes it impossible for modular
operators and for the Linux community instead of solving any real
problems.
What's going on in the FCC regulatory environment has stark
implications that those of us in the Linux wireless community can't
afford to ignore anymore. This is a direct threat to mac80211, Open
Source and the ability to do anything sane with our devices. And even
if you're more practical (like me) about these things, think of it:
each manufacturer being forced to make it harder and harder for anyone
to change the code or work with their chips - you think it's hard to
work with a Marvell or Broadcom chip right now with minimal and
non-accessible documentation? Imagine how it's going to be when
everything is locked behind Secure Boot and signed proprietary drivers
where the hardware itself is locked so it can only work with the (bad
quality and buggy) closed-source driver.
I brought this up at Wireless Summit at the last LPC and basically got
a room of shrugs. Admittedly I wasn't terribly eloquent on the subject
so it's solely my fault I didn't impress. I know that most of us are
representing various companies (though not I anymore) and each has
their own proprietary way to deal with it and no one wants to rock the
boat*. And many of the people in the room are just implementing code
to make stuff work and don't actually know that much depth about the
regulatory environment in which we're working. But we all need to get
together and come up with a better solution.
What's going on right now doesn't serve our interests. I know it's an
agenda being pushed by someone and while I have a few suspects I
really don't know for sure. In any case, who it's being pushed by and
for doesn't matter too much - we as a community aren't pushing back as
a cohesive group; we aren't even talking about it! And so, we're going
to get the short end of the stick.
So, with re: to the patch, that's the environment it will live in.
Personally I don't really care one way or another specifically to what
Simon's patch does. But he opened the door to discussion and it seemed
like an appropriate opportunity. I don't mind that it opens more
functionality, functionality that the chip in question supports. I'd
even regard this as a good thing, especially considering the
"obstacles" in place. And keeping it out doesn't solve anything to do
with the root of the problem either.
As for merging it, I guess my only test would be: is this a
functionality that the community as a whole benefits from? Either
because more than one person would be using it, or we have a vested
interest in keeping a cohesive codebase that doesn't require people to
use it a crazy maintenance overhead by requiring patching every time
they upgrade? But that's always the same questions with any patch.
In either case, patch merged or not: we still have an important
discussion to have about what we're going to do about the FCC
regulatory problems - before someone "solves" it for us in a way that
hurts us all.
If you got this far, thanks for reading this.
Thanks,
- Steve
footnote:
* Personally, I think that many of the devices in the past and
currently are getting certifications by clever wording on the
documents and getting through on a wink and a nod. And no one wants to
talk about it because that means acknowledging that fact and risking
newer devices having a more difficult time getting through.