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

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

[Dave Taht]

a commenter that I will keep anonymous wrote:


Regarding the FCC firmware lockdown issue, I’m sure you’re aware that
baseband firmware in cellphones has been subject to similar
restrictions for some time. In fact, the FCC effectively mandates that
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 easily
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 many factors:

The precedent from cellphone baseband firmware control; regulators are
easily inspired by success stories in related areas
The substantial increase in flexibility offered by SDR implementations
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 GHz
ISM to the U-NII bands, increases in transmit power allowances, etc.)
The improved spectrum utilization of newer Wi-Fi modulation schemes
Inconsistencies among international regulations for spectrum allocation
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 that
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 lot
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 frequency,
power, and modulation scheme, even for open-source solutions. That
doesn’t mean the source code for the binary module can’t be published,
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 modulation
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 doesn’t
overlap with the solutions they will accept.

.               png


On Sep 21, 2015, at 5:10 AM, Dave Taht <dmt@millcomputing.com> wrote:


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 event.



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 other
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 devs
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 aggregation.
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 online.
I am pushing on all fronts, but being a manager was a bit wearying so
I took time out to do some recording at a place called theconvent.net
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: https://wlan-si.net/en/blog/2015/09/08/battlemesh-v8-and-its-many-stories/

The test results were dismal, as expected. Finally knocking a few
heads to use abusive network tests like what toke and I developed were
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:

https://docs.google.com/document/d/1VTOHEpRXSvhWvQ0leM-sROJ_XC7Fk1WjFXq57ysFtAA/edit?usp=sharing

A similar letter has to go to the eu, as they just passed similar rules.

as much as I would like to be working on the mill, it seems politics,
finance, and organisation are in more need of my attentions right now.
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@gmail.com




-- 
Dave Täht
Do you want faster, better, wifi? https://www.patreon.com/dtaht

Re: [Cerowrt-devel] some comments from elsewhere on the lockdown

[David P. Reed]

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

Those of us who innovate at the waveform and MAC layer would argue differently.  The cellular operators are actually the responsible control operators and hold licenses for that. They may want to lock down phones' cellular transmitters. But U-NII and ism bands are not licensed to these operators. There is no license requirement for those bands to use particular 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 device passed certification.

Lock down has not been demonstrated to be necessary. This is all due to fearful what - if speculation by people who have no data to justify the need, plus attempt to stop innovation by licensees who want to exclude competitors from being created, like LTE operators proposing LTE-U which 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 spectrum.

On Sep 24, 2015, Dave Taht <dave.taht@gmail.com> wrote:
>a commenter that I will keep anonymous wrote:
>
>
>Regarding the FCC firmware lockdown issue, I’m sure you’re aware that
>baseband firmware in cellphones has been subject to similar
>restrictions for some time. In fact, the FCC effectively mandates that
>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 easily
>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 many
>factors:
>
>The precedent from cellphone baseband firmware control; regulators are
>easily inspired by success stories in related areas
>The substantial increase in flexibility offered by SDR implementations
>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 GHz
>ISM to the U-NII bands, increases in transmit power allowances, etc.)
>The improved spectrum utilization of newer Wi-Fi modulation schemes
>Inconsistencies among international regulations for spectrum allocation
>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 that
>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 lot
>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 frequency,
>power, and modulation scheme, even for open-source solutions. That
>doesn’t mean the source code for the binary module can’t be published,
>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 modulation
>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 doesn’t
>overlap with the solutions they will accept.
>
>.               png
>
>
>On Sep 21, 2015, at 5:10 AM, Dave Taht <dmt@millcomputing.com> wrote:
>
>
>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 event.
>
>
>
>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 other
>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 devs
>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 aggregation.
>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 online.
>I am pushing on all fronts, but being a manager was a bit wearying so
>I took time out to do some recording at a place called theconvent.net
>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:
>https://wlan-si.net/en/blog/2015/09/08/battlemesh-v8-and-its-many-stories/
>
>The test results were dismal, as expected. Finally knocking a few
>heads to use abusive network tests like what toke and I developed were
>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:
>
>https://docs.google.com/document/d/1VTOHEpRXSvhWvQ0leM-sROJ_XC7Fk1WjFXq57ysFtAA/edit?usp=sharing
>
>A similar letter has to go to the eu, as they just passed similar
>rules.
>
>as much as I would like to be working on the mill, it seems politics,
>finance, and organisation are in more need of my attentions right now.
>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@gmail.com
>
>
>
>
>--
>Dave Täht
>Do you want faster, better, wifi? https://www.patreon.com/dtaht
>_______________________________________________
>Cerowrt-devel mailing list
>Cerowrt-devel@lists.bufferbloat.net
>https://lists.bufferbloat.net/listinfo/cerowrt-devel

