All of lore.kernel.org
 help / color / mirror / Atom feed
From: Simon Wunderlich <sw@simonwunderlich.de>
To: Kalle Valo <kvalo@codeaurora.org>
Cc: Julian Calaby <julian.calaby@gmail.com>,
	linux-wireless@vger.kernel.org, ath9k-devel@qca.qualcomm.com,
	ath10k@lists.infradead.org, Steve deRosier <derosier@gmail.com>,
	Ben Greear <greearb@candelatech.com>,
	Mathias Kretschmer <mathias.kretschmer@fit.fraunhofer.de>
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.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 #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 146 bytes --]

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

WARNING: multiple messages have this Message-ID (diff)
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:58 UTC|newest]

Thread overview: 38+ 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 ` Simon Wunderlich
2017-03-23 13:30 ` [PATCH v2 1/3] ath9k: Support channels in licensed bands Simon Wunderlich
2017-03-23 13:30   ` Simon Wunderlich
2017-04-18 14:36   ` [v2,1/3] " Kalle Valo
2017-04-18 14:36   ` Kalle Valo
     [not found]   ` <20170418143654.8AC0A60FAA@smtp.codeaurora.org>
2017-04-18 14:50     ` Simon Wunderlich
2017-04-18 14:50       ` Simon Wunderlich
2017-04-18 16:38       ` Steve deRosier
2017-04-18 16:38         ` Steve deRosier
     [not found]       ` <CALLGbRK2d1wZpfLnXu_UDWxVPA9LvejFyEFpzMub56uLH0+DTw@mail.gmail.com>
2017-04-18 17:09         ` Ben Greear
2017-04-18 17:09           ` Ben Greear
2017-04-21 11:29           ` Simon Wunderlich
2017-04-21 11:29             ` Simon Wunderlich
2017-04-21 12:40             ` Mathias Kretschmer
2017-04-21 12:40               ` Mathias Kretschmer
2017-05-09 12:57               ` Simon Wunderlich [this message]
2017-05-09 12:57                 ` Simon Wunderlich
2017-05-09 17:50                 ` Adrian Chadd
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-10 16:17                       ` Ben Greear
2017-05-11 11:38                 ` Kalle Valo
2017-05-11 11:38                   ` Kalle Valo
2017-05-12 14:12                   ` Ben Greear
2017-05-12 14:12                     ` Ben Greear
2017-05-12 19:21                     ` Steve deRosier
2017-05-12 19:21                       ` Steve deRosier
2017-05-12 19:44                       ` Ben Greear
2017-05-12 19:44                         ` Ben Greear
2017-05-13 12:12                       ` Arend Van Spriel
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   ` Simon Wunderlich
2017-03-23 13:30 ` [PATCH v2 3/3] ath9k: add noise floor override option Simon Wunderlich
2017-03-23 13:30   ` Simon Wunderlich
2017-04-19 14:08   ` [v2,3/3] " Kalle Valo
2017-04-19 14:08     ` 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.