[Make-wifi-fast] [Cerowrt-devel] some comments from elsewhere on the lockdown

David P. Reed dpreed at reed.com
Fri Sep 25 21:08:46 EDT 2015

Sounds great to me

On Sep 25, 2015, Dave Taht <dave.taht at gmail.com> wrote:
>The core of the FCC letter is currently this. comments?
>snip snip
>In place of last year’s and the new proposed regulations, we propose a
>system of rules that would foster innovation, improve security, make
>Wi-Fi better, and overall improve usage of the Wi-Fi spectrum for
>1) Mandate that: for a SDR, wireless, or Wi-Fi radio of any sort - in
>order to achieve FCC compliance - full and maintained source code for
>at least the device driver and radio firmware be made publicly
>available in a source code repository on the internet, available for
>review and improvement by all.
>2) Mandate that: the vendor supply a continuous update stream, one
>that must respond to regulatory transgressions and CVEs within 45 days
>of disclosure, for the warranted lifetime of the product + 5 years
>after last customer ship.
>3) Mandate that: secure update of firmware be working at shipment, and
>that update streams be under ultimate control of the owner of the
>equipment. Problems with compliance can then be fixed going forward.
>4)  Failure to comply with these regulations will result in FCC
>decertification of the existing product and in severe cases, bar new
>products from that vendor from being considered for certification.
>5) In addition, we ask that the FCC review and rescind the rules for
>anything that conflicts with open source best practices, and/or which
>causes the vendors to believe they should hide the mechanisms they use
>by shipping undocumented “binary blobs” of compiled code.  This had
>been an ongoing problem to all in the internet community trying to do
>change control and error correction on safety-critical systems.
>On Fri, Sep 25, 2015 at 9:16 PM, David P. Reed <dpreed at reed.com> wrote:
>> Those of us who innovate at the waveform and MAC layer would argue
>> differently.  The cellular operators are actually the responsible
>> operators and hold licenses for that. They may want to lock down
>> cellular transmitters. But U-NII and ism bands are not licensed to
>> operators. There is no license requirement for those bands to use
>> waveforms or MAC layers.
>> So this is massive overreach. The control operator of the "licensed
>by rule"
>> Part 15 radios in your phone or home are licensed to the device user
>and not
>> to the mfr at all. For example, the user is responsible that the
>device not
>> interfere with licensed services, and that the device stop
>transmitting if
>> such harmful interference is called to their attention, *even* if the
>> passed certification.
>> Lock down has not been demonstrated to be necessary. This is all due
>> fearful what - if speculation by people who have no data to justify
>> need, plus attempt to stop innovation by licensees who want to
>> competitors from being created, like LTE operators proposing LTE-U
>> will be locked down and is the stalking horse for taking back open
>part 15
>> operation into a licensed regime based on property rights to
>> On Sep 24, 2015, Dave Taht <dave.taht at gmail.com> wrote:
>>> a commenter that I will keep anonymous wrote:
>>> Regarding the FCC firmware lockdown issue, I’m sure you’re aware
>>> baseband firmware in cellphones has been subject to similar
>>> restrictions for some time. In fact, the FCC effectively mandates
>>> baseband functionality is implemented on a whole separate subsystem
>>> with its own CPU to make it easier to isolate and protect. Also, the
>>> cellphone system is designed so that a misbehaving node can be
>>> identified and blocked from the network, making it useless and
>>> removing most of the incentive to find ways around regulatory
>>> restrictions. Wi-Fi devices have none of these protections.
>>> I believe this new attention to Wi-Fi devices is a consequence of
>>> factors:
>>> The precedent from cellphone baseband firmware control; regulators
>>> easily inspired by success stories in related areas
>>> The substantial increase in flexibility offered by SDR
>>> Technical ignorance, for example of the difference between OS,
>>> protocol, and UI firmware and baseband firmware
>>> The expansion of allowed capabilities in Wi-Fi hardware (from 5.8
>>> ISM to the U-NII bands, increases in transmit power allowances,
>>> The improved spectrum utilization of newer Wi-Fi modulation schemes
>>> Inconsistencies among international regulations for spectrum
>>> Spectrum sharing between Wi-Fi and life safety applications
>>> The relative lack of attention to (and sometimes, the deliberate
>>> flouting of) regulatory constraints in open-source firmware
>>> The increased availability of open-source firmware for higher-power
>>> and narrow-beam Wi-Fi devices (not just the WRT-54G :-)
>>> And probably more I can’t think of off the top of my head, but which
>>> regulators are obsessing over every day.
>>> Although I agree with the spirit of your FCC email draft letter, it
>>> does not address most of these factors, so it’s likely to be seen as
>>> missing the point by regulators. If you want to reach these people,
>>> you have to talk about the things they’re thinking about.
>>> What you ought to be pushing for instead is that Wi-Fi devices be
>>> partitioned the same way cellphones are, defining a baseband section
>>> that can be locked down so that the device can’t operate in ways
>>> are prohibited by the relevant local regulations, so that the OS,
>>> protocol, and UI code on the device can be relatively more open for
>>> the kinds of optimizations and improvements we all want to see.
>>> It’s possible that the partition could be in software alone, or in
>>> some combination of hardware and software, that doesn’t require a
>>> cellphone-style independent baseband processor, which would add a
>>> of cost to Wi-Fi devices. For example, the device vendor could put
>>> baseband-related firmware into a trusted and _truly minimal_ binary
>>> module that the OS has to go through to select the desired
>>> power, and modulation scheme, even for open-source solutions. That
>>> doesn’t mean the source code for the binary module can’t be
>>> or even that there can’t be a mandate to publish it.
>>> I’m sure that doesn’t sound like a great solution to you, but making
>>> it easy for end users to configure commercial devices to transmit at
>>> maximum power on unauthorized frequencies using very dense
>>> schemes doesn’t sound like a great solution to regulators, and the
>>> difference between you and the regulators is that they are more
>>> determined and, frankly, better armed. It will do you no good to
>>> constrain the range of the solutions you’ll accept so that it
>>> overlap with the solutions they will accept.
>>> .               png
>>> On Sep 21, 2015, at 5:10 AM, Dave Taht <dmt at millcomputing.com>
>>> Dave,
>>> Huh. I have been interested in mesh networking for a couple of years
>>> now, and curious about Battlemesh, but I had no idea I knew someone
>>> who was active in it.
>>> Are there any other reports online from this year or last year? The
>>> website doesn't seem to serve any purpose beyond announcing the
>>> As you can tell I am way, way behind on my email. I've mostly been
>>> chasihg funding for my main project, make-wifi-fast for over a year
>>> now - I added in the mill and the "cake switch chip" to that overall
>>> list as I tried to climb the financial ladders. My funding at google
>>> dried up suddenly (due to the re-org), and I was forced to chase
>>> avenues. I think i got a grant from comcast coming in, but it is for
>>> 1/10th the total I needed for make-wifi-fast... and it is hung up in
>>> legal, and in the fact the work has to mostly happen in europe.
>>> So I've moved to europe, trying to find bases in bristol, england,
>>> berlin, and sweden. That's taken a while (I dropped out of the mill
>>> process in may or so due to the sudden google silences, and the lack
>>> of compiler - and I view mill's biggest problem is funding, so it
>>> seems like just combining my own quest with yours the right thing)
>>> I was very involved in the early days of wireless networking but
>>> dropped out by 2002 or so, much to my now, later regret. The only
>>> left that understand it at more than one level all go to battlemesh,
>>> so I've been there twice. I still find it quite discouraging how few
>>> grok the minstrel algorithm, or what is wrong with packet
>>> A billion+ users that all think wifi "just works", and "always
>>> sucked"... :( I gave a talk on the latter as well at at this
>>> battlemesh.
>>> anyway the videos and results from this battlemesh are all now
>>> I am pushing on all fronts, but being a manager was a bit wearying
>>> I took time out to do some recording at a place called
>>> for the past 2 weeks. Haven't played the piano so much in 5 years!
>>> Youtube videos:
>>> https://www.youtube.com/channel/UCxfh-2aOR5hZUjxJLQ2CIHw
>>> blog post:
>>> The test results were dismal, as expected. Finally knocking a few
>>> heads to use abusive network tests like what toke and I developed
>>> hopefully an eye-opener, and a lot more people grok what
>>> make-wifi-fast is really about, and how to do it.
>>> http://docs.battlemesh.org/
>>> one very positive outcome of the fcc talk was a level of net outrage
>>> and organisation over some new fcc rules I have not seen before. My
>>> letter to the fcc, in progress, with vint cerf and other
>>> co-signers is up for review at:
>>> A similar letter has to go to the eu, as they just passed similar
>>> as much as I would like to be working on the mill, it seems
>>> finance, and organisation are in more need of my attentions right
>>> but I will keep plugging y'all at every opportunity.
>>> But, but... as I said, I just took a few weeks off and am picking up
>>> the pieces and trying to figure out what to focus on, at the moment.
>>> If you wish a faster response to my email, please use
>dave.taht at gmail.com
>> -- Sent with K-@ Mail - the evolution of emailing.

-- Sent with K-@ Mail - the evolution of emailing.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/make-wifi-fast/attachments/20150925/7e0bdd1b/attachment-0002.html>

More information about the Make-wifi-fast mailing list