[v2,1/3] ath9k: Support channels in licensed bands

[Steve deRosier]

Hi Ben,

On Fri, May 12, 2017 at 7:12 AM, Ben Greear <greearb at candelatech.com> wrote:
>
>
> On 05/11/2017 04:38 AM, Kalle Valo wrote:
>>
>> Simon Wunderlich <sw at 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