| Message ID | 20170323133048.30062-2-sw@simonwunderlich.de (mailing list archive) |
|---|---|
| State | Rejected |
| Delegated to: | Kalle Valo |
| Headers | show |
Simon Wunderlich <sw@simonwunderlich.de> wrote: > From: Ben Greear <greearb@candelatech.com> > > 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 <greearb@candelatech.com> > [Hide this support behind a Kconfig option] > Signed-off-by: Julian Calaby <julian.calaby@gmail.com> > [only use the 20 mhz channels, add 5 ghz, change to 4.9ghz to licensed bands, simplify] > Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de> > Signed-off-by: Mathias Kretschmer <mathias.kretschmer@fit.fraunhofer.de> 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.
Hi, On Tuesday, April 18, 2017 2:36:54 PM CEST Kalle Valo wrote: > Simon Wunderlich <sw@simonwunderlich.de> wrote: > > From: Ben Greear <greearb@candelatech.com> > > > > 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 <greearb@candelatech.com> > > [Hide this support behind a Kconfig option] > > Signed-off-by: Julian Calaby <julian.calaby@gmail.com> > > [only use the 20 mhz channels, add 5 ghz, change to 4.9ghz to licensed > > bands, simplify] Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de> > > Signed-off-by: Mathias Kretschmer <mathias.kretschmer@fit.fraunhofer.de> > > 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 <sw@simonwunderlich.de> wrote: > > Hi, > > On Tuesday, April 18, 2017 2:36:54 PM CEST Kalle Valo wrote: > > Simon Wunderlich <sw@simonwunderlich.de> wrote: > > > From: Ben Greear <greearb@candelatech.com> > > > > > > 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.
On 04/18/2017 09:33 AM, Steve deRosier wrote: > Hi, > > On Tue, Apr 18, 2017 at 7:50 AM, Simon Wunderlich <sw@simonwunderlich.de <mailto:sw@simonwunderlich.de>> wrote: > > Hi, > > On Tuesday, April 18, 2017 2:36:54 PM CEST Kalle Valo wrote: > > Simon Wunderlich <sw@simonwunderlich.de <mailto:sw@simonwunderlich.de>> wrote: > > > From: Ben Greear <greearb@candelatech.com <mailto:greearb@candelatech.com>> > > > > > > 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. These patches make it slightly easier to use the licensed bands, but no one can accidentally use them due to the regdb and other constaints in these patches. So, I don't think these patches offer any fundamental new vulnerability that should concern the FCC. After all, someone who really wants to do evil can find and apply the patches without undue effort, and it could easily be that those applying the patches would then make it even easier to abuse the new channels due to laziness or poor coding choices. Thanks, Ben
Hi, On Tuesday, April 18, 2017 10:09:59 AM CEST Ben Greear wrote: > [...] > > 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. > These patches make it slightly easier to use the licensed bands, but no one > can accidentally use them due to the regdb and other constaints in these > patches. > > So, I don't think these patches offer any fundamental new vulnerability > that should concern the FCC. > > After all, someone who really wants to do evil can find and apply the > patches without undue effort, and it could easily be that those applying > the patches would then make it even easier to abuse the new channels due to > laziness or poor coding choices. I'm with Ben on this one. I also have followed the FCC actions in the past few years, and I've also been involved into that [1,2,3]. There are mailing lists on the topic if you want to get involved. I agree that the topic is important, but I would prefer to not have this patch serving as battleground. :) The patches proposed here, as Ben says, at least put proper warnings and obstacles which users have to knowingly overcome (or read). It's probably safer than keeping the driver as is and having people apply random patches from the internet which they don't understand or hack the code themselves. Frankly, it's not that hard to enable those channels. As we have seen by the number of questions and people trying to bring this patch in (Ben and Julian), there is quite some interest for supporting those bands. I've also got a few requests from companies to have it supported (Fraunhofer is one of those). Cheers, Simon [1] https://www.reddit.com/r/wireless/comments/3irr5b/ openwrt_vs_fcc_forced_firmware_lockdown/ [2] http://hackaday.com/2016/02/26/fcc-locks-down-router-firmware/ [3] https://libreplanet.org/wiki/Save_WiFi
Hi all, as one of the parties who triggered this patch to be included into the main line kernel, we do support Simon's or Ben's point of view. Safeguards against accidental misuse are in place. Various patches are (have been) already in the open, so if someone wants to be evil, it can't be prevented. Also, these patches do not make up new channels out of the blue, they merely enable channels which are allowed in certain countries under specific regulations. To me it seems to be the task of the distribution manager (or manufacturer) to ensure that only hardware/kernel features are made available that are legal in the given jurisdiction. The default behavior is to disable those extra channels. If you are building, i.e. First Responder solutions, you need to ensure that those guys use the systems incl. the frequency spectrum accordingly. To be pragmatic and to avoid out-of-tree code maintenance, my vote would be for integration into mainline. Best regards, Mathias Hence, for On 21-Apr-17 13:29, Simon Wunderlich wrote: > Hi, > > On Tuesday, April 18, 2017 10:09:59 AM CEST Ben Greear wrote: >> [...] >>> 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. >> These patches make it slightly easier to use the licensed bands, but no one >> can accidentally use them due to the regdb and other constaints in these >> patches. >> >> So, I don't think these patches offer any fundamental new vulnerability >> that should concern the FCC. >> >> After all, someone who really wants to do evil can find and apply the >> patches without undue effort, and it could easily be that those applying >> the patches would then make it even easier to abuse the new channels due to >> laziness or poor coding choices. > > I'm with Ben on this one. I also have followed the FCC actions in the past few > years, and I've also been involved into that [1,2,3]. There are mailing lists > on the topic if you want to get involved. I agree that the topic is important, > but I would prefer to not have this patch serving as battleground. :) > > The patches proposed here, as Ben says, at least put proper warnings and > obstacles which users have to knowingly overcome (or read). It's probably > safer than keeping the driver as is and having people apply random patches > from the internet which they don't understand or hack the code themselves. > Frankly, it's not that hard to enable those channels. > > As we have seen by the number of questions and people trying to bring this > patch in (Ben and Julian), there is quite some interest for supporting those > bands. I've also got a few requests from companies to have it supported > (Fraunhofer is one of those). > > Cheers, > Simon > > > [1] https://www.reddit.com/r/wireless/comments/3irr5b/ > openwrt_vs_fcc_forced_firmware_lockdown/ > [2] http://hackaday.com/2016/02/26/fcc-locks-down-router-firmware/ > [3] https://libreplanet.org/wiki/Save_WiFi >
Hey Kalle,
it seems like there was some discussion here and I wouldn't expect too many
more opinions ... do you think we can have a decision based on what has been
discussed here?
I'd be happy to rebase the remaining patches if that is necessary.
Thank you!
Simon
On Friday, April 21, 2017 2:40:51 PM CEST Mathias Kretschmer wrote:
> Hi all,
>
> as one of the parties who triggered this patch to be included into the
> main line kernel, we do support Simon's or Ben's point of view.
>
> Safeguards against accidental misuse are in place. Various patches are
> (have been) already in the open, so if someone wants to be evil, it
> can't be prevented.
>
> Also, these patches do not make up new channels out of the blue, they
> merely enable channels which are allowed in certain countries under
> specific regulations. To me it seems to be the task of the distribution
> manager (or manufacturer) to ensure that only hardware/kernel features
> are made available that are legal in the given jurisdiction.
>
> The default behavior is to disable those extra channels. If you are
> building, i.e. First Responder solutions, you need to ensure that those
> guys use the systems incl. the frequency spectrum accordingly.
>
> To be pragmatic and to avoid out-of-tree code maintenance, my vote would
> be for integration into mainline.
>
> Best regards,
>
> Mathias
>
>
>
>
> Hence, for
>
> On 21-Apr-17 13:29, Simon Wunderlich wrote:
> > Hi,
> >
> > On Tuesday, April 18, 2017 10:09:59 AM CEST Ben Greear wrote:
> >> [...]
> >>
> >>> 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.
> >>
> >> These patches make it slightly easier to use the licensed bands, but no
> >> one
> >> can accidentally use them due to the regdb and other constaints in these
> >> patches.
> >>
> >> So, I don't think these patches offer any fundamental new vulnerability
> >> that should concern the FCC.
> >>
> >> After all, someone who really wants to do evil can find and apply the
> >> patches without undue effort, and it could easily be that those applying
> >> the patches would then make it even easier to abuse the new channels due
> >> to
> >> laziness or poor coding choices.
> >
> > I'm with Ben on this one. I also have followed the FCC actions in the past
> > few years, and I've also been involved into that [1,2,3]. There are
> > mailing lists on the topic if you want to get involved. I agree that the
> > topic is important, but I would prefer to not have this patch serving as
> > battleground. :)
> >
> > The patches proposed here, as Ben says, at least put proper warnings and
> > obstacles which users have to knowingly overcome (or read). It's probably
> > safer than keeping the driver as is and having people apply random patches
> > from the internet which they don't understand or hack the code themselves.
> > Frankly, it's not that hard to enable those channels.
> >
> > As we have seen by the number of questions and people trying to bring this
> > patch in (Ben and Julian), there is quite some interest for supporting
> > those bands. I've also got a few requests from companies to have it
> > supported (Fraunhofer is one of those).
> >
> > Cheers,
> >
> > Simon
> >
> > [1] https://www.reddit.com/r/wireless/comments/3irr5b/
> > openwrt_vs_fcc_forced_firmware_lockdown/
> > [2] http://hackaday.com/2016/02/26/fcc-locks-down-router-firmware/
> > [3] https://libreplanet.org/wiki/Save_WiFi
>
> _______________________________________________
> ath10k mailing list
> ath10k@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k
On 9 May 2017 at 05:57, Simon Wunderlich <sw@simonwunderlich.de> wrote: > Hey Kalle, > > it seems like there was some discussion here and I wouldn't expect too many > more opinions ... do you think we can have a decision based on what has been > discussed here? (Note: FreeBSD has had in-tree support for 4.9GHz and 900MHz bands since forever. I'm actually thinking of extending it to include 5.9 and other UHF bands to cover licenced hardware people are making but then leaving the support disabled unless you compile in very specific licenced bits. No, it doesn't work out of the box unless your NIC actually supports it in the calibration section.) (Note note: some of those channels have non-megahertz boundaries, which means ... yeah, hello inter-operability boundaries. Hilarious.) -adrian
On 05/10/2017 03:30 AM, Tom Psyborg wrote: > > > On 9 May 2017 at 19:50, Adrian Chadd <adrian@freebsd.org <mailto:adrian@freebsd.org>> wrote: > > > (Note note: some of those channels have non-megahertz boundaries, > which means ... yeah, hello inter-operability boundaries. Hilarious.) > > > > -adrian > > > > From what I can tell, it seems like as long as your both points are configured with identical settings, you can use any channel/frequency/bandwidth combination > that hardware supports. Possibly even 802.11ac at 2.4 GHz if we got more than 100MHz of bandwidth from 2.4 to 2.5 GHz. The solution i've made myself doesn't > include all available channels but can serve as an example: https://forum.openwrt.org/viewtopic.php?pid=353870#p353870 primary/sec HT channel option should also > be further extended. > > Cheers, Tom I've successfully used 802.11ac VHT-40 on 2.4Ghz band with ath10k...it just requires a few small changes in the mac80211 stack to allow it to be configured....just FYI. Thanks, Ben
Simon Wunderlich <sw@simonwunderlich.de> writes: > it seems like there was some discussion here and I wouldn't expect too many > more opinions ... do you think we can have a decision based on what has been > discussed here? Well, there was an excellent reply from Steve and quite a few "in my opinion this is safe" type of answers. [1] But bluntly said it does not really matter what we (the engineers) think. What really matters here are regulatory authorities' opinions and rulings. In that respect here are few items I want to point out: o I suspect that from someone's, who is not familiar with software engineering, point of view there is still quite a diffference from modifiying source code or just enabling few options from Kconfig with a custom regdb rule. o I don't know about other countries, but in Finland applying for any type of license (even if just to a license to drive a moped) needs both time and money. So there is significant effort anyway needed to legally use this band. And how many users there really are is unclear. o Also this is not about enabling or disabling channel 13, but about a public _safety_ band which makes me very uneasy. So the way I see this is that the risks outweigh the benefits and that's why I do not want to take these. Sorry. [1] https://patchwork.kernel.org/patch/9641105/
On 05/11/2017 04:38 AM, Kalle Valo wrote: > Simon Wunderlich <sw@simonwunderlich.de> writes: > >> it seems like there was some discussion here and I wouldn't expect too many >> more opinions ... do you think we can have a decision based on what has been >> discussed here? > > Well, there was an excellent reply from Steve and quite a few "in my > opinion this is safe" type of answers. [1] But bluntly said it does not > really matter what we (the engineers) think. What really matters here > are regulatory authorities' opinions and rulings. In that respect here > are few items I want to point out: > > o I suspect that from someone's, who is not familiar with software > engineering, point of view there is still quite a diffference from > modifiying source code or just enabling few options from Kconfig with > a custom regdb rule. If someone with real authority ever complains, then the code could be backed out again. Your opinion seems not much more informed than the rest of us discussing this. > > o I don't know about other countries, but in Finland applying for any > type of license (even if just to a license to drive a moped) needs > both time and money. So there is significant effort anyway needed to > legally use this band. And how many users there really are is unclear. This is almost certainly not going to be used by regular end-users. It is going to be used by public safety organizations who are buying equipment from companies using open-wrt, LEDE, or similar, or possibly small teams at public safety organizations doing the work themselves. Rather than having each of these vendors hack their own crap into their kernels or forcing the the organizations to use Cisco gear, we could work on it together. Anyway, if upstream is blocked, then maybe we could work on getting this into LEDE? Thanks, Ben
Hi Ben, On Fri, May 12, 2017 at 7:12 AM, Ben Greear <greearb@candelatech.com> wrote: > > > On 05/11/2017 04:38 AM, Kalle Valo wrote: >> >> Simon Wunderlich <sw@simonwunderlich.de> writes: >> >>> it seems like there was some discussion here and I wouldn't expect too >>> many >>> more opinions ... do you think we can have a decision based on what has >>> been >>> discussed here? >> >> >> Well, there was an excellent reply from Steve and quite a few "in my >> opinion this is safe" type of answers. [1] But bluntly said it does not >> really matter what we (the engineers) think. What really matters here >> are regulatory authorities' opinions and rulings. In that respect here >> are few items I want to point out: >> >> o I suspect that from someone's, who is not familiar with software >> engineering, point of view there is still quite a diffference from >> modifiying source code or just enabling few options from Kconfig with >> a custom regdb rule. > > > If someone with real authority ever complains, then the code could be > backed out again. Your opinion seems not much more informed than the > rest of us discussing this. > With all due respect, _I_ am quite well informed about this issue. From my conversations with him, I'd also judge Kalle to be quite informed likewise. "Someone with real authority" has already complained. That's the entire point here. For the past two+ years it's been difficult to get modular approvals through the FCC and their TCBs. The standard they are applying is both pointless and technically misinformed, but they've got the authority and they're using it. I can't speak for any other manufacturers other than what I specifically have experience with, but I expect the rest are having similar conversations with the TCBs. From my work with them, I know that the chip manufacturers like QCA, Marvell and Cypress/Broadcom are also having similar issues. However, the chip manufacturers, and end-user equipment manufacturers are less vulnerable here than the module manufacturers. >> >> o I don't know about other countries, but in Finland applying for any >> type of license (even if just to a license to drive a moped) needs >> both time and money. So there is significant effort anyway needed to >> legally use this band. And how many users there really are is unclear. > > > This is almost certainly not going to be used by regular end-users. It is > going to be > used by public safety organizations who are buying equipment from companies > using open-wrt, LEDE, or similar, or possibly small teams at public safety > organizations doing the work themselves. Rather than having each of these > vendors I agree 100% that this won't be used by "regular end-users", if you define those users as the 99% of the population who will go to Best Buy and buy a router, plug it into their network and use it to get their iOS updates and download movies from Netflix. These aren't the users that the FCC is worried about. They're concerned about the user who buys an OpenWRT compatible router, installs OpenWRT on it, builds a custom kernel. And that person happens to live in an area with congested WiFi bands, the person notices an option to use these other non-congested bands, decides that ignoring the warning would be harmless and the FCC won't ever know anyway. And then there's a fire or other event in the area, and the emergency workers can't communicate. At best case, the FCC investigates and slaps a $25,000 fine on the operator. At worst case, someone dies. I don't feel it's responsible as an engineer to hide behind "well, we warned them that they shouldn't do that" while ignoring my culpability in the matter. Setting the stage for others to fail due to their ignorance is not ethical. Anyone building a custom kernel is able to enable a config option. You can say that, "sure they can pull the patch from here and enable it anyway" or "they can figure it out and do it themselves, it's easy", but I do think there's a significant difference between being able to build a custom kernel with a configuration enabled vs being able to find and apply a random patch to a kernel and get it building and working. That's a different level of expertise. And going through that effort gives a person some time to reflect and think about if it should be done in the first place. Adding this code to mainline makes it a feature of Linux and this driver. There's no way around that argument. Saying that "this is almost certainly not going to be used by regular end-users" is both fairly true as well as disingenuous. You're still making it an accepted feature. > hack their own crap into their kernels or forcing the the organizations to > use Cisco gear, > we could work on it together. > I absolutely concur with the idea of "we could work on it together." Working together means coming up with a holistic plan that will work and satisfy the regulatory agencies (and I'm not just talking FCC, though they're right now one of the worst offenders IMHO). Just putting a patch to use licenced public-safety bands into a single random 802.11 chip driver to satisfy your particular project/product/itch is not the same as working together. In particular because this is _exactly_ the type of stuff that the FCC is actually concerned about and fighting against with their misinformed lock-down attitudes. What really needs to happen to solve these sort of issues is a whole-system approach where we work with the agencies and figure out a way that works for everyone. The lawmakers and the regulatory agencies as a group entity don't understand software, electronics, technology, nor Open Source. The whole idea of a bunch of us "hackers" able to do anything we want with just a few lines of code scares the hell out of them. We need to engage with them. Educate them. Work with the specific people inside their organizations that _do_ understand the technology. Let them understand we're not the enemy and then work with them to achieve both their goals and ours. I tried to get the ball rolling on this at the Wireless Summit at the last LPC, but no one bit. Probably some due to the lack of clarity around the issue as well as my lack of eloquence, but no matter why, it didn't go anywhere. I'm happy to try again if people are interested. This isn't just about letting it operate out of spec, nor a technical argument. I don't have any issue with making it easier to enable a feature of the chipset. That's all good. But "making it easier" in this case equates to making it harder for the entire community who depends on this stuff to get their work done and their products certified. That's a net negative. > Anyway, if upstream is blocked, then maybe we could work on getting this > into LEDE? > Honestly, I don't see how this solves any problems. You're just moving the chair. A chair that someone will stand on and fall off and get hurt. LEDE, OpenWRT or even Buildroot is essentially just a big patch and build system. For a closed-ecosystem manufacturer, which by definition a public-safety band licensed equipment manufacturer must be, can just as easily maintain their own internal fork of the kernel with these patches sitting there. That's not something I'd normally advocate, but it does seem appropriate in this specific application. Thanks, - Steve
On 05/12/2017 12:21 PM, Steve deRosier wrote: > Hi Ben, > > On Fri, May 12, 2017 at 7:12 AM, Ben Greear <greearb@candelatech.com> wrote: >> >> >> On 05/11/2017 04:38 AM, Kalle Valo wrote: >>> >>> Simon Wunderlich <sw@simonwunderlich.de> writes: >>> >>>> it seems like there was some discussion here and I wouldn't expect too >>>> many >>>> more opinions ... do you think we can have a decision based on what has >>>> been >>>> discussed here? >>> >>> >>> Well, there was an excellent reply from Steve and quite a few "in my >>> opinion this is safe" type of answers. [1] But bluntly said it does not >>> really matter what we (the engineers) think. What really matters here >>> are regulatory authorities' opinions and rulings. In that respect here >>> are few items I want to point out: >>> >>> o I suspect that from someone's, who is not familiar with software >>> engineering, point of view there is still quite a diffference from >>> modifiying source code or just enabling few options from Kconfig with >>> a custom regdb rule. >> >> >> If someone with real authority ever complains, then the code could be >> backed out again. Your opinion seems not much more informed than the >> rest of us discussing this. >> > > With all due respect, _I_ am quite well informed about this issue. > From my conversations with him, I'd also judge Kalle to be quite > informed likewise. >> Anyway, if upstream is blocked, then maybe we could work on getting this >> into LEDE? >> > > Honestly, I don't see how this solves any problems. You're just moving > the chair. A chair that someone will stand on and fall off and get > hurt. LEDE, OpenWRT or even Buildroot is essentially just a big patch > and build system. For a closed-ecosystem manufacturer, which by > definition a public-safety band licensed equipment manufacturer must > be, can just as easily maintain their own internal fork of the kernel > with these patches sitting there. > > That's not something I'd normally advocate, but it does seem > appropriate in this specific application. Maintaining outside patches means work for everyone..but if there is a single set of outside patches, then at least it is easier. That is what LEDE might be able to offer. As for keeping lame users from causing trouble, maybe we can merge much of the code that often conflicts with upstream code but leave out a few key patches to actually enable the feature. Then no one can just re-build with a different kernel option (after hacking their regdb) and get it to work. All that said, I doubt this will matter at all to FCC because if LEDE can boot on a device, it can already be put out of spec without much trouble. Making it take 2 days of effort vs 1 hour surely doesn't make a difference? Thanks, Ben
On 12-5-2017 21:21, Steve deRosier wrote: > Hi Ben, > > On Fri, May 12, 2017 at 7:12 AM, Ben Greear <greearb@candelatech.com> wrote: >> >> >> On 05/11/2017 04:38 AM, Kalle Valo wrote: >>> [snip] >>> o I don't know about other countries, but in Finland applying for any >>> type of license (even if just to a license to drive a moped) needs >>> both time and money. So there is significant effort anyway needed to >>> legally use this band. And how many users there really are is unclear. >> >> >> This is almost certainly not going to be used by regular end-users. It is >> going to be >> used by public safety organizations who are buying equipment from companies >> using open-wrt, LEDE, or similar, or possibly small teams at public safety >> organizations doing the work themselves. Rather than having each of these >> vendors > > I agree 100% that this won't be used by "regular end-users", if you > define those users as the 99% of the population who will go to Best > Buy and buy a router, plug it into their network and use it to get > their iOS updates and download movies from Netflix. These aren't the > users that the FCC is worried about. They're concerned about the user > who buys an OpenWRT compatible router, installs OpenWRT on it, builds > a custom kernel. And that person happens to live in an area with > congested WiFi bands, the person notices an option to use these other > non-congested bands, decides that ignoring the warning would be > harmless and the FCC won't ever know anyway. > > And then there's a fire or other event in the area, and the emergency > workers can't communicate. At best case, the FCC investigates and > slaps a $25,000 fine on the operator. At worst case, someone dies. > > I don't feel it's responsible as an engineer to hide behind "well, we > warned them that they shouldn't do that" while ignoring my culpability > in the matter. Setting the stage for others to fail due to their > ignorance is not ethical. Totally agree this is about being responsible. > Anyone building a custom kernel is able to enable a config option. You > can say that, "sure they can pull the patch from here and enable it > anyway" or "they can figure it out and do it themselves, it's easy", > but I do think there's a significant difference between being able to > build a custom kernel with a configuration enabled vs being able to > find and apply a random patch to a kernel and get it building and > working. That's a different level of expertise. And going through that > effort gives a person some time to reflect and think about if it > should be done in the first place. > > Adding this code to mainline makes it a feature of Linux and this > driver. There's no way around that argument. Saying that "this is > almost certainly not going to be used by regular end-users" is both > fairly true as well as disingenuous. You're still making it an > accepted feature. Indeed. I had my concerns back when the CFG80211_CERTIFICATION_ONUS was added to the kernel, but that is water under the bridge. It is not only these kind of changes the FCC is looking at. They also have issues with 802.11d support. That does not even need a custom kernel. The end-user just sets the country to some nice EU channel while being in the US and screw up some weather radar. It has happened. Not life-threatening, unless some tornado was missed maybe, but the concern is justified. How the FCC is handling it may indeed be pointless and technically misinformed, but that is because there is no good solution right now. At least not a solution that assures it will not happen. I can only agree that we as a community should not accommodate such (ab)use. Finding a solution that is working for everyone is indeed the real challenge. Regards, Arend
diff --git a/drivers/net/wireless/ath/ath9k/Kconfig b/drivers/net/wireless/ath/ath9k/Kconfig index 783a38f1a626..23b8abf4449a 100644 --- a/drivers/net/wireless/ath/ath9k/Kconfig +++ b/drivers/net/wireless/ath/ath9k/Kconfig @@ -116,6 +116,26 @@ config ATH9K_DFS_CERTIFIED developed. At this point enabling this option won't do anything except increase code size. +config ATH9K_LICENSED_CHAN + bool "Support channels in licensed bands" + depends on ATH9K && CFG80211_CERTIFICATION_ONUS + default n + ---help--- + This option enables support for licensed channels on such as + 4.9 GHz (public safety). + + These are PUBLIC SAFETY CHANNELS and MUST NOT BE USED in most + regulatory domains UNLESS YOU HAVE A FULL LICENSE for their use from + your local radio regulator, e.g. the FCC or equivalent. Using these + channels without proper authorisation may result in serious legal + consequences. + + You will also have to build a regulatory database with these channels + enabled to actually use them. + + If you are a distro kernel builder or have any doubt whatsoever about + your legal ability to use these channels, say N. + config ATH9K_DYNACK bool "Atheros ath9k ACK timeout estimation algorithm (EXPERIMENTAL)" depends on ATH9K diff --git a/drivers/net/wireless/ath/ath9k/common-init.c b/drivers/net/wireless/ath/ath9k/common-init.c index 8b4f7fdabf58..3d65dce13048 100644 --- a/drivers/net/wireless/ath/ath9k/common-init.c +++ b/drivers/net/wireless/ath/ath9k/common-init.c @@ -86,6 +86,21 @@ static const struct ieee80211_channel ath9k_5ghz_chantable[] = { CHAN5G(5785, 35), /* Channel 157 */ CHAN5G(5805, 36), /* Channel 161 */ CHAN5G(5825, 37), /* Channel 165 */ + +#ifdef CONFIG_ATH9K_LICENSED_CHAN + /* 4.9Ghz channels, public safety channels, license is required in US + * and most other regulatory domains! + */ + /* 802.11j 4.9 GHz (20 MHz) */ + CHAN5G(4920, 38), /* channel 184 */ + CHAN5G(4940, 39), /* channel 188 */ + CHAN5G(4960, 40), /* channel 192 */ + CHAN5G(4980, 41), /* channel 196 */ + /* 802.11j 5.030 - 5.080 GHz (20 MHz) */ + CHAN5G(5040, 42), /* channel 8 */ + CHAN5G(5060, 43), /* channel 12 */ + CHAN5G(5080, 44), /* channel 16 */ +#endif }; /* Atheros hardware rate code addition for short premble */ diff --git a/drivers/net/wireless/ath/ath9k/hw.h b/drivers/net/wireless/ath/ath9k/hw.h index 9cbca1229bac..2166f644599d 100644 --- a/drivers/net/wireless/ath/ath9k/hw.h +++ b/drivers/net/wireless/ath/ath9k/hw.h @@ -73,7 +73,11 @@ #define ATH9K_RSSI_BAD -128 +#ifdef CONFIG_ATH9K_LICENSED_CHAN +#define ATH9K_NUM_CHANNELS 45 +#else #define ATH9K_NUM_CHANNELS 38 +#endif /* Register read/write primitives */ #define REG_WRITE(_ah, _reg, _val) \