-- Sent with K-@ Mail - the evolution of emailing.

[-- Attachment #2: Type: text/html, Size: 11609 bytes --]

Re: [Cerowrt-devel] some comments from elsewhere on the lockdown

[Dave Taht]

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
everybody.

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@reed.com> wrote:
> Those of us who innovate at the waveform and MAC layer would argue
> differently.  The cellular operators are actually the responsible control
> operators and hold licenses for that. They may want to lock down phones'
> cellular transmitters. But U-NII and ism bands are not licensed to these
> operators. There is no license requirement for those bands to use particular
> 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 device
> passed certification.
>
> Lock down has not been demonstrated to be necessary. This is all due to
> fearful what - if speculation by people who have no data to justify the
> need, plus attempt to stop innovation by licensees who want to exclude
> competitors from being created, like LTE operators proposing LTE-U which
> 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 spectrum.
>
>
> On Sep 24, 2015, Dave Taht <dave.taht@gmail.com> wrote:
>>
>> a commenter that I will keep anonymous wrote:
>>
>>
>> Regarding the FCC firmware lockdown issue, I’m sure you’re aware that
>> baseband firmware in cellphones has been subject to similar
>> restrictions for some time. In fact, the FCC effectively mandates that
>> 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 easily
>> 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 many
>> factors:
>>
>> The precedent from cellphone baseband firmware control; regulators are
>> easily inspired by success stories in related areas
>> The substantial increase in flexibility offered by SDR implementations
>> 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 GHz
>> ISM to the U-NII bands, increases in transmit power allowances, etc.)
>> The improved spectrum utilization of newer Wi-Fi modulation schemes
>> Inconsistencies among international regulations for spectrum allocation
>> 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 that
>> 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 lot
>> 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 frequency,
>> power, and modulation scheme, even for open-source solutions. That
>> doesn’t mean the source code for the binary module can’t be published,
>> 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 modulation
>> 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 doesn’t
>> overlap with the solutions they will accept.
>>
>> .               png
>>
>>
>> On Sep 21, 2015, at 5:10 AM, Dave Taht <dmt@millcomputing.com> wrote:
>>
>>
>> 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 event.
>>
>>
>>
>> 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 other
>> 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 devs
>> 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 aggregation.
>> 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 online.
>> I am pushing on all fronts, but being a manager was a bit wearying so
>> I took time out to do some recording at a place called theconvent.net
>> 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:
>> https://wlan-si.net/en/blog/2015/09/08/battlemesh-v8-and-its-many-stories/
>>
>> The test results were dismal, as expected. Finally knocking a few
>> heads to use abusive network tests like what toke and I developed were
>> 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:
>>
>>
>> https://docs.google.com/document/d/1VTOHEpRXSvhWvQ0leM-sROJ_XC7Fk1WjFXq57ysFtAA/edit?usp=sharing
>>
>> A similar letter has to go to the eu, as they just passed similar rules.
>>
>> as much as I would like to be working on the mill, it seems politics,
>> finance, and organisation are in more need of my attentions right now.
>> 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@gmail.com
>>
>>
>>
>
> -- Sent with K-@ Mail - the evolution of emailing.



-- 
Dave Täht
endo is a terrible disease: http://www.gofundme.com/SummerVsEndo

Re: [Cerowrt-devel] some comments from elsewhere on the lockdown

[David P. Reed]

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

Sounds great to me

