Re: [Make-wifi-fast] [bufferbloat-fcc-discuss] arstechnica confirms tp-link router lockdown

Re: [Make-wifi-fast] [bufferbloat-fcc-discuss] arstechnica confirms tp-link router lockdown

[Brandon Butterworth]

On Sat, 13 Mar 2016, David lang wrote:
> I would do us no good to create a fully open chip if the FCC mandates
> that the firmware must be locked down.

Which firmware must be locked down? I was under the impression that is
just retail end user devices, is the suggestion that chip manufacturers
will not be allowed to sell parts to people who might make a non locked
down device? Does that include if they don't supply firmware and the
user writes their own/reverse engineers others? Sounds like a road to
future regulating all rf hardware sale (stop people selling rp
connectors as it's letting them circumvent the antenna limitations they
were designed to impose?)

Given the interference that caused this is a few incidents a year
compared to the millions of units sold and that those cases were
either bad users or caused by faulty devices it seems that the
lock down would have to be total to prevent future incidents. Quite
impractical.

> Would I like someone to do this, Sure. I'll contribute towards a
> kickstarter, even if it's $100 for a mini-pci card that is the
> equivalent of what we can get today for $30, but it would take
> tens of thousands of people doing that to fund the project, and
> I have serious doubts if you can get that much funding for 
> something with such a long lead time.

It think it would be cheaper and quicker to reverse engineer drivers
for others hardware. Even if the cost could be covered to build it'd
lag commercial products by years making it a difficult sell, and likely
subjected to IPR claims from current manufacturers

> If someone does the research and puts together a FPGA version

