All of lore.kernel.org
 help / color / mirror / Atom feed
From: Simon Wunderlich <sw@simonwunderlich.de>
To: ath10k@lists.infradead.org
Cc: Ben Greear <greearb@candelatech.com>,
	Steve deRosier <derosier@gmail.com>,
	Julian Calaby <julian.calaby@gmail.com>,
	linux-wireless@vger.kernel.org, ath9k-devel@qca.qualcomm.com,
	Mathias Kretschmer <mathias.kretschmer@fit.fraunhofer.de>,
	Kalle Valo <kvalo@codeaurora.org>
Subject: Re: [v2,1/3] ath9k: Support channels in licensed bands
Date: Fri, 21 Apr 2017 13:29:14 +0200	[thread overview]
Message-ID: <1811221.G4Vz0DPyQ8@prime> (raw)
In-Reply-To: <d4acedac-e28c-4c1c-d112-40557d52f3a2@candelatech.com>

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

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

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

WARNING: multiple messages have this Message-ID (diff)
From: Simon Wunderlich <sw@simonwunderlich.de>
To: ath10k@lists.infradead.org
Cc: 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>,
	Mathias Kretschmer <mathias.kretschmer@fit.fraunhofer.de>,
	Kalle Valo <kvalo@codeaurora.org>
Subject: Re: [v2,1/3] ath9k: Support channels in licensed bands
Date: Fri, 21 Apr 2017 13:29:14 +0200	[thread overview]
Message-ID: <1811221.G4Vz0DPyQ8@prime> (raw)
In-Reply-To: <d4acedac-e28c-4c1c-d112-40557d52f3a2@candelatech.com>


[-- Attachment #1.1: Type: text/plain, Size: 2230 bytes --]

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

[-- 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

  reply	other threads:[~2017-04-21 11:29 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 [this message]
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
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=1811221.G4Vz0DPyQ8@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.