On Sep 25, 2015, Dave Taht <dave.taht@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
>everybody.
>
>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@reed.com> wrote:
>> Those of us who innovate at the waveform and MAC layer would argue
>> differently.  The cellular operators are actually the responsible
>control
>> operators and hold licenses for that. They may want to lock down
>phones'
>> cellular transmitters. But U-NII and ism bands are not licensed to
>these
>> operators. There is no license requirement for those bands to use
>particular
>> 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
>device
>> passed certification.
>>
>> Lock down has not been demonstrated to be necessary. This is all due
>to
>> fearful what - if speculation by people who have no data to justify
>the
>> need, plus attempt to stop innovation by licensees who want to
>exclude
>> competitors from being created, like LTE operators proposing LTE-U
>which
>> 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
>spectrum.
>>
>>
>> On Sep 24, 2015, Dave Taht <dave.taht@gmail.com> wrote:
>>>
>>> a commenter that I will keep anonymous wrote:
>>>
>>>
>>> Regarding the FCC firmware lockdown issue, I’m sure you’re aware
>that
>>> baseband firmware in cellphones has been subject to similar
>>> restrictions for some time. In fact, the FCC effectively mandates
>that
>>> 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
>easily
>>> 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
>many
>>> factors:
>>>
>>> The precedent from cellphone baseband firmware control; regulators
>are
>>> easily inspired by success stories in related areas
>>> The substantial increase in flexibility offered by SDR
>implementations
>>> 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
>GHz
>>> ISM to the U-NII bands, increases in transmit power allowances,
>etc.)
>>> The improved spectrum utilization of newer Wi-Fi modulation schemes
>>> Inconsistencies among international regulations for spectrum
>allocation
>>> 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
>that
>>> 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
>lot
>>> 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
>frequency,
>>> power, and modulation scheme, even for open-source solutions. That
>>> doesn’t mean the source code for the binary module can’t be
>published,
>>> 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
>modulation
>>> 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
>doesn’t
>>> overlap with the solutions they will accept.
>>>
>>> .               png
>>>
>>>
>>> On Sep 21, 2015, at 5:10 AM, Dave Taht <dmt@millcomputing.com>
>wrote:
>>>
>>>
>>> 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
>event.
>>>
>>>
>>>
>>> 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
>other
>>> 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
>devs
>>> 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
>aggregation.
>>> 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
>online.
>>> I am pushing on all fronts, but being a manager was a bit wearying
>so
>>> I took time out to do some recording at a place called
>theconvent.net
>>> 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:
>>>
>https://wlan-si.net/en/blog/2015/09/08/battlemesh-v8-and-its-many-stories/
>>>
>>> The test results were dismal, as expected. Finally knocking a few
>>> heads to use abusive network tests like what toke and I developed
>were
>>> 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:
>>>
>>>
>>>
>https://docs.google.com/document/d/1VTOHEpRXSvhWvQ0leM-sROJ_XC7Fk1WjFXq57ysFtAA/edit?usp=sharing
>>>
>>> A similar letter has to go to the eu, as they just passed similar
>rules.
>>>
>>> as much as I would like to be working on the mill, it seems
>politics,
>>> finance, and organisation are in more need of my attentions right
>now.
>>> 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@gmail.com
>>>
>>>
>>>
>>
>> -- Sent with K-@ Mail - the evolution of emailing.

-- Sent with K-@ Mail - the evolution of emailing.

[-- Attachment #2: Type: text/html, Size: 14771 bytes --]

Re: [Cerowrt-devel] some comments from elsewhere on the lockdown

[Valdis.Kletnieks]

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

On Fri, 25 Sep 2015 22:40:02 +0100, Dave Taht said:

Sorry for late reply...


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

This needs to address vendors going out of business, and also corporate
acquisitions.

Bonus points for explaining how to deal with a CVE against hardware that's 7
years and 10 months out of production (3 years warranty + 5) - that requires a
hardware engineering change to properly close.

(I once got my chops busted by somebody from the GNU project over clause
3B of the GPLV2:

    b) Accompany it with a written offer, valid for at least three
    years, to give any third party, for a charge no more than your
    cost of physically performing source distribution, a complete
    machine-readable copy of the corresponding source code, to be
    distributed under the terms of Sections 1 and 2 above on a medium
    customarily used for software interchange; or,

Apparently, they were of the opinion that the mere fact that I might
die of a heart attack a year after distributing something doesn't
excuse me from complying.)


