The EFF launches a router project [LWN.net]

By Jonathan Corbet
July 29, 2014

The Electronic Frontier Foundation is probably best known for its work in the political arena. But the EFF also occasionally tries to make change happen more directly by releasing interesting technologies of its own. The organization's July 20 announcement of the Open Wireless Router project is an example of this type of initiative. Your editor has long been concerned about the state of home (and small business) router software, so it made sense to take a look. What was revealed is a project with some interesting potential — but that potential may take more resources than are currently available to realize.

There are many reasons to want better router software, including improved functionality, performance, security, and more. While the EFF is working toward those goals, the primary impetus behind the Open Wireless Router is something different: to support the Open Wireless Movement. The idea behind Open Wireless is that if we all set aside a portion of the bandwidth on our wireless networks for anybody who might happen by, the world as a whole will be a better place. The Open Wireless Router project intends to make it both easy and safe for people to do exactly that.

By its own admission, this project is in an early stage of development at this point. It only works on one hardware platform, the Netgear WNDR3800 router. The WNDR3800 is beginning to show its age, but it is a relatively open device that is easy to experiment with. The stock Netgear firmware makes it easy to flash a replacement, so installing the Open Wireless software on this device is really just a matter of downloading the image and feeding it to the right administrative page. Once the router reboots, it advertises a wireless network called "Setup Open Wireless" where a minimal amount of configuration can be performed. After that, the router is up and running.

The router is set up to offer two wireless networks to the world. One is the private network set up during the configuration phase. The other, which is set up with openwireless.org as its SSID, is unencrypted and available to anybody who wants to use it. The default setup has the private net on the 5GHz radio, while openwireless.org lives in the 2.4GHz band.

There is a web-based administrative interface to the router, but it really only has two pages. One of them is the "dashboard," giving an overview of the status of the router and how much bandwidth is being used by each of the two wireless networks. The ping time to eff.org is maintained there for users who are concerned about how quickly they can get back to the mothership (or, more seriously, whether they have connectivity to the Internet at all). This screen also has a toggle that may be used to turn the openwireless.org network on or off.

The second screen enables minimal tweaking of the router's settings. The basic parameters for both networks can be changed (though openwireless.org cannot be renamed). This screen can be used to upload an SSH public key to the router; after that, it is possible to use SSH to log into the router with the corresponding private key. Once the key has been set and used, it cannot be changed again via the web interface.

The settings screen demonstrates the attention that has been paid to the open wireless objective. The administrator can configure how much of the network's total bandwidth can be used by open wireless users; there is also a monthly bandwidth cap that can be applied (though that feature does not appear to work yet). The idea, once again, is to make it easy to offer an open network without compromising the functionality or the security of the private network.

Given the priority that supporting open access wireless seems to have, it is somewhat ironic that the openwireless.org network does not actually work in the initial release of the router software. It seems that the firewall rules are not correct, preventing DHCP requests from making it to the daemon on the router. The problem is fixed easily enough, but it is somewhat discouraging that this project shipped its initial version with the headline feature not working properly. It gives the impression that the release was put out in a hurry, an impression which is reinforced by rough edges elsewhere in the distribution.

Beyond open access, this project has goals that include bufferbloat avoidance, a minimal and secure configuration interface, and to improve the state of home router security. The first of those goals has mostly been met by basing the Open Wireless Router distribution on CeroWrt, an OpenWrt derivative designed to support work on bufferbloat issues. With regard to the second goal, the interface is certainly minimal. The fact that an administrative login over HTTP never times out suggests that the security side of the equation has not yet been fully thought out. But one has to start somewhere.

What about security in general? CeroWrt has done a little work in this area, but a fundamental problem remains unsolved: there is no mechanism for distributing security updates to these routers. In most configurations, the only practical way to apply an update is to reflash the entire firmware image. So these devices, once installed, tend to be deployed for years and forgotten about; there must be no end of outdated and vulnerable software running on small routers all over the world. The EFF is right to want to address this problem; in the long run, it may turn out to be one of the biggest security problems for the net as a whole.

For now, it does not appear that much has happened in this area, though. The dashboard page does have an indication of when the last check for software updates was done. Evidently the router can perform a full-image upgrade when an update is made available; that is useful for users who have not customized anything, but will be painful for those who have installed their own packages. If there is any mechanism for verifying the provenance and integrity of an update image, though, it is not mentioned anywhere. (As of this writing, a bug-fix update is planned for around August 1). There is also no way in the administrative screens for the user to install a new firmware image of their own choosing; hopefully this feature will be provided in the near future.

