Re: [Cerowrt-devel] [bufferbloat-fcc-discuss] arstechnica confirms tp-link router lockdown
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 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" wrote: >> >> On 12 March 2016 at 11:14, Henning Rogge wrote: >> > On Sat, Mar 12, 2016 at 3:32 PM, Wayne Workman >> > 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-disc...@lists.redbarn.org > http://lists.redbarn.org/mailman/listinfo/bufferbloat-fcc-discuss > ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] [bufferbloat-fcc-discuss] arstechnica confirms tp-link router lockdown
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 ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] [bufferbloat-fcc-discuss] arstechnica confirms tp-link router lockdown
On Sat, 12 Mar 2016, Adrian Chadd wrote: On 12 March 2016 at 11:14, Henning Rogge wrote: On Sat, Mar 12, 2016 at 3:32 PM, Wayne Workman 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 ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] [bufferbloat-fcc-discuss] arstechnica confirms tp-link router lockdown
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 ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] [bufferbloat-fcc-discuss] arstechnica confirms tp-link router lockdown
On Sat, Mar 12, 2016 at 12:18 PM, Adrian Chadd wrote: > On 12 March 2016 at 11:14, Henning Rogge wrote: >> On Sat, Mar 12, 2016 at 3:32 PM, Wayne Workman >> 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-disc...@lists.redbarn.org > http://lists.redbarn.org/mailman/listinfo/bufferbloat-fcc-discuss ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] [bufferbloat-fcc-discuss] arstechnica confirms tp-link router lockdown
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 ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] [bufferbloat-fcc-discuss] arstechnica confirms tp-link router lockdown
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" wrote: On Sat, 12 Mar 2016, Adrian Chadd wrote: On 12 March 2016 at 11:14, Henning Rogge wrote: On Sat, Mar 12, 2016 at 3:32 PM, Wayne Workman 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 ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] [bufferbloat-fcc-discuss] arstechnica confirms tp-link router lockdown
On Sat, Mar 12, 2016 at 3:32 PM, Wayne Workman 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 ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