[-- Attachment #2: Type: application/pgp-signature, Size: 848 bytes --]

Re: [Cerowrt-devel] [FCC] some comments from elsewhere on the lockdown

[Valdis.Kletnieks]

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

On Wed, 30 Sep 2015 16:11:38 -0400, Christopher Waid said:

> > Apparently, they were of the opinion that the mere fact that I might
> > die of a heart attack a year after distributing something doesn't
> > excuse me from complying.)
>
> I don't know if it does excuse you from complying, but I say good luck
> to the person trying to get it enforced.

They could quite possibly hassle the executor of my estate if they were
sufficiently determined.

But given that abandonware (both software and hardware) is a big chunk
of the problem, we really *do* need to address the problem of companies
that can't provide patches because they've gone under.  Possibly a
requirement that they open-source the hardware/software if possible?
(That's another can-o-worms - consider that a big chunk of why NVidia
doesn't open-source their proprietary graphics drivers is because there's
a lot of OpenGL-related patents and trade secrets that Microsoft bought when
there was the big fire sale when SGI got out of the graphics market - so
it's quite possible that a vendor *can't* open-source it when they go
under due to licensing issues...)

[-- Attachment #2: Type: application/pgp-signature, Size: 848 bytes --]

Re: [Cerowrt-devel] [FCC] some comments from elsewhere on the lockdown

[David P. Reed]

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

I love copy left thinking. I worry that I can't sign something so provocative, because it invokes regulatory overreach.

The letter is taking a totalitarian turn, asking government to go beyond choice. I thought we were reducing the power of the FCC Iintitution, but now it is a call for extreme control.

Instead of innovation it seeks control over innovators.

On Sep 30, 2015, Valdis.Kletnieks@vt.edu wrote:
>On Wed, 30 Sep 2015 16:11:38 -0400, Christopher Waid said:
>
>> > Apparently, they were of the opinion that the mere fact that I
>might
>> > die of a heart attack a year after distributing something doesn't
>> > excuse me from complying.)
>>
>> I don't know if it does excuse you from complying, but I say good
>luck
>> to the person trying to get it enforced.
>
>They could quite possibly hassle the executor of my estate if they were
>sufficiently determined.
>
>But given that abandonware (both software and hardware) is a big chunk
>of the problem, we really *do* need to address the problem of companies
>that can't provide patches because they've gone under.  Possibly a
>requirement that they open-source the hardware/software if possible?
>(That's another can-o-worms - consider that a big chunk of why NVidia
>doesn't open-source their proprietary graphics drivers is because
>there's
>a lot of OpenGL-related patents and trade secrets that Microsoft bought
>when
>there was the big fire sale when SGI got out of the graphics market -
>so
>it's quite possible that a vendor *can't* open-source it when they go
>under due to licensing issues...)

-- Sent with K-@ Mail - the evolution of emailing.

[-- Attachment #2: Type: text/html, Size: 2673 bytes --]

Re: [Cerowrt-devel] [FCC] some comments from elsewhere on the lockdown

[Dave Taht]

On Thu, Oct 1, 2015 at 12:33 PM, David P. Reed <dpreed@reed.com> wrote:
> I love copy left thinking. I worry that I can't sign something so
> provocative, because it invokes regulatory overreach.
>
> The letter is taking a totalitarian turn, asking government to go beyond
> choice. I thought we were reducing the power of the FCC Iintitution, but now
> it is a call for extreme control.

?

If you could point to the paragraphs you are objecting to, we can
resolve your issues. Hopefully. The ultimate control should reside in
the owner, and I thought we'd brought that out sufficiently.

> Instead of innovation it seeks control over innovators.
>
>
> On Sep 30, 2015, Valdis.Kletnieks@vt.edu wrote:
>>
>> On Wed, 30 Sep 2015 16:11:38 -0400, Christopher Waid said:
>>
>>>> Apparently, they were of the opinion that the mere fact that I might
>>>> die of a heart attack a year after distributing something doesn't
>>>> excuse me from complying.)
>>>
>>>
>>> I don't know if it does excuse you from complying, but I say good luck
>>> to the person trying to get it enforced.
>>
>>
>> They could quite possibly hassle the executor of my estate if they were
>> sufficiently determined.
>>
>> But given that abandonware (both software and hardware) is a big chunk
>> of the problem, we really *do* need to address the problem of companies
>> that can't provide patches because they've gone under. Possibly a
>> requirement that they open-source the hardware/software if possible?
>> (That's another can-o-worms - consider that a big chunk of why NVidia
>> doesn't open-source their proprietary graphics drivers is because there's
>> a lot of OpenGL-related patents and trade secrets that Microsoft bought
>> when
>> there was the big fire sale when SGI got out of the graphics market - so
>> it's quite possible that a vendor *can't* open-source it when they go
>> under due to licensing issues...)
>
>
> -- Sent with K-@ Mail - the evolution of emailing.