Fixing the home router security problem is a laudable goal. Creating a more friendly administrative interface to OpenWrt-based (or CeroWrt-based) devices is also a worthwhile effort; these distributions can be somewhat intimidating to those who don't want to learn about how routers work in great detail. One can only wish the EFF luck as it works toward achieving these goals. A certain amount of luck would appear to be needed; the goals are ambitious, while the development community, at this point, seems to be tiny. The commit stream shows few developers actively working on the project at this point.

In other words, there is a reason why the EFF's announcement was titled "Calling all hackers." There is a clear desire to attract a development community to help push this project forward. By putting the focus on interface and security development while basing its work on a solid technical foundation provided by others, the EFF might have hit on a winning strategy. This is an important area that has been somewhat neglected to date; a handful of dedicated developers working on these problems could make a real difference.

In the short term, the Open Wireless Router distribution is not quite ready for mainstream use, even for those who own the requisite hardware. But it is not that far away from that point. Many users simply want to connect their router to their Internet link and have a functioning wireless net; the Open Wireless Router makes that quite easy to do. Those who want to dig in further will need to learn command-line administration, a skill that makes the full capabilities of a CeroWrt-based system available to them. All told, the Open Wireless Router could easily evolve into a useful tool that could greatly increase the reach, performance, and security of the open network.

Index entries for this article
Security	Home network
Security	Internet/Routers

to post comments

The EFF launches a router project