That could be an interesting project. It may not help but we have
an FPGA MIMO implementation we may be able to release to such a
project (it may be unsuitable though, we've been making radio cameras
https://www.google.co.uk/?gws_rd=ssl#q=bbc+r%26d+mimo
https://www.google.co.uk/?gws_rd=ssl#q=bbc+r%26d+halfrf )

> and is looking for funding to convert it to a ASIC, I think you
> could get funding. But that's not the question in front of us now.

Yes, and if the lock down expands to chips too would have
the same problem

brandon

Re: [Make-wifi-fast] [bufferbloat-fcc-discuss] arstechnica confirms tp-link router lockdown

[David Lang]

On Sun, 13 Mar 2016, Brandon Butterworth wrote:

> On Sat, 13 Mar 2016, David lang wrote:
>> I would do us no good to create a fully open chip if the FCC mandates
>> that the firmware must be locked down.
>
> Which firmware must be locked down? I was under the impression that is
> just retail end user devices, is the suggestion that chip manufacturers
> will not be allowed to sell parts to people who might make a non locked
> down device? Does that include if they don't supply firmware and the
> user writes their own/reverse engineers others? Sounds like a road to
> future regulating all rf hardware sale (stop people selling rp
> connectors as it's letting them circumvent the antenna limitations they
> were designed to impose?)
>
> Given the interference that caused this is a few incidents a year
> compared to the millions of units sold and that those cases were
> either bad users or caused by faulty devices it seems that the
> lock down would have to be total to prevent future incidents. Quite
> impractical.

the original proposed ruling specifically asked for ways to block loading DD-WRT 
on devices.

If the FCC requires a lockdown like this, then it becomes something they test 
during the certification process, so unless you buy the chips and build 
something yourself that is not certified, you can't user it.

That would mean that even if we were to build a free component, we would never 
see it in any devices that aren't locked down.

>> Would I like someone to do this, Sure. I'll contribute towards a
>> kickstarter, even if it's $100 for a mini-pci card that is the
>> equivalent of what we can get today for $30, but it would take
>> tens of thousands of people doing that to fund the project, and
>> I have serious doubts if you can get that much funding for
>> something with such a long lead time.
>
> It think it would be cheaper and quicker to reverse engineer drivers
> for others hardware. Even if the cost could be covered to build it'd
> lag commercial products by years making it a difficult sell, and likely
> subjected to IPR claims from current manufacturers

the issue isn't the drivers, it's in the firmware running on the radio chip. 
That does a lot of stuff (implements the entire 801.11 protocol)

>> If someone does the research and puts together a FPGA version
>
> That could be an interesting project. It may not help but we have
> an FPGA MIMO implementation we may be able to release to such a
> project (it may be unsuitable though, we've been making radio cameras
> https://www.google.co.uk/?gws_rd=ssl#q=bbc+r%26d+mimo
> https://www.google.co.uk/?gws_rd=ssl#q=bbc+r%26d+halfrf )
>
>> and is looking for funding to convert it to a ASIC, I think you
>> could get funding. But that's not the question in front of us now.
>
> Yes, and if the lock down expands to chips too would have
> the same problem

As I understand it, every 802.11ac chipset is using closed-source firmware. The 
proposal was to solve this by createing a new chipset with open firmware. That 
isn't going to be useful if it's only a FPGA implementation that is priced out 
of range for commercial products, so whatever is built to be a replacement 
chipset would have to be reduced to ASIC or it won't be cheap enough to be used.

David Lang

[Make-wifi-fast] arstechnica confirms tp-link router lockdown

[Dave Taht]

http://arstechnica.com/information-technology/2016/03/tp-link-blocks-open-source-router-firmware-to-comply-with-new-fcc-rule/

I've tweeted, facebooked, and g+'d. I've also seen it just hit the fcc
list, and perhaps it will cross over into more media (with a little
help from y'all?) I also matched the donations to the savewifi site
over the past month (620 or so) with a matched donation to:
https://www.gofundme.com/save_wifi_round_2/

Also of ironic interest today was:

http://mjg59.dreamwidth.org/40505.html

--
Dave Täht
Do you really want software in your house you cannot control?
https://www.gofundme.com/save_wifi_round_2/

Re: [Make-wifi-fast] [bufferbloat-fcc-discuss] arstechnica confirms tp-link router lockdown

[Henning Rogge]

On Sat, Mar 12, 2016 at 3:32 PM, Wayne Workman
<wayne.workman2012@gmail.com> wrote:
> I understand that Broadcom was paid to develop the Pi, a totally free board.
>
> And they already make wireless chipsets.

The question is how easy would it be to build a modern 802.11ac
halfmac chip... the amount of work these chips do (especially with 3*3
or 4*4 MIMO) is not trivial.

Henning Rogge

Re: [Make-wifi-fast] [bufferbloat-fcc-discuss] arstechnica confirms tp-link router lockdown

[Adrian Chadd]

On 12 March 2016 at 11:14, Henning Rogge <hrogge@gmail.com> wrote:
> On Sat, Mar 12, 2016 at 3:32 PM, Wayne Workman
> <wayne.workman2012@gmail.com> wrote:
>> I understand that Broadcom was paid to develop the Pi, a totally free board.
>>
>> And they already make wireless chipsets.
>
> The question is how easy would it be to build a modern 802.11ac
> halfmac chip... the amount of work these chips do (especially with 3*3
> or 4*4 MIMO) is not trivial.

It's not that scary - most of the latency sensitive things are:

* channel change - eg background scans
* calibration related things - but most slow calibration could be done
via firmware commands, like the intel chips do!
* transmit a-mpdu / retransmit
* transmit rate control adaptation
* receiving / block-ack things - which is mostly done in hardware anyway
* likely some power save transition-y things too

If you're doing STA mode, then you have more things to do - eg bgscans
with active traffic, TDLS, P2P, etc.
If you're doing hostap mode or heck, even mostly-dumb ibss mode -
where there's no requirement for off-channel traffic - the firmware is
mostly just a transmit/receive engine and some power save stuff.

And honestly - know how many cycles a modern CPU has? If you don't
care about hyper-optimising for power consumption (ie, you're not a
phone), then I bet you could get away with ath9k model hardware. Those
same lower end CPUs can do 200kpps on an ethernet NIC right now. The
reordering and retransmit stuff could be handled in firmware, but
that's about it - and again, only if you wanted to do it on some
anenmic SoC or you cared about power.

People keep talking about "oh god, these things do so much now" - but
that's because people are thinking about phones or those L2-cache-less
anemic older SOCs that are massively memory bandwidth constrained.
Newer stuff is much less terrible.



-adrian

Re: [Make-wifi-fast] [bufferbloat-fcc-discuss] arstechnica confirms tp-link router lockdown

[Dave Taht]

You can acquire the 802.11ac specs easiest merely by attending an IEEE
802.11 wg meeting once, and joining to get the ongoing work, and many
specs are now increasingly available via:

http://www.ieee802.org/11/

The meeting schedule is here:

http://www.ieee802.org/11/Meetings/Meeting_Plan.html

What is generally coming down the pike (802.11ax, ad, ak, etc) is
often quite fascinating, but I have to admit, I am burnt out on going
to SDO (standards organization) meetings personally, and yet I long to
have a member or members of this group attending IEEE 802.11
regularly. (is anyone here doing so?)

I like to think that my talk there in sept 2014 is proving influential
(a public version, I gave last august, here:
https://www.youtube.com/watch?v=Rb-UnHDw02o  ) , but hardware design
cycles are long, meetings sometimes mind-numbingly tedious (like all
meetings, most of the work takes place in the hallways), sometimes
horrifying (lots of people trying to reinvent layer3 at layer 2), and
breakthrough technologies are only slowly adopted, particularly when
there are major patent holders in the room.

I've been meaning to go to next week's meeting, but couldn't raise the
funds or allocate the time to go. I still felt going to china would
have been worth while. If anyone here wants to hop on a plane??

Dave Täht
Let's go make home routers and wifi faster! With better software!
https://www.gofundme.com/savewifi


On Sat, Mar 12, 2016 at 1:42 PM, Wayne Workman
<wayne.workman2012@gmail.com> wrote:
> Earlier today I was reading over the IC  wiki articles our there. I can't
> say I understand a lot of it but they all start with a common thing.
> Specifications. And I won't pretend to be an expert in defining those
> either. But I'd say the 802.11ac specs would likely be what we are after -
> and 100% GPLv3 non-negotiable.
>
> On Mar 12, 2016 2:18 PM, "Adrian Chadd" <adrian@freebsd.org> wrote:
>>
>> On 12 March 2016 at 11:14, Henning Rogge <hrogge@gmail.com> wrote:
>> > On Sat, Mar 12, 2016 at 3:32 PM, Wayne Workman
>> > <wayne.workman2012@gmail.com> wrote:
>> >> I understand that Broadcom was paid to develop the Pi, a totally free
>> >> board.
>> >>
>> >> And they already make wireless chipsets.
>> >
>> > The question is how easy would it be to build a modern 802.11ac
>> > halfmac chip... the amount of work these chips do (especially with 3*3
>> > or 4*4 MIMO) is not trivial.
>>
>> It's not that scary - most of the latency sensitive things are:
>>
>> * channel change - eg background scans
>> * calibration related things - but most slow calibration could be done
>> via firmware commands, like the intel chips do!
>> * transmit a-mpdu / retransmit
>> * transmit rate control adaptation
>> * receiving / block-ack things - which is mostly done in hardware anyway
>> * likely some power save transition-y things too
>>
>> If you're doing STA mode, then you have more things to do - eg bgscans
>> with active traffic, TDLS, P2P, etc.
>> If you're doing hostap mode or heck, even mostly-dumb ibss mode -
>> where there's no requirement for off-channel traffic - the firmware is
>> mostly just a transmit/receive engine and some power save stuff.
>>
>> And honestly - know how many cycles a modern CPU has? If you don't
>> care about hyper-optimising for power consumption (ie, you're not a
>> phone), then I bet you could get away with ath9k model hardware. Those
>> same lower end CPUs can do 200kpps on an ethernet NIC right now. The
>> reordering and retransmit stuff could be handled in firmware, but
>> that's about it - and again, only if you wanted to do it on some
>> anenmic SoC or you cared about power.
>>
>> People keep talking about "oh god, these things do so much now" - but
>> that's because people are thinking about phones or those L2-cache-less
>> anemic older SOCs that are massively memory bandwidth constrained.
>> Newer stuff is much less terrible.
>>
>>
>>
>> -adrian
>
>
> _______________________________________________
> bufferbloat-fcc-discuss mailing list
> bufferbloat-fcc-discuss@lists.redbarn.org
> http://lists.redbarn.org/mailman/listinfo/bufferbloat-fcc-discuss
>

Re: [Make-wifi-fast] [bufferbloat-fcc-discuss] arstechnica confirms tp-link router lockdown

[David Lang]

On Sat, 12 Mar 2016, Adrian Chadd wrote:

> On 12 March 2016 at 11:14, Henning Rogge <hrogge@gmail.com> wrote:
>> On Sat, Mar 12, 2016 at 3:32 PM, Wayne Workman
>> <wayne.workman2012@gmail.com> wrote:
>>> I understand that Broadcom was paid to develop the Pi, a totally free board.
>>>
>>> And they already make wireless chipsets.
>>
>> The question is how easy would it be to build a modern 802.11ac
>> halfmac chip... the amount of work these chips do (especially with 3*3
>> or 4*4 MIMO) is not trivial.
>
> It's not that scary - most of the latency sensitive things are:
>
> * channel change - eg background scans
> * calibration related things - but most slow calibration could be done
> via firmware commands, like the intel chips do!
> * transmit a-mpdu / retransmit
> * transmit rate control adaptation
> * receiving / block-ack things - which is mostly done in hardware anyway
> * likely some power save transition-y things too

you are ignoring MU-MIMO, the ability to transmit different signals from each 
antenna so that the interference patterns from the different signals result in 
different readable data depending on where the receiver is in relation to the 
access point is not a trivial thing.

But it's one of the most valuable features in the spec.

David Lang

Re: [Make-wifi-fast] [bufferbloat-fcc-discuss] arstechnica confirms tp-link router lockdown

[David Lang]

On Sat, 12 Mar 2016, Wayne Workman wrote:

> @David lang,
>
> Dude, Help make it happen.
>
> I don't know all the details. I don't even pretend to know anything about
> IC design and manufacturing.
>
> Look if we want a platform that is open, then it'll be an open source
> chipset. Yes, the first of its kind.
>
> We need someone who is willing to do this in their free time(as you said),
> or a company that is willing to be paid to do it.
>
> We can be pioneers.
>
> We CAN be pioneers.
>
> All we have to do is figure this out. It's been done before, with the Linux
> kernel. It can be done again. The person who has made a chipset in their
> free time is out there. Let's find them!

I'll be happy to support anyone who tackles this. But your question was if 
something like this was a good use of 'our money'. If you are talking the 
bufferbloat team, make-wifi-fast team, or even team trying to convince teh FCC 
nto to outlaw OpenWRT, then no, funding the development of a chipset from 
scratch is not a good use of 'our money', it will have no effect for several 
years (by which time we may be looking at the next chipset), and we don't have 
anywhere close to the funding needed to pull it off.

I would do us no good to create a fully open chip if the FCC mandates that the 
firmware must be locked down.

Would I like someone to do this, Sure. I'll contribute towards a kickstarter, 
even if it's $100 for a mini-pci card that is the equivalent of what we can get 
today for $30, but it would take tens of thousands of people doing that to fund 
the project, and I have serious doubts if you can get that much funding for 
something with such a long lead time.

If someone does the research and puts together a FPGA version that works and is 
looking for funding to convert it to a ASIC, I think you could get funding. But 
that's not the question in front of us now.

David Lang

Re: [Make-wifi-fast] [bufferbloat-fcc-discuss] arstechnica confirms tp-link router lockdown

[Adrian Chadd]

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

You do that in hardware. Do the Mac, phy and RF in hardware.

This is what the qca hardware does.

a
On Mar 13, 2016 5:25 PM, "David Lang" <david@lang.hm> wrote:

> On Sat, 12 Mar 2016, Adrian Chadd wrote:
>
> On 12 March 2016 at 11:14, Henning Rogge <hrogge@gmail.com> wrote:
>>
>>> On Sat, Mar 12, 2016 at 3:32 PM, Wayne Workman
>>> <wayne.workman2012@gmail.com> wrote:
>>>
>>>> I understand that Broadcom was paid to develop the Pi, a totally free
>>>> board.
>>>>
>>>> And they already make wireless chipsets.
>>>>
>>>
>>> The question is how easy would it be to build a modern 802.11ac
>>> halfmac chip... the amount of work these chips do (especially with 3*3
>>> or 4*4 MIMO) is not trivial.
>>>
>>
>> It's not that scary - most of the latency sensitive things are:
>>
>> * channel change - eg background scans
>> * calibration related things - but most slow calibration could be done
>> via firmware commands, like the intel chips do!
>> * transmit a-mpdu / retransmit
>> * transmit rate control adaptation
>> * receiving / block-ack things - which is mostly done in hardware anyway
>> * likely some power save transition-y things too
>>
>
> you are ignoring MU-MIMO, the ability to transmit different signals from
> each antenna so that the interference patterns from the different signals
> result in different readable data depending on where the receiver is in
> relation to the access point is not a trivial thing.
>
> But it's one of the most valuable features in the spec.
>
> David Lang
>

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

Re: [Make-wifi-fast] [bufferbloat-fcc-discuss] arstechnica confirms tp-link router lockdown

[David Lang]

On Sun, 13 Mar 2016, Adrian Chadd wrote:

> You do that in hardware. Do the Mac, phy and RF in hardware.
>
> This is what the qca hardware does.

unfortunantly, that's not what the existing chipsets do.

So unless you can create a new chipset, you can't just change what's done in 
hardware.

David Lang

> a
> On Mar 13, 2016 5:25 PM, "David Lang" <david@lang.hm> wrote:
>
>> On Sat, 12 Mar 2016, Adrian Chadd wrote:
>>
>> On 12 March 2016 at 11:14, Henning Rogge <hrogge@gmail.com> wrote:
>>>
>>>> On Sat, Mar 12, 2016 at 3:32 PM, Wayne Workman
>>>> <wayne.workman2012@gmail.com> wrote:
>>>>
>>>>> I understand that Broadcom was paid to develop the Pi, a totally free
>>>>> board.
>>>>>
>>>>> And they already make wireless chipsets.
>>>>>
>>>>
>>>> The question is how easy would it be to build a modern 802.11ac
>>>> halfmac chip... the amount of work these chips do (especially with 3*3
>>>> or 4*4 MIMO) is not trivial.
>>>>
>>>
>>> It's not that scary - most of the latency sensitive things are:
>>>
>>> * channel change - eg background scans
>>> * calibration related things - but most slow calibration could be done
>>> via firmware commands, like the intel chips do!
>>> * transmit a-mpdu / retransmit
>>> * transmit rate control adaptation
>>> * receiving / block-ack things - which is mostly done in hardware anyway
>>> * likely some power save transition-y things too
>>>
>>
>> you are ignoring MU-MIMO, the ability to transmit different signals from
>> each antenna so that the interference patterns from the different signals
>> result in different readable data depending on where the receiver is in
>> relation to the access point is not a trivial thing.
>>
>> But it's one of the most valuable features in the spec.
>>
>> David Lang
>>
>

Re: [Make-wifi-fast] [bufferbloat-fcc-discuss] arstechnica confirms tp-link router lockdown

[Dave Taht]

On Sat, Mar 12, 2016 at 12:18 PM, Adrian Chadd <adrian@freebsd.org> wrote:
> On 12 March 2016 at 11:14, Henning Rogge <hrogge@gmail.com> wrote:
>> On Sat, Mar 12, 2016 at 3:32 PM, Wayne Workman
>> <wayne.workman2012@gmail.com> wrote:
>>> I understand that Broadcom was paid to develop the Pi, a totally free board.
>>>
>>> And they already make wireless chipsets.
>>
>> The question is how easy would it be to build a modern 802.11ac
>> halfmac chip... the amount of work these chips do (especially with 3*3
>> or 4*4 MIMO) is not trivial.
>
> It's not that scary - most of the latency sensitive things are:
>
> * channel change - eg background scans
> * calibration related things - but most slow calibration could be done
> via firmware commands, like the intel chips do!
> * transmit a-mpdu / retransmit
> * transmit rate control adaptation
> * receiving / block-ack things - which is mostly done in hardware anyway
> * likely some power save transition-y things too
>
> If you're doing STA mode, then you have more things to do - eg bgscans
> with active traffic, TDLS, P2P, etc.
> If you're doing hostap mode or heck, even mostly-dumb ibss mode -
> where there's no requirement for off-channel traffic - the firmware is
> mostly just a transmit/receive engine and some power save stuff.
>
> And honestly - know how many cycles a modern CPU has? If you don't
> care about hyper-optimising for power consumption (ie, you're not a
> phone), then I bet you could get away with ath9k model hardware. Those
> same lower end CPUs can do 200kpps on an ethernet NIC right now. The
> reordering and retransmit stuff could be handled in firmware, but
> that's about it - and again, only if you wanted to do it on some
> anenmic SoC or you cared about power.

It is not always "cycles" as context switch latency - which is often
mitigated (now) by having general purpose multi-core hardware
available, but still hard to get into the us range reliably enough.

That said, doing 802.11ac right requires a LOT of on-board DSP
processing, and the design of the first chips out the door pre-dated
the arrival of modern multi-cores.

I certainly think that everything we laid out to improve wifi in
make-wifi-fast is now doable on nearly all now-shipping processors and
on the ath9k - and work is  also proceeding on non-open-source
versions of the ideas in iwl and in the next gen ath10k based
products. Lots of discussion on the linux-wireless mailing list and
patches landing.

I do, very much, want to avoid the separate baseband processor that
inhabits most cell designs and retain the core smarts for wifi in
general purpose processors. Getting locked into a celluar patent and
binary blob model would be a bad thing.

>
> People keep talking about "oh god, these things do so much now" - but
> that's because people are thinking about phones or those L2-cache-less
> anemic older SOCs that are massively memory bandwidth constrained.
> Newer stuff is much less terrible.

The ath9k has a long life in it yet, particularly at 2.4ghz, agreed.
Yet, I look at the new pi, and see a broadcom chip and driver that
could be improved much. I see dozens of other wifi chips that could
use more software and design effort, and more coming down the pike.

And I gotta admit that 802.11ac, even in it's current state, is now
superior to 802.11n in nearly every way, except for the shoddy state
of the usually binary-only firmware. Which has got a lot better over
the past year.

I can see - just as it happened to modems - more soft-mac-is wifi
chips arriving like the mt72 - or approaches that load the entire
stack on an ethernet-like interface. What I don't see is enough
students and engineers with sufficient background in how wifi really
works available to handle the billions of devices yet to be shipped.
I'd like to attach a knowledge vacuum to your brain, adrian, for
example....

One of the things obscured by the "whole router lockdown" debate here
is that the binary blob problem is most acute on the next-gen 802.11ac
chips (well, also acute on the video drivers). Anybody using those
blobs can certainly not lock down the entire router, and ship a blob
for the wifi. Which is historically what has always happened here -
the ath9k being the sole exception. Blobs are a PITA in themselves.

At one positive note, I think usb-wifi interfaces are going to go the
way of the dodo, and be replaced almost entirely by on-board
interfaces, for which I hope for a blob-free outcome on at least one
design.

>
>
>
> -adrian
> _______________________________________________
> bufferbloat-fcc-discuss mailing list
> bufferbloat-fcc-discuss@lists.redbarn.org
> http://lists.redbarn.org/mailman/listinfo/bufferbloat-fcc-discuss

Re: [Make-wifi-fast] [bufferbloat-fcc-discuss] arstechnica confirms tp-link router lockdown

[David Lang]

On Sat, 12 Mar 2016, Wayne Workman wrote:

> I understand that Broadcom was paid to develop the Pi, a totally free board.

No, Broadcom created a video processor with an embedded ARM cpu. An engineer who 
works at Broadcom got permission to create a board based on this chip outside of 
Broadcom on his own time. This board was the original Pi.

Broadcom does not develop the Pi or special chips for the Pi. The Pi designers 
watch what Broadcom makes available and makes use of those chips in their 
designs.

David Lang