-- 
Dave Täht
Do you want faster, better, wifi? https://www.patreon.com/dtaht

[Cerowrt-devel] Editorial questions for response to the FCC

[Rich Brown]

Folks,

I have screwed up my nerve to take an editorial pass over the document. It has a lot of good information and many useful citations, but it needs focus to be effective.

As I read through (yesterday's) draft of the document and the comments, I came up with observations to confirm and questions that I want to understand before charging ahead.

Observations:

1) Unfortunately, we are coming to this very late: if I understand the timeline, the FCC proposed these rules a year ago, the comment period for the NPRM closed 2 months ago, and we only got an extra month's extension of the deadline because their computer was going to be down on the original filing date. (Note - that doesn't challenge any of our points' validity, only that we need to be very specific in what we say/ask for.)

2) The FCC will view all this through the lens of "Licensed use has priority for spectrum over unlicensed." That's just the rules. Any effort to say they should change their fundamental process will cause our comments to be disregarded.

3) The *operator* (e.g., homeowner) is responsible for the proper operation of a radio. If the FCC discovers your home router is operating outside its allowed parameters *you* must (immediately?) remediate it or take it off the air.

4) We must clearly and vigorously address the FCC admonishment to "prevent installing DD-WRT"

5) [Opinion] I share dpreed's concern that the current draft overplays our hand, requesting more control/change than the FCC would be willing to allow. See Question 7 below for a possible alternative.

Questions:

1) What is our request? What actions would we like the FCC to take?

2) How much of a deviation from their current rules (the ones we're commenting on) are we asking them to embrace?

3) How much dust could/should we kick up? For example, is it useful to point out that these FCC rules do not address other practices that are possible today: 
	- Use of high gain antennas (which would certainly introduce a stronger signal than the design parameters); 
	- Use of other (non-commercially produced) SDR transmitters;
	- Malicious attack that takes control of insecure vendor software to alter the RF parameters 
	- Router manufacturers in most cases are already *contractually obliged* to release full source code for their routers (GPL). In the past, many have been resistant to doing so, especially for the RF drivers. Do any concerns of the FCC change if there were to be a full source code release?

4) Footnotes 15, 16, and 17 cite published reports of router vendors using activation codes or new firmware lockdowns where previously not present. Do any readers have personal/verified knowledge of these activities?

5) Vendors certify release X of their firmware in tests with the FCC. It includes the entire binary, including radio control parameters, OS version, web GUI, etc. Do we know anything about whether vendor's X+1 release goes through the same FCC certification process? Or do they just fix a couple bugs and re-release knowing that they haven't touched the RF driver...

6) Vendors are generally do not release source code for the wireless drivers. How likely is it that this reluctance is due to a concern that the vendor could get in trouble with the FCC if people modified that code?

7) Would it be feasible to ask the FCC to require that vendors *publish* the critical parameters/source code for operating in spec, so that responsible software developers can carefully observe those parameters? (We already have code that handles the RF specs for various countries. Could we envision doing the same for each router/model/version radio parameters?)

I'm going to collect your comments for ~24 hours, then start editing. My goal is to have a draft by Monday morning, 5 Oct to refine for the 9 Oct deadline. Thanks!

Rich

Re: [Cerowrt-devel] Editorial questions for response to the FCC

[dpreed]

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


This is good. Regarding my concern about asking for mandated FCC-centered control - we need less of that. It establishes a bad precedent for the means of "protecting the airwaves".  (or reinforces a precedent that must be changed soon - of establishing de-facto, anti-innovation monopolies that derive from regulatory mandates). And it creates a problematic "us vs. them" debate where there is none.
 
A vast majority of folks want interoperability of all kinds of communications, and that includes sharability of the wireless medium.  That means finding approaches for coexistence and innovation, without mandates for the technological solution based on a particular implementation of hardware or systems architecture. An evolutionary approach.
 
