linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Simon Wunderlich <sw@simonwunderlich.de>
To: Kalle Valo <kvalo@codeaurora.org>
Cc: ath10k@lists.infradead.org,
	Mathias Kretschmer <mathias.kretschmer@fit.fraunhofer.de>,
	Julian Calaby <julian.calaby@gmail.com>,
	linux-wireless@vger.kernel.org, ath9k-devel@qca.qualcomm.com,
	Steve deRosier <derosier@gmail.com>,
	Ben Greear <greearb@candelatech.com>
Subject: Re: [v2,1/3] ath9k: Support channels in licensed bands
Date: Tue, 09 May 2017 14:57:32 +0200	[thread overview]
Message-ID: <1863250.VEhGCjvYY0@prime> (raw)
In-Reply-To: <12133a0e-b030-5b21-8de1-3bf7334d47df@fit.fraunhofer.de>

[-- Attachment #1: Type: text/plain, Size: 3980 bytes --]

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


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2017-05-09 12:57 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-23 13:30 [PATCH v2 0/3] Channels in licensed bands, noise floor override Simon Wunderlich
2017-03-23 13:30 ` [PATCH v2 1/3] ath9k: Support channels in licensed bands Simon Wunderlich
2017-04-18 14:36   ` [v2,1/3] " Kalle Valo
     [not found]   ` <20170418143654.8AC0A60FAA@smtp.codeaurora.org>
2017-04-18 14:50     ` Simon Wunderlich
2017-04-18 16:38       ` Steve deRosier
     [not found]       ` <CALLGbRK2d1wZpfLnXu_UDWxVPA9LvejFyEFpzMub56uLH0+DTw@mail.gmail.com>
2017-04-18 17:09         ` Ben Greear
2017-04-21 11:29           ` Simon Wunderlich
2017-04-21 12:40             ` Mathias Kretschmer
2017-05-09 12:57               ` Simon Wunderlich [this message]
2017-05-09 17:50                 ` Adrian Chadd
     [not found]                   ` <CAKR_QV+0cPXbiScO3cS52R97o=wGh4+zgmqaRM7QbotmEJD51Q@mail.gmail.com>
2017-05-10 16:17                     ` Ben Greear
2017-05-11 11:38                 ` Kalle Valo
2017-05-12 14:12                   ` Ben Greear
2017-05-12 19:21                     ` Steve deRosier
2017-05-12 19:44                       ` Ben Greear
2017-05-13 12:12                       ` Arend Van Spriel
2017-03-23 13:30 ` [PATCH v2 2/3] ath10k: add support for " Simon Wunderlich
2017-03-23 13:30 ` [PATCH v2 3/3] ath9k: add noise floor override option Simon Wunderlich
2017-04-19 14:08   ` [v2,3/3] " Kalle Valo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1863250.VEhGCjvYY0@prime \
    --to=sw@simonwunderlich.de \
    --cc=ath10k@lists.infradead.org \
    --cc=ath9k-devel@qca.qualcomm.com \
    --cc=derosier@gmail.com \
    --cc=greearb@candelatech.com \
    --cc=julian.calaby@gmail.com \
    --cc=kvalo@codeaurora.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=mathias.kretschmer@fit.fraunhofer.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).