The EFF launches a router project
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.
![[Dashboard screen]](https://static.lwn.net/images/2014/owr-dashboard-sm.png)
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.
![[Settings screen]](https://static.lwn.net/images/2014/owr-settings-sm.png)
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 |
Posted Jul 29, 2014 16:35 UTC (Tue)
by eean (subscriber, #50420)
[Link] (2 responses)
Posted Jul 29, 2014 17:27 UTC (Tue)
by mathstuf (subscriber, #69389)
[Link]
Posted Jul 29, 2014 17:47 UTC (Tue)
by dlang (guest, #313)
[Link]
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.
Posted Jul 29, 2014 17:45 UTC (Tue)
by dlang (guest, #313)
[Link] (11 responses)
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.
Posted Jul 29, 2014 18:41 UTC (Tue)
by hechacker1 (guest, #82466)
[Link]
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.
Posted Jul 29, 2014 19:15 UTC (Tue)
by arnd (subscriber, #8866)
[Link] (9 responses)
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.
Posted Jul 29, 2014 21:08 UTC (Tue)
by dlang (guest, #313)
[Link] (8 responses)
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.
Posted Jul 29, 2014 22:08 UTC (Tue)
by arnd (subscriber, #8866)
[Link] (7 responses)
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.
Posted Jul 29, 2014 22:17 UTC (Tue)
by dlang (guest, #313)
[Link] (1 responses)
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
Posted Jul 30, 2014 2:31 UTC (Wed)
by mtaht (subscriber, #11087)
[Link]
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.
Posted Jul 30, 2014 2:26 UTC (Wed)
by mtaht (subscriber, #11087)
[Link] (4 responses)
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...
Posted Jul 31, 2014 14:58 UTC (Thu)
by jhhaller (guest, #56103)
[Link] (3 responses)
Posted Aug 1, 2014 4:21 UTC (Fri)
by mtaht (subscriber, #11087)
[Link] (2 responses)
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).
Posted Aug 1, 2014 12:27 UTC (Fri)
by arnd (subscriber, #8866)
[Link] (1 responses)
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.
Posted Feb 15, 2016 13:13 UTC (Mon)
by nysan (guest, #81015)
[Link]
Have a look at openfastpath on ODP.
Posted Jul 29, 2014 17:56 UTC (Tue)
by josh (subscriber, #17465)
[Link] (3 responses)
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.
Posted Jul 31, 2014 8:08 UTC (Thu)
by ortalo (guest, #4654)
[Link] (2 responses)
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).
Posted Jul 31, 2014 19:01 UTC (Thu)
by SiliconSlick (guest, #39955)
[Link] (1 responses)
Posted Jul 31, 2014 23:16 UTC (Thu)
by mathstuf (subscriber, #69389)
[Link]
Posted Jul 29, 2014 18:13 UTC (Tue)
by mtaht (subscriber, #11087)
[Link] (5 responses)
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.
Posted Jul 30, 2014 17:34 UTC (Wed)
by ms-tg (subscriber, #89231)
[Link] (2 responses)
Could anyone knowledgeable also comment on how the state of DD-WRT compares to these projects, by any chance?
Posted Jul 30, 2014 19:36 UTC (Wed)
by dlang (guest, #313)
[Link]
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.
Posted Aug 1, 2014 3:55 UTC (Fri)
by mtaht (subscriber, #11087)
[Link]
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.
Posted Jul 31, 2014 23:08 UTC (Thu)
by NightMonkey (subscriber, #23051)
[Link] (1 responses)
Posted Aug 1, 2014 3:57 UTC (Fri)
by mtaht (subscriber, #11087)
[Link]
http://tomatousb.org/forum/t-676664/trying-to-unravel-the...
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.
Posted Jul 29, 2014 20:50 UTC (Tue)
by mtaht (subscriber, #11087)
[Link] (5 responses)
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.
Posted Jul 30, 2014 7:16 UTC (Wed)
by fredrik (subscriber, #232)
[Link]
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.
Posted Jul 31, 2014 21:20 UTC (Thu)
by rknight (subscriber, #26792)
[Link] (3 responses)
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.
Posted Aug 1, 2014 4:09 UTC (Fri)
by mtaht (subscriber, #11087)
[Link] (2 responses)
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)
Posted Aug 1, 2014 4:17 UTC (Fri)
by mtaht (subscriber, #11087)
[Link] (1 responses)
Posted Aug 1, 2014 4:54 UTC (Fri)
by rknight (subscriber, #26792)
[Link]
Posted Jul 29, 2014 21:25 UTC (Tue)
by debacle (subscriber, #7114)
[Link] (11 responses)
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...
Posted Jul 29, 2014 21:42 UTC (Tue)
by dlang (guest, #313)
[Link] (10 responses)
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.
Posted Jul 29, 2014 22:23 UTC (Tue)
by debacle (subscriber, #7114)
[Link] (9 responses)
Posted Jul 29, 2014 22:47 UTC (Tue)
by dlang (guest, #313)
[Link] (2 responses)
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.
Posted Jul 30, 2014 21:26 UTC (Wed)
by debacle (subscriber, #7114)
[Link] (1 responses)
Posted Jul 30, 2014 21:32 UTC (Wed)
by dlang (guest, #313)
[Link]
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.
Posted Jul 30, 2014 5:13 UTC (Wed)
by drag (guest, #31333)
[Link] (5 responses)
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'.
Posted Aug 1, 2014 14:54 UTC (Fri)
by kjp (guest, #39639)
[Link] (4 responses)
Posted Aug 1, 2014 18:45 UTC (Fri)
by dlang (guest, #313)
[Link] (3 responses)
convenient if you have a network that changes a lot (like a lab), for a production network I'm not so sure.
Posted Aug 1, 2014 20:47 UTC (Fri)
by raven667 (subscriber, #5198)
[Link] (2 responses)
Posted Aug 1, 2014 22:10 UTC (Fri)
by dlang (guest, #313)
[Link] (1 responses)
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.
Posted Aug 2, 2014 23:55 UTC (Sat)
by bronson (subscriber, #4806)
[Link]
Posted Jul 29, 2014 21:54 UTC (Tue)
by josh (subscriber, #17465)
[Link] (1 responses)
Posted Aug 1, 2014 4:10 UTC (Fri)
by mtaht (subscriber, #11087)
[Link]
The EFF launches a router project
The EFF launches a router project
The EFF launches a router project
The EFF launches a router project
The EFF launches a router project
The EFF launches a router project
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
The EFF launches a router project
The EFF launches a router project
The EFF launches a router project
The EFF launches a router project
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
The EFF launches a router project
The EFF launches a router project
The EFF launches a router project
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
The EFF launches a router project
The EFF launches a router project
The EFF launches a router project
The EFF launches a router project
The EFF launches a router project
The EFF launches a router project
The EFF launches a router project
The EFF launches a router project
The EFF launches a router project
What about hardware? (was: The EFF launches a router project)
What about hardware? (was: The EFF launches a router project)
What about hardware? (was: The EFF launches a router project)
What about hardware? (was: The EFF launches a router project)
What about hardware? (was: The EFF launches a router project)
What about hardware? (was: The EFF launches a router project)
What about hardware? (was: The EFF launches a router project)
Possible alternative: Raspberry Pi + Modem
Possible alternative: Raspberry Pi + Modem
Possible alternative: Raspberry Pi + Modem
Possible alternative: Raspberry Pi + Modem
Possible alternative: Raspberry Pi + Modem
Possible alternative: Raspberry Pi + Modem
Possible alternative: Raspberry Pi + Modem
Possible alternative: Raspberry Pi + Modem
Possible alternative: Raspberry Pi + Modem
Possible alternative: Raspberry Pi + Modem
Possible alternative: Raspberry Pi + Modem
Possible alternative: Raspberry Pi + Modem
The EFF launches a router project
The EFF launches a router project