So we don't have to specify alternative rules in detail.  And by going into detail too much, we only lose support.
 
What have to demonstrate is that there is *at least one* better approach, while also pointing out what will be lost with the proposed approach in the NPRM.  Most of the letter focuses on these, quite correctly, but it might be useful to clarify those two lines of argument by an editorial pass.  The approach suggested in the letter should be presented as open to further improvement that achieves the shared goals.
 
This is why emphasizing "mandates" and punishments is probably counterproductive. The goals that stand behind the proposed mandates should be emphasized, the mandates left to be developed in detail based on those goals.
 
The battle here is part of a longer term, necessary reframing of regulatory practice.  Current regulation is based on means rather than ends, and doesn't consider what is technologically possible. And it is centered on control of what capabilities are delivered in fixed function devices, rather than in how those devices are used or how they integrate into systems. As an absurd example, we certainly would like to prevent people from being electrocuted.  But does that mean we must specify how an electric vehicle is built down to the voltages of batteries used and what kind of switching transistors must be used in the power supply?  Or that the only battery charging that is allowed must be done at stations owned by the vendor of the vehicle?
 
That longer term reframing must take into account the characteristics of the trillions of wireless nodes that will be deployed in the next 25 years.  There's been no study of that by the FCC (though some of us have tried, as I did at the TAC when I was on it) at all.
 
That can't be accomplished in this NPRM.  The battle is to prevent this regulation from being deployed, because it is a huge step backwards.  Fortunately, we *don't* need to rewrite the regulation, so quickly.
 
We need to argue that they need to go back to the drawing board with a new perspective.  The approach proposed should focus that effort, but it need not be adopted now.  It might turn out even worse...  So the goal is to stop the NPRM.
 


On Friday, October 2, 2015 10:22am, "Rich Brown" <richb.hanover@gmail.com> said:



> Folks,
> 
> I have screwed up my nerve to take an editorial pass over the document. It has a
> lot of good information and many useful citations, but it needs focus to be
> effective.
> 
> As I read through (yesterday's) draft of the document and the comments, I came up
> with observations to confirm and questions that I want to understand before
> charging ahead.
> 
> Observations:
> 
> 1) Unfortunately, we are coming to this very late: if I understand the timeline,
> the FCC proposed these rules a year ago, the comment period for the NPRM closed 2
> months ago, and we only got an extra month's extension of the deadline because
> their computer was going to be down on the original filing date. (Note - that
> doesn't challenge any of our points' validity, only that we need to be very
> specific in what we say/ask for.)
> 
> 2) The FCC will view all this through the lens of "Licensed use has priority for
> spectrum over unlicensed." That's just the rules. Any effort to say they should
> change their fundamental process will cause our comments to be disregarded.
> 
> 3) The *operator* (e.g., homeowner) is responsible for the proper operation of a
> radio. If the FCC discovers your home router is operating outside its allowed
> parameters *you* must (immediately?) remediate it or take it off the air.
> 
> 4) We must clearly and vigorously address the FCC admonishment to "prevent
> installing DD-WRT"
> 
> 5) [Opinion] I share dpreed's concern that the current draft overplays our hand,
> requesting more control/change than the FCC would be willing to allow. See
> Question 7 below for a possible alternative.
> 
> Questions:
> 
> 1) What is our request? What actions would we like the FCC to take?
> 
> 2) How much of a deviation from their current rules (the ones we're commenting on)
> are we asking them to embrace?
> 
> 3) How much dust could/should we kick up? For example, is it useful to point out
> that these FCC rules do not address other practices that are possible today:
> - Use of high gain antennas (which would certainly introduce a stronger signal
> than the design parameters);
> - Use of other (non-commercially produced) SDR transmitters;
> - Malicious attack that takes control of insecure vendor software to alter the RF
> parameters
> - Router manufacturers in most cases are already *contractually obliged* to
> release full source code for their routers (GPL). In the past, many have been
> resistant to doing so, especially for the RF drivers. Do any concerns of the FCC
> change if there were to be a full source code release?
> 
> 4) Footnotes 15, 16, and 17 cite published reports of router vendors using
> activation codes or new firmware lockdowns where previously not present. Do any
> readers have personal/verified knowledge of these activities?
> 
> 5) Vendors certify release X of their firmware in tests with the FCC. It includes
> the entire binary, including radio control parameters, OS version, web GUI, etc.
> Do we know anything about whether vendor's X+1 release goes through the same FCC
> certification process? Or do they just fix a couple bugs and re-release knowing
> that they haven't touched the RF driver...
> 
> 6) Vendors are generally do not release source code for the wireless drivers. How
> likely is it that this reluctance is due to a concern that the vendor could get in
> trouble with the FCC if people modified that code?
> 
> 7) Would it be feasible to ask the FCC to require that vendors *publish* the
> critical parameters/source code for operating in spec, so that responsible
> software developers can carefully observe those parameters? (We already have code
> that handles the RF specs for various countries. Could we envision doing the same
> for each router/model/version radio parameters?)
> 
> I'm going to collect your comments for ~24 hours, then start editing. My goal is
> to have a draft by Monday morning, 5 Oct to refine for the 9 Oct deadline.
> Thanks!
> 
> Rich