Posted Jul 29, 2014 16:35 UTC (Tue) by eean (subscriber, #50420) [Link] (2 responses)

I start losing 5GHz signal within my apartment. I can understand their decision for the defaults but I'm not sure it works well in practice.

The EFF launches a router project

Posted Jul 29, 2014 17:27 UTC (Tue) by mathstuf (subscriber, #69389) [Link]

I have a WNDR3800 and I have it set up to have a guest and private network on both 2.4GHz and 5GHz, so that is another possible solution. Unfortunately, devices tend to not support connecting to both frequencies at the same time (and there's no way to distinguish the 5GHz band from the 2.4GHz band in the Android UI either without different SSIDs).

The EFF launches a router project

Posted Jul 29, 2014 17:47 UTC (Tue) by dlang (guest, #313) [Link]

In many places the 2.4GHz band is close to useless because of so many APs deployed in an area (and deployed badly at that)

It would probably have been better to have both private and guest networks on each band, but that would have been a bit more complex to setup.

The EFF launches a router project

Posted Jul 29, 2014 17:45 UTC (Tue) by dlang (guest, #313) [Link] (11 responses)

re: upgrade issues

The big problem is that the 3800 just doesn't have that much flash available.

As a result, like many other OpenWRT devices, you end up needing to use a read-only compressed filesystem to hold the OS software. This gets coupled with an overlay of a read-write filesystem, but the compression is poor (or non-existant) on this overlay. The difference in image size between using the read-only compressed image vs the read-write image can be about 10x

This means that when you install a update to a package that was in the base OS, you don't free the space the original took up, and the new version takes a lot more space than the old one did.

As a result, you can't start with the highly compressed image and update it.

New devices are shipping with much more flash, so this may end up changing and OpenWRT will need to adapt it's scripts and packages to deal with the upgrade in place process better, but support for these new devices has been lagging (in part because the new devices show bad flash sectors to the OS, so the filesystem needs to be able to deal with them and with the possibility of loosing eraseblocks as they are written), but it is starting to show up now.

The EFF launches a router project

Posted Jul 29, 2014 18:41 UTC (Tue) by hechacker1 (guest, #82466) [Link]

I have the 3800 with Cerowrt, and it's running the jffs2 version. It does have free space and can be provided updates. However, I don't know how much the extra EFF features take up. It has enough RAM for tmpfs to hold the next firmware image to install, and it can save settings in between installs. There's just a few bugs they are still working out.

I think the bigger problem is that cerowrt is fairly fast in releasing point patches, with the latest linux kernel, and so patch levels aren't necessarily compatible. EFF should probably freeze on a version of cerowrt and stick with it for a while, but I bet they cannot yet due to outstanding bugs in cerowrt and openwrt.

And most of the work cerowrt is already upstreamed to openwrt as well.

The EFF launches a router project

Posted Jul 29, 2014 19:15 UTC (Tue) by arnd (subscriber, #8866) [Link] (9 responses)

It seems surprisingly hard to find a good device with more than 16MB flash. Its successor WNDR3700v4 (aka WNDR4300) has 128MB NAND flash and could lift that barrier, but almost everything else that has a lot of flash also requires proprietary firmware blobs for the wireless drivers.

As I commented last week, it seems worthwhile to wait for the next generation of routers that also has dual-core ARM processors instead of single-core MIPS. OpenWRT currently has initial support for Marvell ArmadaXP and Broadcom bcm4708, but they have the same problem with wireless drivers and are not yet stable enough for a project like CeroWRT.
The new Atheros IPQ8064 (derived from Snapdragon S4 Pro) should show up in devices (Netgear R7500?) at some point this year, and that has a slightly better chance of getting free firmware, as mtaht mentioned.

The EFF launches a router project

Posted Jul 29, 2014 21:08 UTC (Tue) by dlang (guest, #313) [Link] (8 responses)

The problem with the WNDR3700v4 (and 4300 which is almost the same board) is that the flash is NAND, which requires badblock support.

That support was not available until a few months ago, and I think I saw a patch tweaking support for these models within the last week, so they are very recent entreats as far as OpenWRT is concerned.

As a like-for-like replacement of the 3800 it wouldn't be bad.

But if we are going to move CeroWRT to a new platform, it would be very nice to get something with a faster CPU because the bandwidth available to home users (in some areas) is increasing, and many of those people are the ones who would be most interested in addressing these sorts of problems

Depending on configuration and traffic, the 3800 can run out of CPU somewhere in the 10-50Mb/s range when running CeroWRT.

The EFF launches a router project

Posted Jul 29, 2014 22:08 UTC (Tue) by arnd (subscriber, #8866) [Link] (7 responses)

WNDR3700v4 has a 74Kc CPU core, so it should be a bit faster than the 24Kc on the 3800, but it won't make a lot of difference in the end, even the QCA9558/MT7620A/BCM4706 as the current high end on MIPS SoCs are probably too limited.

IPQ8064 will have a much faster CPU but the I/O path is as crippled as before by lacking cache-coherent DMA over PCI. Armada XP (from WRT1900AC) should have much higher I/O throughput, but its PJ4B CPU cores are not as fast as the Krait cores used in IPQ8064.

In terms of raw CPU performance, I'd expect doubling speed with each step AR7161->QCA9558->BCM47081->MV78230->IPQ8064, but in practice you see less than that on network transfers because they will all spend a lot of time waiting for I/O to cross the bus.

The EFF launches a router project

Posted Jul 29, 2014 22:17 UTC (Tue) by dlang (guest, #313) [Link] (1 responses)

Well, since there is more processing being done with active queue management, the I/O thoughput isn't the limiting factor.

I've had testing done with the 3800 with a very stripped down kernel (down to disabling connection tracking and all firewalling because it wasn't needed for the application), and the number reported back was that it topped out at 300Mb/sec

The EFF launches a router project

Posted Jul 30, 2014 2:31 UTC (Wed) by mtaht (guest, #11087) [Link]

I need to point out there is nearly zero cpu impact of the new queue management stuff, be it aqm or fair queuing. There are even beneficial cache effects from keeping the queues shorter with BQL, also -

the real killer for cpu is the cost software rate limiting, which accounts for like 82% of the overhead before a box flatlines. (I confirm the peak forwarding rate for the wndr3800 appears to be about 330mbit/sec with no iptables rules using fq_codel on the ethernet device, and about 50mbit with software rate limiting)

I'd like to come up with a better rate limiter, and feel that hardware assistance is going to be needed with the current generation of arm router based products as well.

The EFF launches a router project

Posted Jul 30, 2014 2:26 UTC (Wed) by mtaht (guest, #11087) [Link] (4 responses)

my benchmarks show the perceived benefits of the mips 74k cpu to be mostly illusion. To get roughly 2x more performance on simplistic benchmarks, it has a much deeper instruction pipeline, but usually has the same cache sizes as prior chips. (32K/32K). So you have worse interrupt response time, and not enough cache to do more stuff, both of which are critical things needed in a router.

An advantage of the arm chips is they generally have a L2 cache that is worthwhile and shorter pipelines. And Intel did some great things with ivy bridge direct to cache dma interface and their DLPK system that I wish the lower end routers could duplicate...

Personally I'm in love with the parallella right now (if only the 16 core co processor was more of an I/O co-processor) and its dual A9 core AND FPGA.... got enough gates to do http://jvimal.github.io/senic/ and maybe fq_codel too...

The EFF launches a router project

Posted Jul 31, 2014 14:58 UTC (Thu) by jhhaller (guest, #56103) [Link] (3 responses)

The generic activity (but driven by ARM) comparable to the Intel DPDK effort is OpenDataPlane. It's not nearly as advanced as DPDK, but may be of interest to OpenWRT and downstream projects.

The EFF launches a router project

Posted Aug 1, 2014 4:21 UTC (Fri) by mtaht (guest, #11087) [Link] (2 responses)

cool, thanks, good to know! The kind of numbers that intel gets out of their SDK are *amazing* - and I wasn't aware that there was a similar effort on arm. The thing is, intel gets those numbers by having DMA direct to their very large caches, which arm chips generally lack.

I keep hoping someone writing hardware will make note of all the advancements in queue theory of late and make better ethernet chips (or, in arm's case, verilog or VHDL IP).

The EFF launches a router project

Posted Aug 1, 2014 12:27 UTC (Fri) by arnd (subscriber, #8866) [Link] (1 responses)

My understanding of DPDK and ODP is that they are mostly interested in running proprietary network stacks in user space, in order to implement features there that don't exist in the kernel, but at the same time completely bypassing the kernel and the features that exist in it. The fact that Intel and some others can do DMA into caches is independent of that and you can do that in both kernel and user space based network stacks.

Note that ODP by design requires cache-coherent DMA, which does not necessarily imply doing the DMA into the cache, but it does mean that it is not portable to the typical low-end SoCs you'd find in consumer routers as opposed to the devices that Cisco and Juniper are selling to enterprise customers.

The ArmadaXP chip (used in WRT1900AC) may be an exception to that, so ODP can run on that in theory, but then you still need to program your ODP based application to talk to Marvell's network hardware through ODP.

The EFF launches a router project

Posted Feb 15, 2016 13:13 UTC (Mon) by nysan (subscriber, #81015) [Link]

"My understanding of DPDK and ODP is that they are mostly interested in running proprietary network stacks in user space, in order to implement features there that don't exist in the kernel, but at the same time completely bypassing the kernel and the features that exist in it. The fact that Intel and some others can do DMA into caches is independent of that and you can do that in both kernel and user space based network stacks."

Have a look at openfastpath on ODP.
Linux is still used as controlplane with --enable-sp, ARP, RIPv2 et.c. is sent to the kernel stack.
Standard cmds "arp", "ip" et.c. are used to configure parts of the stack thats common between both.
Control plane stack state is mirrored via netlink for fast access by packet churning cores, i.e. ARP table, FIB et.c.

The EFF launches a router project

Posted Jul 29, 2014 17:56 UTC (Tue) by josh (subscriber, #17465) [Link] (3 responses)

As much as I'd love to provide bandwidth to anyone who comes by, doing so has much the same risks as running a Tor exit node: you risk being blamed for any resulting traffic. Doing so may also violate ISP policies.

Also, while the article doesn't say, I'd hope that the default policy is not "fixed percentage of available bandwidth" but rather "bandwidth that's not being used by the private network", with an optional (disabled by default) upper and lower bound.

The EFF launches a router project

Posted Jul 31, 2014 8:08 UTC (Thu) by ortalo (guest, #4654) [Link] (2 responses)

I second your comment and imho, that's not a simple risk but a true question: how do you comply to the (many) laws that oblige one to provide the police the necessary means to pursue their investigations (via logging, user registration, etc.)?

NB: Please, no comment only on the adequacy of these laws, that's not the question here (though I agree this is certainly the problem).

The EFF launches a router project

Posted Jul 31, 2014 19:01 UTC (Thu) by SiliconSlick (guest, #39955) [Link] (1 responses)

I bit perplexed about this as well. My Netgear WNDR3700v3 has a built-in option for wireless "Guest" networks, but I'm not about to enable it. Spammers and kiddie-porn peddlers are the first things that come to mind whenever I consider it. Who would put themselves in the situation where they could be held responsible for those miscreants' actions? I'm sure as hell not going to.

The EFF launches a router project

Posted Jul 31, 2014 23:16 UTC (Thu) by mathstuf (subscriber, #69389) [Link]

The guest network can also be under WPA2… Just post the password on a bulletin board or something.

The EFF launches a router project

Posted Jul 29, 2014 18:13 UTC (Tue) by mtaht (guest, #11087) [Link] (5 responses)

A few comments:

CeroWrt is approaching a stable release, now that openwrt is entering the barrier breaker freeze. Stuff under the covers includes good ipv6 with just about everything, (especially) including comcast, bufferbloat fixes using the sqm system, full upnp support, etc, etc.

The only truly major difference left between openwrt and cerowrt is that cero routes everything and has the sqm system for managing bufferbloat better: http://www.bufferbloat.net/projects/cerowrt/wiki/Setting_...

And hopefully that system will make it up to openwrt also. The EFF is using a derivative of SQM to manage their sharing setup.

on the security front, dnssec is enabled by default, and access to certain daemons (like ssh) is moderated by xinetd. bcp38 is supported for reducing address spoofing concerns, there's mesh networking, and I forget what else.

I do not mind at all the EFF ripping out some of that stuff to tackle their gui, security, and update goals! - because security and gui are way down on my todo list - and I will do my best to track their work in cerowrt.

But if you are interested in something that works more fully, now, with the luci gui on the same hardware, try cero.

Latest release is at:

http://snapon.lab.bufferbloat.net/~cero2/cerowrt/wndr/3.1...

Next up for cerowrt are make-wifi-fast, and integration with the new protocols being developed by the ietf "homenet" working group.

The EFF launches a router project

Posted Jul 30, 2014 17:34 UTC (Wed) by ms-tg (subscriber, #89231) [Link] (2 responses)

Thanks for posting this info.

Could anyone knowledgeable also comment on how the state of DD-WRT compares to these projects, by any chance?

The EFF launches a router project

Posted Jul 30, 2014 19:36 UTC (Wed) by dlang (guest, #313) [Link]

I only used dd-wrt a little bit, but it looked to me like the only thing that it may be suitable for was running an AP, while OpenWRT (and derivatives) are much more general.

configuration for dd-wrt was a registry of name-value pairs while Openwrt uses config files and scripts.

There is also a very large selection of packages available in Openwrt while dd-wrt is just a router.

The EFF launches a router project

Posted Aug 1, 2014 3:55 UTC (Fri) by mtaht (guest, #11087) [Link]

dd-wrt got fq_codel for it's QoS system a while back. It's uncertain if they grokked the need to up the target parameter for it at low bandwidths (basically the fq_codel target and interval should be increased to account for a MTU's worth of packets when used at low rates (below 3mbit), which is something we didn't figure out until some testing of the real world against the behavior of the ns2 model.

I like dd-wrt, but they tend to run a bit behind openwrt (for quite a few good reasons). I figure they will have the high level of ipv6 integration that openwrt now has soon, if not already.

The EFF launches a router project

Posted Jul 31, 2014 23:08 UTC (Thu) by NightMonkey (subscriber, #23051) [Link] (1 responses)

Any consideration for Tomato derivatives for this project? I'm really fond of Tomato by Shibby. http://tomato.groov.pl/

The EFF launches a router project

Posted Aug 1, 2014 3:57 UTC (Fri) by mtaht (guest, #11087) [Link]

I found the tomato community rather toxic to deal with.

http://tomatousb.org/forum/t-676664/trying-to-unravel-the...

What about hardware? (was: The EFF launches a router project)

Posted Jul 29, 2014 19:54 UTC (Tue) by fredrik (subscriber, #232) [Link] (6 responses)

Is there a plan to complement this software project with some hardware building project, presumably funded on Indiegogo or Kickstarter? I really look forward to buying a router that has community support down to the last piece of physical wire on the board.

It is only too common to see free software projects like this target (workable, somewhat old) hardware, which unfortunately is more or less abandonware. I understand the need to access hardware that has open specifications, or failing that, is old enough to have been reverse engineered. But I can't help but think that all that effort spent to reverse engineer, replace binary blobs, and work around undocumented hardware bugs, might have been better spent getting it right from the beginning rather than fixing what is broken and old.

What about hardware? (was: The EFF launches a router project)

Posted Jul 29, 2014 20:50 UTC (Tue) by mtaht (guest, #11087) [Link] (5 responses)

The basic mips-based atheros chipset this stuff runs on has been continually updated (4 revisions over the last 6 years) and is in 100s of products currently sold. While I have CeroWrt running on several of these newer platforms, none have been compelling enough to switch to using, although several buffalo and TP-link products come close. I agree with another poster here that it looks like switching to arm is sanest as none of the mips boxes I've tried can drive 802.11ac fast enough.

OpenWrt itself runs on a lot of more current platforms than the wndr3800! - Go ahead, use those! but as CeroWrt has a rather large installed base of wndr3800s I have mostly been trying to make everything stable on that... and once that is stable... getting some of the science done on evaluating new queuing mechanisms... papers written, data sets sorted through, etc, etc.

and then porting over to a newer platform in the fall and starting new work (make-wifi-fast) on x86.

I agree that now that everything else is looking good (in openwrt and cero, anyway), that the stack is basically solid - that it would be best to try to do some sort of open source hardware for the next generation, in collaboration with the many other research oriented projects out there like project bismark, homenet, homewrt, openwireless, commotion wireless, dozens, nay hundreds of others, but it seems difficult even then - even if we could all co-operate on a RFP and buy to get to a large enough and cost-effective enough volume to be worth doing more engineering up front.

... and that requires effort and money up front that we do not have, and while we could perhaps raise enough via kickstarter it has been hard enough to express the advantages of a bufferbloat-free, blob-free, highly secure and flexible router during the project, much less beforehand. Despite the successes of projects like the rasberry pi and parallella, there would need to be some feasible long term gain and penetration into markets that linksys, buffalo, tp-link currently dominate, on razor thin margins...

Generally people only care about their home routers when they don't work. I have certainly watched smaller router-oriented ideas go by on kickstarter with something like jealousy...

I am extremely happy with where openwrt barrier breaker stands today, and I hope that the bigger manufacturers and ISPs decide to switch to it or something derived from it, on their next generations of hardware. Nothing does ipv6 as well as openwrt now does in particular, and beating bufferbloat so thoroughly has been quite satisfying.

What about hardware? (was: The EFF launches a router project)

Posted Jul 30, 2014 7:16 UTC (Wed) by fredrik (subscriber, #232) [Link]

Thanks for sharing your insights into the state of router hardware today.

I hope that a future open hardware project can show the current manufacturers (linksys, etc) that it is advantageous to make router hardware that is open, and that it sells well because the consumers knows there is a community that will support it with security updates long after the router has been sold.

What about hardware? (was: The EFF launches a router project)

Posted Jul 31, 2014 21:20 UTC (Thu) by rknight (subscriber, #26792) [Link] (3 responses)

>>I agree with another poster here that it looks like switching to arm is >>sanest as none of the mips boxes I've tried can drive 802.11ac fast >>enough.

Have you tried any of the routers based on the Cavium Octeon chipset? I realize these are all currently commercial class routers, but I suspect that the multi-core Octeon chips would have no problem handling 802.11ac.

What about hardware? (was: The EFF launches a router project)

Posted Aug 1, 2014 4:09 UTC (Fri) by mtaht (guest, #11087) [Link] (2 responses)

The ubiquiti (ubnt) edgerouter series of octeon based routers added fq_codel support to their QoS system as of version 1.5 of their debian/vyatta based firmware, which is based on linux 3.4.

The HUGE thread this generated is behind the beta tester forum (you have to register on the site), but it was quite edifying and informative. http://community.ubnt.com/t5/EdgeMAX-Beta/Testing-fq-code...

We ran into some issues with ingress shaping that I hope will be resolved when they switch to linux 3.10 (which may be in 1.6 but I don't know). Overall the edgerouter lite was turning in QoS numbers about 2x better than what cerowrt on the wndr3800 can do (with less cpu), and the pro, 7x. Adding BQL looks useful on the octeon ethernet drivers as well but some rework down there seems needed; I keep hoping someone else will get around to it.

Openwrt recently has gained the ability to boot via tftp on the edgerouter series, and I just saw that support for the flash and usb had been added to the main openwrt tree for it, a few days back, so openwrt barrier breaker 3.10 on octeon may be getting closer to being useful for ordinary mortals.

I have been trying to find a router that could do ingress shaping at 250mbit for quite some time now, and maybe that box can do it eventually, with a lot more work through the stack.

I LOVE the edgerouter pro (8 ports) - getting that routing the yurtlab really simplified and sped up my configuration there (as without qos enabled, it can generally forward at 8gbits)

What about hardware? (was: The EFF launches a router project)

Posted Aug 1, 2014 4:17 UTC (Fri) by mtaht (guest, #11087) [Link] (1 responses)

In more direct answer to your question - no, haven't tried the octeon against 802.11ac. No pcie bus on the devices I've seen...

What about hardware? (was: The EFF launches a router project)

Posted Aug 1, 2014 4:54 UTC (Fri) by rknight (subscriber, #26792) [Link]

Is it possible to do 802.11ac on miniPCI? And if so are there currently any cards available? I have a couple of Netgear ProSafe routers that apparently have Cavium Octeon processors that I've been meaning to attempt OpenWRT on.

Possible alternative: Raspberry Pi + Modem

Posted Jul 29, 2014 21:25 UTC (Tue) by debacle (subscriber, #7114) [Link] (11 responses)

I thought about replacing my proprietary home DSL modem/Wifi router combo with a free software, but I really don't want to use any specialised distribution, such as OpenWRT or the new EFF project (which I welcome).

Now I bought a Raspberry Pi B+ and a separated DSL modem and hope to make it run as a replacement for my proprietary stuff just by installing Debian with PPPoE and HostAP. Let's see when I find a free weekend for this...

Possible alternative: Raspberry Pi + Modem

Posted Jul 29, 2014 21:42 UTC (Tue) by dlang (guest, #313) [Link] (10 responses)

> I really don't want to use any specialised distribution, such as OpenWRT

OpenWRT isn't much more specialized than Debian is

It's designed to work on much smaller, less powerful devices than Debian is, but the router hardware is smaller and less powerful only in specific ways.

a 3800 router is going to outperform a RaspberryPi at network related tasks due to the fact that the Pi has to put all it's networking through it's USB interface (which has significant bufferbloat issues remaining by the way)

I would suggest that you go look through the list of packages available for OpenWRT and then see what you need that's missing.

Possible alternative: Raspberry Pi + Modem

Posted Jul 29, 2014 22:23 UTC (Tue) by debacle (subscriber, #7114) [Link] (9 responses)

Of course, Raspberry Pi is not the perfect HW for this, and Debian does even support hardware floating point on it (Raspbian does, however). With OpenWRT I'ld probably miss dpkg and apt, AFAIK. Nothing wrong with OpenWRT, but I like to stay with my universal OS :~)

Possible alternative: Raspberry Pi + Modem

Posted Jul 29, 2014 22:47 UTC (Tue) by dlang (guest, #313) [Link] (2 responses)

Openwrt has opkg, but if you are deciding based on the package manager, go for it.

I'd love for someone to take the time to make a installation profile that could be squeezed down to a router.

I was just taking issue with the description of OpenWRT as being a specialized distro.

you can define terms so that anything other than Debian is specialized, but if you go a bit broader (to include things like Fedora, Suse, RHEL), then OpenWRT should qualify as well.

Possible alternative: Raspberry Pi + Modem

Posted Jul 30, 2014 21:26 UTC (Wed) by debacle (subscriber, #7114) [Link] (1 responses)

I just distinguished between a specialised OS such as OpenWRT, which runs only on routers, and an universal OS, which runs - more or less identical - on a server, a desktop, or an embedded device. The latter could be Debian (my choice) or Fedora, Mint, Redhat, S.u.S.E., Ubuntu etc., of course. To me it is an advantage to use the same OS for different purposes, but this depends very much on individual needs/choices.

Possible alternative: Raspberry Pi + Modem

Posted Jul 30, 2014 21:32 UTC (Wed) by dlang (guest, #313) [Link]

Openwrt runs on x86 systems as well, again it's not as limited as you think.

It runs on more types of devices that Fedora does.

Remember, it's still using the Linux kernel, and the userspace is still *nix. So it's not nearly as limited as you are thinking.

Possible alternative: Raspberry Pi + Modem

Posted Jul 30, 2014 5:13 UTC (Wed) by drag (guest, #31333) [Link] (5 responses)

Home routers are not really 'universal' devices. I normally see the proliferation of different Linux distros as largely a waste of time (beyond somebody who likes it as a hobby), but this is one of those cases were a custom Linux OS and unique package manager is entirely justified.

These type of devices feature specialized hardware like a programmable switch that will be very poorly handled by typical Linux distributions.

Openwrt is a fine Linux operating system and is worth learning how to operate.

The patches/improvements coming back in from Cerowrt has made the latency and performance of my home network's connection to the internet increased significantly. This has brought tremendous benefits when it comes to things like bittorrent traffic and VoIP and has laid waste to the vague suspicions of the ISP being dickheads... In the vast majority of cases it's people's home routers that suck, not the ISPs.

I really doubt that throwing Debian into the mix would yeild a superior router.

--------

Now if you really want to use Debian for this sort of thing keep in mind that the future for 'Enteprise' networks is 'Software Defined Networking'.

That is instead of screwing around with crap like 'Vlans' and struggling with managing QoS using expensive Cisco gear... you just make a 10GbE/40GbE network that is simple as can be (while maximizing 'east-west bandwidth rather then north-south in traditional network models) and then run a entirely software defined network stack on top of that. This is very effective, very cheap, and works very well. Network folks tend to be sticks-in-the-mud and love their vendors, but eventually it's going to start having a big impact outside of the large OpenStack cloud providers.

This way when you do your 'cloud' people can define the network by how they want the network to be, on the fly, via web interfaces or whatever. Just let the consumer in your business decide what sort of network they like to see and then build it for them without having to configure a single firmware or wire up a single port.

To enable this sort of stuff one of the pioneers is 'Culumus Networks' and they have developed a commercial Debian-based Linux distribution to install on various 'white box switches'. So instead of using big proprietary gear from companies like Cisco you buy generic switches from ODMs from Korea (or whatever) and install Debian on it to control the hardware backplane.

Another approach is to take a cheap 'desktop' Linux system and stuff it full of dual port NIC cards and install Debian on it. You can use OpenVswitch to manage the bridge ports, which is massively more capable then the traditional 'Linux brctl-based switch' that is very common.

From there you can take a look at things like Openflow and OVSDB to peer into the future of network management.

This sort of stuff is going to be a big deal in a couple years so while it's a lot more expensive then a openwrt-based home router it will allow you to keep using Debian and potentially get marketable skills and contribute back to Debian making it 'more universal'.

Possible alternative: Raspberry Pi + Modem

Posted Aug 1, 2014 14:54 UTC (Fri) by kjp (guest, #39639) [Link] (4 responses)

Fascinating post. It seems like you're virtualizing the network, just like everything else is being virtualized...

Possible alternative: Raspberry Pi + Modem

Posted Aug 1, 2014 18:45 UTC (Fri) by dlang (guest, #313) [Link] (3 responses)

yep, all your security boils down to control over the management server, if you get hold of that you can configure anything to talk to anything else.

convenient if you have a network that changes a lot (like a lab), for a production network I'm not so sure.

Possible alternative: Raspberry Pi + Modem

Posted Aug 1, 2014 20:47 UTC (Fri) by raven667 (subscriber, #5198) [Link] (2 responses)

That's in some way the same security problem of any network management plane, there is less fundamental difference between a JunOS or IOS supervisor and a PC running Linux than one might think, in fact most of the modern network gear runs on Linux or FreeBSD, sometimes on re-badged commodity servers, with just an old-timey CLI put on top. Whether you have an SDN controller or management server talking over a network devices or you have a chassis connected to a FEX it is surprisingly similar when you get down to the details. So protecting your management plane, which has traditionally been done with local packet filters/ACLs on the device could be extended into the new designs.

Possible alternative: Raspberry Pi + Modem

Posted Aug 1, 2014 22:10 UTC (Fri) by dlang (guest, #313) [Link] (1 responses)

That is true, but the more you centralize, the more dangerous that control system becomes. With the virtual datacenter you have the same system configuring the switches as is configuring the servers.

As I say, it's nice for highly dynamic environments, but I question the value of it for production networks.

There's also the question of if the dynamically configured switches are going to create unexpected bottlenecks. not a problem on a small network, but a serious concern on a large one.

Possible alternative: Raspberry Pi + Modem

Posted Aug 2, 2014 23:55 UTC (Sat) by bronson (subscriber, #4806) [Link]

Production environments tend to be highly dynamic these days.

The EFF launches a router project

Posted Jul 29, 2014 21:54 UTC (Tue) by josh (subscriber, #17465) [Link] (1 responses)

Do any of the Open Source router projects have any support for MoCA?

The EFF launches a router project

Posted Aug 1, 2014 4:10 UTC (Fri) by mtaht (guest, #11087) [Link]

I don't know of any open source support for MoCa yet. I AM aware of working linux drivers for it, but so far as I know they are closed source.