From: Jonathan Morton <chromatix99@gmail.com>
To: dpreed@reed.com
Cc: David Lang <david@lang.hm>,
make-wifi-fast@lists.bufferbloat.net,
bufferbloat-fcc-discuss
<bufferbloat-fcc-discuss@lists.redbarn.org>,
cerowrt-devel@lists.bufferbloat.net
Subject: Re: [Make-wifi-fast] [Cerowrt-devel] [bufferbloat-fcc-discuss] arstechnica confirmstp-link router lockdown
Date: Mon, 14 Mar 2016 16:14:58 +0200 [thread overview]
Message-ID: <7E8F9D99-38F8-47CD-960E-45100844B161@gmail.com> (raw)
In-Reply-To: <1457964158.79616218@mobile.rackspace.com>
> On 14 Mar, 2016, at 16:02, dpreed@reed.com wrote:
>
> The WiFi protocols themselves are not a worry of the FCC at all. Modifying them in software is ok. Just the physical emissions spectrum must be certified not to be exceeded.
>
> So as a practical matter, one could even satisfy this rule with an external filter and power limiter alone, except in part of the 5 GHz band where radios must turn off if a radar is detected by a specified algorithm.
>
> That means that the radio software itself could be tasked with a software filter in the D/A converter that is burned into the chip, and not bypassable. If the update path requires a key that is secret, that should be enough, as key based updating is fine for all radios sold for other uses that use digital modulation using DSP.
>
> So the problem is that 802.11 chips don't split out the two functions, making one hard to update.
To put this another way, what we need is a cleaner separation of ISO Layers 1 (physical) and 2 (MAC).
The FCC is concerned about locking down Layer 1 for RF compliance. We’re concerned with keeping Layer 2 (and upwards) open for experimentation and improvement.
These are compatible goals, at the fundamental level, but there is a practical problem with existing implementations which mix the layers inappropriately.
- Jonathan Morton
next prev parent reply other threads:[~2016-03-14 14:15 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-14 14:02 dpreed
2016-03-14 14:14 ` Jonathan Morton [this message]
[not found] ` <CAEfCu-oCfO+FfdLjpZDSwQmZ7-Mc+X4vDvzZMNrnp+p8ut8OKQ@mail.gmail.com>
2016-03-14 16:23 ` [Make-wifi-fast] [bufferbloat-fcc-discuss] [Cerowrt-devel] " Adrian Chadd
2016-03-14 17:49 ` dpreed
2016-03-14 19:04 ` David Lang
2016-03-14 19:07 ` [Make-wifi-fast] [Cerowrt-devel] [bufferbloat-fcc-discuss] " David Lang
2016-03-14 19:13 ` David Lang
[not found] ` <CAEfCu-pGdkcqHJMHSiXtXBcx=m0XyskVOLmGjC2esS+SY+GgcQ@mail.gmail.com>
2016-03-14 22:29 ` [Make-wifi-fast] [bufferbloat-fcc-discuss] [Cerowrt-devel] " David Lang
2016-03-15 3:47 [Make-wifi-fast] [bufferbloat-fcc-discuss] [Cerowrt-devel]arstechnica " dpreed
2016-03-15 9:38 ` [Make-wifi-fast] [Cerowrt-devel] [bufferbloat-fcc-discuss] arstechnica " Jonathan Morton
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
List information: https://lists.bufferbloat.net/postorius/lists/make-wifi-fast.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7E8F9D99-38F8-47CD-960E-45100844B161@gmail.com \
--to=chromatix99@gmail.com \
--cc=bufferbloat-fcc-discuss@lists.redbarn.org \
--cc=cerowrt-devel@lists.bufferbloat.net \
--cc=david@lang.hm \
--cc=dpreed@reed.com \
--cc=make-wifi-fast@lists.bufferbloat.net \
/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