On 04/18/2017 09:33 AM, Steve deRosier wrote:
> Hi,
>
> On Tue, Apr 18, 2017 at 7:50 AM, Simon Wunderlich <[email protected] <mailto:[email protected]>> wrote:
>
> Hi,
>
> On Tuesday, April 18, 2017 2:36:54 PM CEST Kalle Valo wrote:
> > Simon Wunderlich <[email protected] <mailto:[email protected]>> wrote:
> > > From: Ben Greear <[email protected] <mailto:[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.
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
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com
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
>
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
On 12-5-2017 21:21, Steve deRosier wrote:
> Hi Ben,
>
> On Fri, May 12, 2017 at 7:12 AM, Ben Greear <[email protected]> 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
On 05/11/2017 04:38 AM, Kalle Valo wrote:
> Simon Wunderlich <[email protected]> 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
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com
Hi Ben,
On Fri, May 12, 2017 at 7:12 AM, Ben Greear <[email protected]> wrote:
>
>
> On 05/11/2017 04:38 AM, Kalle Valo wrote:
>>
>> Simon Wunderlich <[email protected]> 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
Simon Wunderlich <[email protected]> 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/
--
Kalle Valo
On 05/12/2017 12:21 PM, Steve deRosier wrote:
> Hi Ben,
>
> On Fri, May 12, 2017 at 7:12 AM, Ben Greear <[email protected]> wrote:
>>
>>
>> On 05/11/2017 04:38 AM, Kalle Valo wrote:
>>>
>>> Simon Wunderlich <[email protected]> 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
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com
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
> [email protected]
> http://lists.infradead.org/mailman/listinfo/ath10k
On 9 May 2017 at 05:57, Simon Wunderlich <[email protected]> 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