[-- Attachment #2: Type: text/html, Size: 10080 bytes --]

Re: [Cerowrt-devel] some comments from elsewhere on the lockdown

[Laurent GUERBY]

Hi,

Another US agency vs free software and user freedom :

http://www.nytimes.com/2015/09/23/nyregion/volkswagens-diesel-fraud-makes-critic-of-secret-code-a-prophet.html?_r=0
<<
Volkswagen’s Diesel Fraud Makes Critic of Secret Code a Prophet
SEPT. 22, 2015
(...)
That is not how carmakers or even the E.P.A. see things. The code in
automobiles is tightly protected under the Digital Millennium Copyright
Act. Last year, several groups sought to have the code made available
for “good-faith testing, identifying, disclosing and fixing of
malfunctions, security flaws or vulnerabilities,” as Alex Davies
reported last week in Wired.

A group of automobile manufacturers said that opening the code to
scrutiny could create “serious threats to safety and security.” And two
months ago, the E.P.A. said it, too, opposed such a move because people
might try to reprogram their cars to beat emission rules.
(...)
>>

Sincerely,

Laurent

On Thu, 2015-09-24 at 12:49 -0700, Dave Taht wrote:
> a commenter that I will keep anonymous wrote:
> 
> 
> Regarding the FCC firmware lockdown issue, I’m sure you’re aware that
> baseband firmware in cellphones has been subject to similar
> restrictions for some time. In fact, the FCC effectively mandates that
> 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 easily
> 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 many factors:
> 
> The precedent from cellphone baseband firmware control; regulators are
> easily inspired by success stories in related areas
> The substantial increase in flexibility offered by SDR implementations
> 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 GHz
> ISM to the U-NII bands, increases in transmit power allowances, etc.)
> The improved spectrum utilization of newer Wi-Fi modulation schemes
> Inconsistencies among international regulations for spectrum allocation
> 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 that
> 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 lot
> 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 frequency,
> power, and modulation scheme, even for open-source solutions. That
> doesn’t mean the source code for the binary module can’t be published,
> 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 modulation
> 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 doesn’t
> overlap with the solutions they will accept.
> 
> .               png
> 
> 
> On Sep 21, 2015, at 5:10 AM, Dave Taht <dmt@millcomputing.com> wrote:
> 
> 
> 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 event.
> 
> 
> 
> 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 other
> 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 devs
> 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 aggregation.
> 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 online.
> I am pushing on all fronts, but being a manager was a bit wearying so
> I took time out to do some recording at a place called theconvent.net
> 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: https://wlan-si.net/en/blog/2015/09/08/battlemesh-v8-and-its-many-stories/
> 
> The test results were dismal, as expected. Finally knocking a few
> heads to use abusive network tests like what toke and I developed were
> 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:
> 
> https://docs.google.com/document/d/1VTOHEpRXSvhWvQ0leM-sROJ_XC7Fk1WjFXq57ysFtAA/edit?usp=sharing
> 
> A similar letter has to go to the eu, as they just passed similar rules.
> 
> as much as I would like to be working on the mill, it seems politics,
> finance, and organisation are in more need of my attentions right now.
> 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@gmail.com
> 
> 
> 
>