The EFF's open wireless router project [LWN.net]

The EFF's open wireless router project

Posted Jul 21, 2014 19:01 UTC (Mon) by mtaht (guest, #11087)
In reply to: The EFF's open wireless router project by proski
Parent article: The EFF's open wireless router project

Actually, ISC & comcast had got secure updates done last year, the work was deemed not good enough (with good reasons) by the openwrt folk and another solution is in progress. I do not know what the EFF is actually pursuing on this front.

The core thing openwireless.org needed from CeroWrt was the ability easily and transparently share bandwidth (beating "bufferbloat"), and with two tweaks to the SQM code in CeroWrt, they were *there*, not only do they provide a better experience for the main users, but also for the guests.

http://snapon.lab.bufferbloat.net/~cero2/jimreisert/resul...

They did their new gui against the sqm backend (which works on most linuxes, not just openwrt and cerowrt)

http://www.bufferbloat.net/projects/cerowrt/wiki/Setting_...

As soon as some form of stable, mainlined, secure update for openwrt lands, it'll be in cerowrt.

PS I have had very little to do with openwireless.org's effort besides the SQM implementation. CeroWrt is open source, after all, anybody can use it for any purpose. Hopefully they will find security concious devs (I freely admit security ranks about 5th on my priority list) and push back improvements to cerowrt and openwrt overall to make the whole world safer, and share better.

to post comments

The EFF's open wireless router project

Posted Jul 21, 2014 19:54 UTC (Mon) by fb (guest, #53265) [Link] (28 responses)

The webpage for cerowrt is not loading... Could you explain how it relates and compare to OpenWrt?
(I do occasionally fix OpenWrt package Makefile's and get the patches merged, so I guess I qualify as a power user)

The EFF's open wireless router project

Posted Jul 21, 2014 20:26 UTC (Mon) by mathstuf (subscriber, #69389) [Link] (27 responses)

CeroWrt is a fork of OpenWrt used as a testbed for bufferbloat research and code. It also only runs on a subset of models.

The EFF's open wireless router project

Posted Jul 21, 2014 20:44 UTC (Mon) by mtaht (guest, #11087) [Link] (26 responses)

Website is up for me...

I prefer to think of cerowrt as a branch, not a fork. Nearly everything in it was pushed up to openwrt a long time ago, and a great deal of the ipv6 work we helped drive in mainline openwrt, and test in cerowrt, in conjuction with the ietf "homenet" working group. http://tools.ietf.org/wg/homenet/ which is trying to set standards for ipv6 enabled home routers. Notably openwrt and cerowrt now work great with comcast ipv6, and see RFC6092, and various other supporting documents for making home cpe and routers "just work" with ipv6.

CeroWrt's current differences from openwrt are:

*extensively* tested on the one platform supported. Only 1 bug (#442) holding up a stable release.

SSL used by default in the gui
cerowrt routes, rather than bridges, everything. This is due to needing to be able to analyze ethernet, 2.4ghz, and 5ghz wifi traces independently. Out of that fell the extensive routing protocol support... the default routing protocol is babel (which is not in openwireless.org, sadly).
Mesh networking and wireless are enabled by default
ssh is enabled by default (no telnet)
some services are protected by xinetd
Whole bunch of test tools by default
it uses a unique device naming scheme to simplify firewall rules

Some out of tree patches: better random number generation, a whole bunch of test qdiscs such as nfq_codel and pie, the sqm system is too complex for baseline openwrt (which lacks the "ip" utility), and probably 10-20 patches more that I forget.

http://cero2.bufferbloat.net/cerowrt/ outlines the goals of the cerowrt project, which have largely been met. We are still in search of a replacement platform for the wndr3800s,and next up, is making wifi fast, again.

The EFF's open wireless router project

Posted Jul 21, 2014 20:50 UTC (Mon) by mtaht (guest, #11087) [Link]

Also, openwrt, homewrt, cerowrt, and hopefully now openwireless.org are now largely compliant with:

http://tools.ietf.org/html/draft-ietf-homenet-arch-17

The EFF's open wireless router project

Posted Jul 21, 2014 22:23 UTC (Mon) by luto (subscriber, #39314) [Link] (24 responses)

If you want to pick a fairly capable next target platform, the TP-Link Archer C7 v2 seems to be hard to beat. It has an ath9k 3-stream 2.4 GHz radio, an ath10k 3-stream 5GHz radio, and 16MB of flash. It even has two real on-board Ethernet NICs. As of a few days ago, openwrt trunk's hardware support seems to be very complete.

The EFF's open wireless router project

Posted Jul 22, 2014 9:49 UTC (Tue) by arnd (subscriber, #8866) [Link] (23 responses)

It's not a big upgrade though: the main difference is the addition of 802.11ac compared to the wndr3800, and also a slightly faster CPU (MIPS 74Kc instead of the MIPS 24K).

The following generation (e.g. Netgear R6250 and presumably TP-Link Archer C8 that is about to come out) instead come with much larger storage (128MB NAND instead of 16MB NOR flash) and multi-core ARM processors (Cortex-A9/A17, PJ4 or Krait). OpenWRT support at this time is still a bit lacking, but I guess it's better to wait a bit before moving away from the wndr3800.

The EFF's open wireless router project

Posted Jul 22, 2014 11:48 UTC (Tue) by fb (guest, #53265) [Link] (22 responses)

@luto and @arnd thanks a lot for your comments on candidates next-gen reference routers. Appreciated.

TP-Link Archer C7 support looks solid (the current bug on 5Ghz notwithstanding). Although I agree that for those not in a hurry it might be worth waiting.

I went to look at Netgear's R6250 wiki pages at openwrt.org. The most recent svn commit linked from there is 12 months old...

I guess we're all searching for a replacement platform for the wndr3700/3800 family.

The EFF's open wireless router project

Posted Jul 22, 2014 12:37 UTC (Tue) by arnd (subscriber, #8866) [Link] (8 responses)

The platform support for r6250 (bcm4708 aka bcm53xx aka northstar) is indeed progressing a bit slowly, it has been mostly a one-man effort. Since May 2014 however, there is a linux-3.14 kernel for it in OpenWRT, and the developer (Hauke Mehrtens) is working with upstream (that includes me). Also, Broadcom have recently hired Jon Mason to help out with upstream support for this platform and others, so this is still very promising. The chip is used in a lot of products but r6250 is currently the only one with OpenWRT support, since that is what Hauke has. See also http://bit.ly/1nQpdoQ [wikidevi].

The qca9558 used in most of the alternatives today is the successor to the ar7161 used in the wndr3800 and is well supported in OpenWRT, but as far as I can tell is a bit behind other MIPS and ARM based ports upstream.

Qualcomm/Atheros have also announced a new high-end product line based on the Snapdragon SoCs that is likely to outperform bcm4708 and is completely unrelated to qca9558. These are called IPQ8062/IPQ8064 and already have some upstream kernel support, but I'm not aware of any products on the market so far. I'm guessing this one will be in the Archer C8.

Linksys WRT1900AC is also worth mentioning, this one is based on the Marvell Armada XP chip, which has excellent upstream kernel support and nice hardware specs, but the router very expensive and has had a rough start because of the lack of an open source wifi driver (I believe that is resolved now). It has only recently gained OpenWRT support.

The EFF's open wireless router project

Posted Jul 22, 2014 18:53 UTC (Tue) by mtaht (guest, #11087) [Link] (6 responses)

The most major requirement of the CeroWrt project is zero binary blobs. We are here to strip the bufferbloat out of everything, and a binary blob firmware for wifi, in particular, is unacceptable, as that is precisely the area of the internet we are trying to fix.

The ath10k at least, has firmware that can be obtained and may be open sourced one day, so we have some hope for that. I have been playing with the archer c7 v2 in particular - but the cpu is kind of weak. I have fiddled with a couple arm based products and am somewhat encouraged, but the ethernet interfaces are behind blobs we cant fix and exhibit bufferbloat....

The ath9k is more or less the "reference standard" for open linux wireless drivers, and that will probably become the focus of the upcoming make-wifi-fast effort. (and it's the other card in the archer c7v2)

Now, if another chipset with entirely open drivers and firmware arrives, we'd take it under consideration. Does that broadcom have binary blobs in the ethernet or wifi drivers?

The EFF's open wireless router project

Posted Jul 22, 2014 18:57 UTC (Tue) by luto (subscriber, #39314) [Link]

It might be worth contacting the Candela people if you're really interested in ath10k. They have firmware source.

But yes, blobless is clearly preferable.

The EFF's open wireless router project

Posted Jul 22, 2014 19:20 UTC (Tue) by johill (subscriber, #25196) [Link] (1 responses)

Intel, Broadcom, and others have binary blobs for wifi firmware, but if you're looking for bufferbloat only you have to ask yourself what that firmware can do. Intel's and Broadcom's don't really buffer frames - if they're on the HW queue they're going out to the air ASAP.

The EFF's open wireless router project

Posted Jul 22, 2014 22:02 UTC (Tue) by dlang (guest, #313) [Link]

The problem is that in many cases the firmware implements very large buggers, so you can't assume that you can ignore the firmware.

The firmware that has been opened shows this to be the case repeatedly, so there's no reason to believe that the closed firmware is going to be better.

The EFF's open wireless router project

Posted Jul 22, 2014 20:14 UTC (Tue) by arnd (subscriber, #8866) [Link] (2 responses)

This is what I know about the ARM based platforms with 802.11ac support:

Marvell armada-xp (WRT1900AC):
* CPU is dual-core Marvell PJ4 (ARMv7)
* Ethernet driver is drivers/net/ethernet/marvell/mvneta.c, I see no hint of blobs in there.
* wireless driver is not known yet, probably a variation of drivers/net/wireless/mwifiex, which comes with a blob, see also https://forum.openwrt.org/viewtopic.php?pid=240734

Atheros ipq8064 (Archer C8?):
* CPU is dual-core Qualcomm Krait-300 (ARMv7)
* Ethernet driver is likely to be drivers/net/ethernet/atheros/atl1c/ (no blobs that I can see)
* Wireless is almost certainly ath10k

Broadcom bcm4708 (R6250 and others):
* CPU is dual-core ARM Cortex-A9 (ARMv7)
* Ethernet driver is drivers/net/ethernet/broadcom/bgmac.c (no blobs)
* wireless driver is drivers/net/wireless/b43 (with blobs)

The EFF's open wireless router project

Posted Jul 23, 2014 15:35 UTC (Wed) by arnd (subscriber, #8866) [Link]

FWIW, I've looked at the firmware image for Archer C8: It's bcm4709 (same chip as bcm4708, but running 1 GHz) with 16MB flash, so probably not worth waiting for, because there are lots of other models out already with that chip and more flash.

For the Marvel wlan driver, the model is 88w8864 and it's related to earlier ones for which some reverse-engineering has been done in the past. The wifi firmware now runs on a Cortex-A9, which is probably faster than a lot of router SoCs.

The EFF's open wireless router project

Posted Jul 23, 2014 15:41 UTC (Wed) by nbd (subscriber, #14393) [Link]

You won't be able to use b43 on any Broadcom wifi chip that even remotely counts as recent.

As for the Marvell wifi, it's probably possible to add support for the chip to mwl8k (not mwifiex). I don't know if anybody is going to do that though.
The chip doesn't seem to be used in a lot of devices, and all the interesting bits are of course hidden away in a crappy firmware blob.

The EFF's open wireless router project

Posted Jul 24, 2014 19:30 UTC (Thu) by fb (guest, #53265) [Link]

Hi arnd, I need to thank you again for the multiple informative posts on newer ARM based platforms that are getting used for routers and for your comments on their software support. Thank you! Very sincerely appreciated!

The EFF's open wireless router project

Posted Jul 22, 2014 12:59 UTC (Tue) by mathstuf (subscriber, #69389) [Link] (12 responses)

> I guess we're all searching for a replacement platform for the wndr3700/3800 family.

Is there any specific reason why?

The EFF's open wireless router project

Posted Jul 22, 2014 13:10 UTC (Tue) by arnd (subscriber, #8866) [Link]

It's becoming rather hard to buy new, and newer models are cheaper and/or more capable.

The EFF's open wireless router project

Posted Jul 22, 2014 14:37 UTC (Tue) by fb (guest, #53265) [Link] (10 responses)

If the question was why those models specifically: those were (in practice) reference models, they were stable and worked extremely well.

If the question was about replacing them: at least in Europe is has been very hard to buy either of these from 'regular/normal' re-sellers for a while already.

Notice that the newer revisions/versions of wndr3800 use a different chipset and are unsupported.

wndr3800

Posted Jul 22, 2014 14:51 UTC (Tue) by corbet (editor, #1) [Link] (9 responses)

So wait...are you saying that if people run out to buy WNDR3800 devices to play with this software they are going to end up with a doorstop? If so, that seems like something to scream from the rooftops, not to bury in a comment stream...?

wndr3800

Posted Jul 22, 2014 15:25 UTC (Tue) by fb (guest, #53265) [Link] (2 responses)

The market is well aware of this, last time I looked around (6 months ago? Probably more), I could find new WNDR3800 but it surely commanded a very steep price. Today a cursory (Amazon) search did not show anyone selling it.

wndr3800

Posted Jul 22, 2014 15:27 UTC (Tue) by fb (guest, #53265) [Link]

PS: Where I wrote Amazon, you folks should read Amazon.FR :-P

wndr3800

Posted Jul 22, 2014 15:33 UTC (Tue) by corbet (editor, #1) [Link]

Um, a quick search on US Amazon turns up this offering. I would not be at all surprised if some people were buying this to try to put openwireless on it. That is not going to lead to happy testers...

wndr3800

Posted Jul 22, 2014 15:31 UTC (Tue) by arnd (subscriber, #8866) [Link] (5 responses)

I think fb was confusing wndr3700 and wndr3800 in the comment above: wndr3800 and wndr3700v1/v2 are the same hardware with different amounts of memory. They are supported by CeroWRT but are no longer produced as far as I can tell. The recommendation is to buy wndr3800 because you know exactly what you get then -- there is only one version of this device.

For wndr3700, there are also v3 and v4 versions. v4 is actually much nicer hardware (same as wndr4300) than v2, is available for a reasonable price and has some OpenWRT support in the latest snapshots but doesn't work with CeroWRT because it requires a separate image.

The main disadvantage of all of the supported systems is that they are two-generation old high-end devices: a new mid-range router (e.g. TL-WDR3600) can do the same things for less, while a new 802.11ac router (e.g. Archer C7) would be better for a similar price.

wndr3800

Posted Jul 22, 2014 19:23 UTC (Tue) by mtaht (guest, #11087) [Link] (3 responses)

The wndr3800 was used by cerowrt, samknows & FCC, the bismark project, and innumerable other science and measurement projects. It had a very high build quality, had enough flash for tools, and sufficient ram as well, along with a huge development community centered around the chipset that didn't exist (at the time) for (examples) the iwl products or ra or broadcom products. It has been nearly unbrickable, and I'm glad we chose it 3 years back...

but... I have been painfully aware of how rare the wndr3800s for the past year. However, the ar71xx/ath9k chipset that the wndr3800 is based on is used by *100s* of other manufacturers products (buffalo, tp-link, ubnt, etc), and the successor chipsets from atheros are largely similar, so... there are 100s more products to choose from with very few changes to the build, if we were to switch to something being currently manufactured.

(I fairly regularly do builds for the ubnt picostation and nanostation, as well as for a few other more current and widely available products... but haven't found one - or enough support from the manufacturer. Secondly, many of the "newer chipsets", contained cost reductions that bothered me, for example clock speeds were reduced by 10-20% in later chipsets). I wanted to hit new performance targets, not get slower...

And we'd (cerowrt) like to have a new platform to deploy for 3+ years, so we can get good data back, and that's kind of hard to figure out at the moment as the industry switches over to 802.11ac and the resulting chaos in the chipsets and raw quality of the code - (this disruption is also a good thing, in that things like "streamboost" are entering that market, we have a chance to influence future designs, etc)

Frankly, given all the help Netgear has been (e.g. none), I'm planning on finding another board from another vendor, rather than fix their stuff anymore. I have some hope we'll work with multiple other projects including openwireless.org and others in this space (very long list), to choose a chipset and vendor that we can work with, to further the advancement of the internet... but every project has different goals, and our (bufferbloat.net's) insistence on no binary blobs is not something that other projects might care about, in particular. (have no idea what the EFF stance is on this issue, for example.)

The 3 years of work in openwrt/cerowrt/etc has led to a home router build that works really well with ipv6, and I do hope tons of people iron out the last bugs in barrier breaker - on any of the 100s of platforms available - to take full advantage of ipv6 as it rolls out.

http://corporate.comcast.com/comcast-voices/comcast-reach...

binary blobs

Posted Jul 22, 2014 21:51 UTC (Tue) by jsha (guest, #97989) [Link]

> insistence on no binary blobs is not something that other projects might care about, in particular. (have no idea what the EFF stance is on this issue, for example.)

I work for EFF, and I can say: We definitely also insist on a platform with no binary blobs. It's vital to both security and user freedom, and is part of the reason we chose CeroWRT and the WNDR3800 as our base platform.

wndr3800

Posted Jul 22, 2014 22:04 UTC (Tue) by dlang (guest, #313) [Link]

> Secondly, many of the "newer chipsets", contained cost reductions that bothered me, for example clock speeds were reduced by 10-20% in later chipsets). I wanted to hit new performance targets, not get slower...

especially given the fact that the current CPU is running into performance bottlenecks on high-speed home connections today.

wndr3800

Posted Jul 22, 2014 22:19 UTC (Tue) by arnd (subscriber, #8866) [Link]

I've bought the wndr3800 myself two years ago because of CeroWRT support and have been fairly happy with it, except that I'd prefer an ARM CPU core since that's what I work on in the kernel ;-)

My prediction is that over the next three years, most of the high-end routers will move to ARM CPU cores, now that five of the main SoC vendors in this area (Qualcomm, Mediatek, Broadcom, Marvell and Realtek, no idea about lantiq or others) all have either products out or announced licenses for CPU cores. The highly integrated low-end will stay with MIPS24K/74K but not move on to faster MIPS cores (Aptiv/Warrior).

This means you basically have the choice between the qca9558 or similar as the last of its kind with high compatibility to wndr3800 on the one side, or a completely new platform like the ipq8064 that uses the same network drivers but shares nothing else on the other side.

wndr3800

Posted Jul 22, 2014 19:27 UTC (Tue) by fb (guest, #53265) [Link]

> I think fb was confusing wndr3700 and wndr3800 in the comment above

Indeed. Thanks for noticing and bringing it up.

The EFF's open wireless router project

Posted Jul 23, 2014 3:27 UTC (Wed) by ranga (guest, #97993) [Link]

Support for secure upgrade of the entire firmware image is in the current EFF router software release. This security is against a threat model that will be described in the threat model document on the OpenWireless github repo (TODO).

The need to upgrade the entire image is a problem for people who customize the router by installing their own pkgs. Since we use the sysupgrade utility built into OpenWRT, such users will need to re-install their packages manually. So even if we wanted to just upgrade the linux kernel we would have to make available a full new image. Similar comment applies to upgrading a specific pkg currently if it is to be done by the EFF through the current automated update mechanism. Users are of course free to manually upgrade specific pkgs themselves with "opkg upgrade pkg1 pkg2 ...".

We would like to move to a system where kernel or individual packages are automatically upgraded. We don't currently have a design for this and will review the current activity in OpenWRT mentioned by Dave above and try to arrive at a solution down the road. Resolving this problem is not a high priority item for us currently.

More concerning is the possibility of routers getting "bricked" during an upgrade. We will be adding the ability to gather "bricking rate" to see whether the current upgrade mechanism is something we can live with. Ideally we would be able to have two copies of the image, with one being live and would only upgrade the backup copy. Then if an upgrade fails we would always be able to boot up into the functioning copy etc. Given the flash of 16MB on the Netgear 3800 we can't implement this yet. In a more modern platform we expect this will be possible.

Dave describes the relationship between the EFF router software release and CeroWRT well. We are focused on innovating in the security of SOHO routers and in making the sharing of the WiFi with guests worry free and easier, and in protecting the privacy of guests themselves. We look to CeroWRT to continue its innovation in the networking and queuing realms and to continue to improve performance and internet experience. Such a division of labor, we hope will result in a healthy exchange of code and ideas between the two projects.