I am not an expert, this is my opinion based on casual observation and some experience with the death-roll that one encounters in maintaining a wifi-based Linux machine, but the 'reason for this', for those asking, or "why is this needed?", is this: because there isn't an open source stack all the way from http:// to wifi0:, all the way, for a lot of the available chipsets. Wifi radios are little ARM machines surrounded by a black box, which somewhere depends on a binary blob to do the radio control/communication. So I think the answer is that the radio is where the open-source is needed; everything else is just a Distro War/-solution.
tldr; consumer wifi stacks that allow open network bonding/pairing/ad-hoc connections, are dependent on the vendor-provided firmware blob having control over these features at the radio level. Thus, we need a fully open radio component to be truly, 'safe'.
AFAIK the Atheros drivers are open which is why this project is using Atheros hardware. The problem is solved as long as you are willing to buy specific hardware.
It does appear that 90% of the effort in the router firmware community goes to dealing with blobs and diverse hardware support; whether that effort is wasted is a matter of opinion.
(as corrected by many people, the statement below is not true)
the author of the post you reply to says it's not the drivers closed (yes, there're WiFi chips with open source drivers), but the radio firmware that runs on the chip. There's no open radio firmware for WiFi, and that's a big issue.
The firmware for many older Atheros chips is open source, but as far as I know they haven't yet released the source for any of their 802.11ac firmware. The availability of open firmware for the wifi chipsets is one of the main reasons that CeroWRT is still targeting a router model that's now out of production: the next big problem they want to tackle is wifi performance, and there's no point attempting that if you can't hack the whole wifi stack. CeroWRT is still primarily a research testbed, even though almost all of it is stable and ready to be integrated upstream (which is why it's not entirely crazy for a new project like this to be based on CeroWRT rather than upstream OpenWRT).
The problem here is most hardware seems to require blobs so instead of building software for old hardware that you can't buy new anymore why not just build an entirely new piece of hardware?
People wanting to use this will most likely have to buy hardware for that purpose might as well build it from the ground up.
I would certainly buy it and judging by the hype the WRT1900AC got before ending in complete failure a lot of people would be willing to buy the hardware for that end.
The Raspberry Pi doesn't have any high-bandwidth peripheral connections, and the CPU is too weak to do high-speed routing with QoS. What's needed is an open source board with a modern CPU, a mini-PCIe slot or two for the wifi, and at least one or two GigE NICs. In other words, this:
I'm a huge fan of ALIX and its successor, APU. I've built dozens of ALIX boxes and most have years of uninterrupted uptime running either m0n0 or pfsense. I've never gotten anywhere close to that with any of the Broadcom or Atheros based embedded platforms which are essentially what you get with a consumer router.
I'm surprised the EFF isn't championing some fork of those platforms, or just those two themselves. Trying to fix the problem by adding yet another platform is just going to cause problems. I'm a huge fan of the EFF but it seems to be championing rather strange initiatives lately like the open WiFi and now this.
Got any references for the relative performance of that over the APU board? They're not using the AMD Geode processors anymore.
What you linked is a dual-core 1.2GHz 32-bit PPC built on a 45nm process. The APU used on the board I linked to is a dual-core 1GHz x86_64 built on a 40nm process. There's no way the PPC core is dramatically faster than the x86 core that was shown to have better IPC than Intel's Atom. The PPC SoC might be able to offload a lot of network stuff to fixed-function hardware, but one of the primary lessons learned from the CeroWRT project is that you can't trust any of the offload stuff to be well-behaved with respect to things like queue length management.
Yes. The APU maxes out around ~670Mbit/s using iperf [1]. I confirmed as much in correspondence with PC Engines too. Personally I _suspect_ it should be able to go much faster, but haven't got one to investigate yet.
The 1.2GHz PPC based router is hitting ~940Mbit/s (the most you can expect from a GE interface with protocol overheads) using iperf. I don't have a reference for that, but I've got one of the devices here and have performed that test myself.
Thank you for the performance statistics. We have done a lot of work on other hardware platforms to get them up to being able to saturate gigE or higher, with tuning and things like "Byte Queue Limits" support. The problem with the ppc thing is that most likely it has bufferbloat in a blob we can't fix. (news to the contrary welcomed). And hearing that the APU peaks at 670Mbit is disappointing, but perhaps someone will get some time to profile it and figure out why it is so bad - certainly we get gigE easily with intel based hardware.
Failing a 'dream bard' like you mention a fairly good alternative is a laptop (scraptop) with a broken screen. It may need to be fairly high end, e.g. many Lenovo models I've seen (even X series) have two m-PCI slots available for Wifi.
I setup a PI with 2 NIC (1 WAN, 1 LAN) + 1 WLAN to act as a router + AP, and I have to tell you its network performance is pathetic. The bottleneck for total network bandwidth was somewhere about 37mb/sec. That's not per interface that's total across all. With WLAN and cheap WAN (Fibre or DSL) far exceeding that -- it's a terrible platform to use for this. Especially if you're anything other than a casual user. The raspi's arm CPU left me with a probably undeserved but less than favourable impression; using qemu to build remotely was also a time consuming annoyance.
I ended up building a dual core 3ghz router based on shuttle's XH61V as it integrates dual gigabit NICs + an atheros USB WLAN for AP. Uses 90w of power and boots in < ~4s from SSD, running Linux.
90W is rather a lot. I'm looking at the Intel NUCs, which are a lot more compact and power efficient. Downside is that they only come with a single Ethernet port so you need to add any additional ones via USB3.
3GHz and 90W is ridiculous for a router. A good NIC does not rely on the CPU, so clock speed should be irrelevant. A Mini-ITX board or a router with OpenWRT would be a much more economic alternative.
A good NIC won't require much CPU power to drive, but in order to have reasonable real-world performance with the networking equipment that actually exists, you need every packet to be handled by the QoS and AQM systems running on the CPU. Doing that at near-gigabit speeds really does require a beefy CPU, though not a full desktop-class wattage.
Well once I decided to go this route I figured take advantage of the opportunity to put a good CPU in it and allow it to take over a number of services that I'd previously hosted on another machine (since retired).
It host several services in VMs(dns, transparent HTTP proxy, torrent client running in X11 open via VNC). I also use VPNs quite extensively and seeing as the Intel chip-set doesn't support AES natively, I opted to up the clock speed of the CPU to the highest I could get it without exceeding my budget.
Maybe updating the title of this post would help with the confusion. "...Help Us Build an Open Wireless Router Firmware"
I'm all for competition and alternatives to products, but developers might be able to better allocate our resources rather than create a clone that might not be necessary. Such as ensuring existing projects are secure.
For varying definitions of "open source" (a considerable amount of functionality is offloaded to binary blobs in many models).
In terms of duplicating effort, in the page linked it specifically states it's based on Cerowrt, which is in turn based on Open WRT (which is actually FOSS, instead of just in name).
More importantly, it doesn't say "...Help Us Build an Open Wireless Router Firmware" because that's not the goal of this project. As you clearly pointed out yourself, and as they implied in the post they made, that's already been accomplished multiple times over. The goal is to make a router designed for the Open Wireless movement, which is why, in the first sentence, they link to https://openwireless.org/
Good idea, selling routers with this firmware would be beneficial to router manufacturer(s) as they get a new marketing tool ( Open Wireless Compatible TM -mark), which would skyrocket market adoption. That to happen needs brand value, so lets hope this project catches on.
Those firmwares function but really don't have elegant and easy to use user interfaces. If you read the link, EFF wants to create some easy to use router firmware for ie. small businesses to run a open network from with QoS, all from a "minimalist secure interface" that selfupdates. No firmware today has got those last two parts down, and it's really hard to set this stuff up when you aren't doing network operations as your day job.
How is luci not easy to use, or inelegant? (particularly say, with luci-theme-bootstrap). I strongly doubt EFF have some magical idea to create a simpler interface. It's trivial to install luci-app-qos, luci-app-samba and other basic software that a small business would need. It sounds like they just want a different default config for OpenWRT/CeroWrt, where multiple zones are enabled by default, and one is opened up.
The idea of does everything for me, including updates and minimally secure are disjoint ideas - you can't have security unless you have complete control over your own device - and OpenWRT with luci already provides that. Relying on a third-party to do your updates, even if it's a trusted body like the EFF is always open to attack.
OpenWrt doesn't provide the self-update by default, and I hope it never decides to add such thing, unless we get reproducible builds, and build some kind of network consensus to verify the integrity of packages, and that they were derived from specific source code (as Nix/Guix and Debian's ReproducibleBuilds are attempting). In other words, we need to remove the centralization of updating, because it's such an easy target for the likes of you know who.
Bootstrap make LuCI look better, but it's still complex and full of non-human-readable stuff. For example, the interfaces on my router are called ge00, gretap0, ip6tnl0, pimreg, se00, sw00, sw10, teql0, tunl0. I work on networking for a living and I have only a vague idea what those are.
Also, you know what else is such an easy target for the likes of you know who? Unpatched systems.
FYI: CeroWRT is a fork based around David Taht's work combating bufferbloat. It describes itself as a project built on top of OpenWRT, which sounds slightly less scary IMO than fork.
Which really seems to be missing a great opportunity. Why would they want open access routers just so it can connect to one of a handful of local monopoly ISPs? That's not freedom.
If they're doing it, why not instead work on building a mesh. There are enough wireless hotspots in my metro area to link up the whole city if only these things talked to each other instead of to the centralized wired network.
mesh networks are made difficult by sanctioning bodies and spectrum laws, whereas this intermediary step of ensuring non-malicious routers isn't hindered the same ways.
There's an even deeper problem than the mesh itself, and that is the dependence on a managed address space (IP, Ethernet, ...).
Even with a physical mesh in place, an open IP network will probably fail due to the need for someone to manage the address space. There will be disagreements about address management among the participants, the job will become too big for volunteers, and eventually there will be a need to have a formal organisation to control addresses. In time, this organistion will become IANAv2, along with exactly the same questions about who gets to control it. That's what happened to a lot of the community wireless networks set up in the early 2000s: they fell apart due to management issues.
Also, as shown by the propagation of "three strikes" rules, and copyright notice sent to IP addresses, a managed address space provides an handle for those who with to exert power, whether that be power over individual addressees or the managing organisation.
My guess is that a successful open network will have to use a protocol that doesn't rely on a unique address. For example, can Freenet be run as a mesh network instead of an overlay network?
I think this is a pretty good idea, and something I have given a lot of thought to. The problem is really bigger than simple privacy though. If you are going to take the time to build an open router, it would be wise to make it have significant broadcast range to try and build in mesh network support.
If people could pay a flat hardware fee and connect directly to the internet in a secure way, Comcast would have significantly less bargaining power and the customer would have significantly more privacy.
How could you pay for the Internet connection on an flat hardware fee? You'd still need some ISP to connect you to the rest of the world outside of the mesh network.
There is an additional need to make an automatic DMZ for "internet of things" devices (isolated like they're in a guest network, or even firewalled entirely), while still cleverly routing in packets from mobile devices.
1. Because devices are doing new things and often by companies without strong software cultures that build in update mechanisms and look after old devices, so they are not updated as well as major platforms.
2. For some devices, you can't simply isolate them as full guests, because existing protocols from your phone allow LAN-to-LAN discovery and control, so special NAT-style routing into the DMZ would be ideal.
Related: the replacement cycle for devices like refrigerators, washer/dryers is not the 2 year cycle that we're used to for smartphone platforms. (e.g., even if your Android 2.2 phone can't be updated, you have probably replaced it by now.)
Regarding the question why CeroWRT, I think this makes perfect sense. DD-WRT ist (afaik) still rooted in the open sourced Linksys firmware, while OpenWRT started from scratch in between. They really do awesome work and have developed a really powerful software platform for embedded devices in general. CeroWRT is based on OpenWRT but is focused on certain important aspects (bufferbloat). So I guess the EFF considers this important and wants to help by giving it some publicity.
Those are the kinds of initiatives that make me optimistic about the future <3
If you are interested in where the OpenWRT project currently stands (hint: they need web as well as systems programmers) you might enjoy watching this talk from 30c3 - OpenWRT and 10 Years of Fun with Embedded Devices:
You know what a killer app for this would be? An "app store" of stupidly-simple-to-use server software.
Routers are most people's only always ON computer, and having the ability to run decentralized applications on them like media, backups, microblogging, chat bouncers, etc. as easily as one would install a smartphone app could really tip the scale back toward the edges and away from centralized services.
Money can't be ignored though. There has to be a (cryptocurrency-y?) way for people to voluntarily "subscribe" to recurringly give money to developers of these services, and it has to be so simple that it's almost easier than not giving.
Costs could be offset by the user by renting out cpu/bandwidth/storage in a similarly one-click way by running specialized apps that handle that.
My Synology DiskStation has a nice set of packages for things like that. As does my OpenWRT router. Both are pretty awesome.
Something as nice as the App Store definitely requires some sort of revenue model. The Synology stuff is about an order of magnitude friendlier than the OpenWRT: the apps are more curated, better polished, etc. Which makes sense; polishing an app to consumer-grade UI levels and then properly cataloging it is a lot of work. Work that doesn't often happen in the open-source scratching-one's-own-itch context.
That would have to be thoroughly thought of to offer a simple solution, maybe even at the cost of defining stricter boundaries of what such services would be allowed to do.
But there's no reason why running servers should be so scary that only the powerful are able to run them. And "server" is not synonymous with "webhosting". There's a lot of p2p to be done if we want a decentralized internet.
I regularly run a Bittorrent "server" available to the internet and never had any problem. I also run a Ricochet "server" (also a p2p app), no headache either.
We have to get past the FUD and dig ourselves out of this hole.
Limiting the fraction of bandwidth used is a much harder problem than it sounds like, thanks to torrents. When you join the torrent you're inviting lots of UDP traffic to you. You can keep it from getting to the endpoint by traffic shaping, but that won't help if your uplink gets saturated by all of the incoming requests.
Your typical asymmetric DSL is therefore very hard to safely share. You can try to block torrents, but there's no truly reliable way of doing so that doesn't involve blocking all encrypted traffic.
Could this be solved by a collaborative protocol? A simple home router has the advantage that all resources are being consumed by a small group of people that already are used to cooperating around resource allocation.
E.g.: The router has some sort of bandwidthd. The Torrent app checks in, asks how much it can use for a low-priority bulk download, and gets a token good for a 30-second lease on 10 megabits down. Before that expires, it tries to renew the token, and maybe it gets only 5 megabits because somebody is watching Netflix. If at some point the connection quality gets bad, the router's owner gets an email saying that the router has noticed a lot of BitTorrent traffic from "Timmy's MacBook" and that maybe they should switch to a BT client that supports bandwidthd. And so dad gets Timmy to upgrade.
The parent simply skipped past the part that a connected peer will send less traffic if they sense packet loss. It's a little problematic, in that there are a lot of clients all sending at once and all looking to see if they can increase their rate of send, but if you ingress limit (drop packets, or via ECN) BitTorrent is controllable.
BitTorrent peers are collorative, because otherwise turning on BitTorrent anywhere would immediately result in the parent's boogeyman showing up: being flooded by way more traffic than can be handled. That's not an overlooked part of designing a client: it's known that when writing UDP protocols one has to do one's own flow control.
Yes, that's absolutely correct on a per-peer basis. The trouble is that for a large torrent, there could be hundreds of peers each attempting to negotiate on the link, and that can cause problems. My experience is with experimenting with just about every QoS setting possible on a Cisco ASA hooked up to the cheapest Verizon DSL several years back- I haven't bothered lately but that's because my home pipe these days is thick enough to make it not matter.
BT would be a lot friendlier for traffic shaping if the tracker played a more active role in flow control, or if otherwise some distributed consensus was negotiated regarding wanting more unsolicited connections.
I'd rather like better data on the problem you describe, as it does not seem to line up with the experimental data I have so far on the interaction of AQM and packet scheduling techniques with bittorrent.
Which predated the development of fq_codel, which is the fair queue (flow queue) + aqm hybrid now deployed in cerowrt, openwrt, and countless other QoS systems. That paper only explored RED or SFQ, not a hybrid.
What I think the positive effects we are seeing now are several factors. 1) a "torrent" is usually on 6 flows at a time, rotating to a new flow every 15 seconds or so. 2) The additional peers trying to negotiate IS a problem at very low rates (say below 4mbit) but invisible at higher rates. 3) reducing latencies under load to under 5ms has enormous gains in bidirectional throughput, which more than compensate for losing torrent's delay based backoff mechanism, which only backs off at 100ms. Which would you rather have, 100ms latency or 5ms?
See, for example, what the fq_codel system does for verizon and comcast here:
We got back 5x free bandwidth on the verizon test. And if you are experiencing 5ms worth of latency does it really matter if you have 6 torrents in the background?
(80, yes! but it's a function of your bandwidth also and... and... more testing is indicated.)
... so I haven't got around to redoing the research and writing a successor paper on it, and probably won't anytime soon. The original authors of that paper have gone off to do several papers of extensive analyses of RED vs ledbat, and I think they've largely gone off into the weeds, not that I mind having that analysis as a basis if ever we (or someone) gets around to analyzing fq_codel with some of those techniques.
Please feel free to test re torrent with a system that uses something like openwrt's qos-scripts or cerowrt's SQM system.
The conclusion of the original paper was that only classification seemed to be an answer to even further deprioritize torrent in an AQM'd and FQ'd world. (which the above systems can do also)
I hope there will be a way to manage the bandwidth and load properly. I think it will be a critical point for this project to be successful. If, e.g., I have an open wifi network access point in an apartment complex or even neighborhood, without the ability to manage bandwidth it might lead to a freeloader problem.
I am thinking it would be cool for local access point owners to, through the router, network and set bandwidth policies as a group. That way freeloading could be mitigated by throttling bandwidth to encourage people to add nodes. It would need to also maybe support lightweight communications protocols in order to facilitate coordination and maybe messaging to people connecting to the open wifi access points.
They thank Dave Taht for helping them, and that's his project. It may be as simple as that. CeroWRT tracks OpenWRT anyway, so they're not really in competition.
I don't regard cerowrt so much as "my" project. There's a couple hundred people on the mailing list - it's the "reference router project" for the bufferbloat-fighting community,
And: cerowrt is much closer to a "branch" of openwrt than a fork. It's synced with openwrt on a nearly weekly basis, and the net delta between it and openwrt at this point is a few dozen patches (most code under test), and a bunch of test tools maintained in the ceropackages feed. We have always collaborated closely with the openwrt folk (several help out on a regular basis). A core difference between openwrt and cerowrt is process - by focusing on one router only (where they focus on hundreds), we were able to spin up and prove out new ideas faster in some cases than they, and maybe get "Stabler", faster - (that said, see bug 442)
Unfortunately - as so many have noted, that router is EOL, and we'e been trying to find a replacement platform for over a year now.
I always regarded DDWRT as the de-facto open replacement for router firmware but the EFF doesn't even mention it. Why not fork from them, are there (legal) issues?
Not sure I agree with you that DD-WRT is the de-facto open replacement for router firmware. DD-WRT is just a fork of an old version of OpenWRT (White Russian). OpenWRT is where all the innovation really happens. The OpenWRT developers also contribute back to the Linux wireless stack.
I believe DD-WRT also had a few GPL violations in the past. Not sure if they still do. Anyway, do agree with the consensus that none of this is really needed because we already have OpenWRT and OpenWRT runs on anything that you could possibly want :-)
But I think the reason for that is the legality about using the proprietary b43 driver. Again, seems that DD-WRT does (patched kernel) support this but their access to the Broadcom source code seems questionable.
It is just an openwrt fork anyway. I use openwrt on everything, ever. I'd wish the EFF would just contribute to that project, or at least present us with evidence they tried.
I just run an EPIA 500 fanless x86 with OpenBSD on it, boot it from a CF card. A MSI Ralink RT2560F - MSI PC54G2 PCI Wi-Fi 802.11g card in it for the AP.
Instead of trying to fight to make big corporations and governments play nice on the Internet, this project tries to allow individuals & small & medium businesses to be good/model citizens. This is a grass-roots attempt to create a shareable electronic freedom: not only ought you have the right to privacy and expression, but sensibly, you ought have the means to share and spread that right too.
I hope to go into more detail about this elsewhere, but to me anonymity is a key point -- existing telecommunications infrastructure is very hostile to anonymity, both in its authentication and payment models. Open wireless networks at cafés, libraries, and so on are already much friendlier to anonymity. Broadening the availability of this kind of infrastructure could be helpful to making anonymity a practical default, at least for some applications.
(I work at EFF and have contributed to this project, but wasn't responsible for EFF's adoption of it.)
Edit: My colleague Yan Zhu and I have also been looking at the question of transparency in software development, including deterministic and reproducible builds as well as update mechanisms that make it hard for the software publisher to target users with malware. I think this project also makes for a good testbed for how transparent we can make software development and distribution. One thing that I did on the initial release of this project is making it get update manifests over Tor so that EFF can't distinguish particular users when serving them update images. I think Ranga spoke about this in his talk at HOPE, and I think it's something EFF will continue working on quite a bit.
This is wild speculation, but when I read the announcement I figured that they're planning to provide the firmware and software for free, while selling fully-assembled hardware pre-loaded with the stack. Can't always rely on donations alone.
I could quite easily be wrong, but without money in the equation, I feel like it would make more sense for them to work with OpenWRT rather than fork it.
Off topic, but hopefully there are some wireless guys in this thread who know the answer: Whatever happened to 802.11ad? Wikipedia says the spec was approved in 2012, but there's pretty much no products on the market.
It seemed like everybody was rushing to get .11n stuff on the market, even before the spec was finished, (draft-n, etc) but nobody's building .11ad radios?
Do you mean 802.11ac? Many new radios use 802.11ac[0], although maybe the rush is smaller than that for 802.11n. 802.11ad is a 60 Ghz protocol, a different frequency than 802.11n or ac use. It looks like 802.11ad would mostly be used as a sort of wireless USB or HDMI, [1] not networking, because it doesn't penetrate walls.
The plethora of solutions to this problem that are already out there, battling through the usability issues, leads me to a perilous thought: there really aren't any guarantees that .. not only do we have the NSA to deal with, but .. many other groups which can profit from severe fragmentation. Cocktail OS builds for commodity hardware are one thing, but knowing - truly - what is going on in the stack is another thing entirely. I think thats important, for an Open Source Wifi/Network effort.
So any attempt to make an open source router OS that kicks ass, should, in my opinion, predominantly strive to be a self-hosting OS, with full sources on-board, and signed images being turnkey; i.e. everything needed to build the OS from source is part of the package; i.e. no cross-compiling, no binary blobs, the router builds its own firmware.
Yes, its extreme, but I truly do think that the disconnect between build-ability and OS 'dependencies management tools' has a lot to offer in terms of improvement. If the first thing the machine did, OOBE, was to build itself its own unique system image .. from source .. as a feature for the user .. then we have a secure system.
Unsigned system-image keys are going to be very, very much more important in this networking/communication space. Full source->build->signed-binary control as part of the bootup is where this effort should focus. Sign the code, build the code, sign the binaries, only run signed binaries on the OS built around the key, and so on.
This allows intercommunication - shared Source, of course - but it also allows audit of things in the environment which is being defended. If we don't build-in sufficient encryption to make it truly safe, whats the point of being so Open about it? Imho, RouterOS should be full-Source onboard.
As a practical matter, consumer routers can't be self-hosting. They don't have the processing power, memory, and storage necessary, and none of the router vendors can be trusted to not have some kind of embedded rootkit that circumvents all of that. It's far better to work on having a deterministic verifiable cross-compiling build system and continue to flash the firmware over JTAG.
>They don't have the processing power, memory, and storage necessary
This is in my opinion, a sign of bloat. They darn-well do have the processing power to build their own images! Its just 'not desirable to use a slow computer to do it' ..
Well, where the build is slow: refactor until its fast.
> It's far better to work on having a deterministic verifiable cross-compiling build system and continue to flash the firmware over JTAG.
The new open networks will require a lot more crypto. I'd prefer to run an open network where signed binaries and such things are just part of the norm. But then, this is all just hot-air .. time better spent actually working on the problem of so much hardware, so little actually safe source code to run on it.
In theory you can strip out the majority of the kernel sources and I'm sure there's some automated way to do this with the kernel build process. Make already doesn't even have to look at the source for drivers that aren't being built. I think there's a lot of macros that depend on the config but there should still be a way to basically run the preprocessor over everything being compiled to strip out all of the pointless #ifdef blocks.
The preprocessor's got nothing to do with it. As you've noted, the raw size of the source code is easily dealt with. (At least for parsing. We still haven't identified where it's being stored in the first place.) The problem is that when targeting an embedded system, you really want to use compiler optimizations (especially size optimizations), and those heuristics require more RAM than routers have. Ideally, you would compile large parts of the OS with link-time optimization, which is one of the most memory-intensive options you can pass to a compiler.
IMHO: EFF doesn't yet grok the importance of pushing out good routing protocols to the edge, and the need for mesh networking the edge together in the advent of emergency... or adversity.
CeroWrt include every mesh networking protocol available - olsr, batman, and babel, for starters. The default is babel in it's source specific variant, and it's on by default. Tinq is also in there as an optional package, and recently RTT based metrics were added to babel to make meshing over vpns saner.
I'm not sure what you mean by "secure mesh networking"?
One of the cool features (not in the current cerowrt release) of the quagga-babeld protocol implementation was the ability to securely exchange routes over an insecure medium, which not only has an implementation but is an official RFC.
Lots of people talking about a lack of open wireless drivers, what about implementing your own wireless stack using something like http://sdr.osmocom.org/trac/wiki/rtl-sdr
They want to build an open wireless router. I think they want a open source software like openWRT. I found I was wrong, when I read comments, everybody discuss the router hardware...
I want to know, why they calling hackers to do with hardware not software?
I am interested in seeing more open router firmware variants. If the open SSL debacle has thought us anything it is that more eyes on the code is better but alternative implementations are better.
In the paper Ken looks into potential vulnerability in compliers. He shows a trivial way that code can be manipulated and a trojan house could be injected into code by a vulnerable complier. His point is that checking the source code is not enough.
i always run openWRT and always left a secured, open wifi for anyone around to use.
until i moved to verizon (since they have the officially sanctioned monopoly of my region) and now i have to run the ugly, power hungry, wireless AP+cable modem (they market it as fiber, but it is cable all the way until the block repeater, then fiber, then into my home, then cable again... the few meters of useless fiber is probably just to avoid CA laws to provide open TV channels for free if it was market as cable)
anyway, all that rant just to say that my will to maintain yet another device is null after that. i just roll with the verizon aberration.
It also needs an anonymizing service, because when you offer open internet, you never know what users might do with it, that will be traced to your personnal connection.
This is a fork of a fork of OpenWRT, and includes some stuff that isn't in the upstream OpenWRT yet. It's not all-new, but it's not reinventing the wheel in any way. Think of this as trying to be Ubuntu to OpenWRT's debian.
In order to enjoy VPN on all of your devices you can either flashing your current router with DD_WRT firmware or by a VPN router but cause DD_WRT is free, it might be better you give it shot first before looking for VPN router. DD-WRT is a free open source project aimed at developing a Linux based firmware solution that removes the restrictions placed on routers by their default programming. Fortunately, it has the option of selecting different VPN configurations like: PPTP, L2TP or OpenVPN and Once configured, users on the network don’t need to enter a log in process when they need to activate the VPN. It just starts automatically, so any device connects automatically and easily, giving you all the benefits of using a reliable VPN service.
OpenWRT supports a bunch of vpn solutions, including OpenVPN. It's lacking a simple UI to configure though (luci-app-openvpn was broken and removed, although there are updated .ipkg which can be manually installed).
I run a custom router on of a Soekris Net6501. It can run Gentoo or Ubuntu or whatever you like. No custom builds necessary - but the hardware is ~$400
Currently the WiFi protocol is vulnerable within a millisecond, and a completely new non-defective-by-design WiFi protocol would have to be created.
Also, you'd have to make sure that the device(s) could not have a vulnerability to remote code execution of any kind, or the device may be capable of being remotely turned into a directed energy weapon, which could lead to serious security concerns.
Uh, no thanks EFF. We were working on this idea, we approached you - all we wanted was a little endorsement from you, and our large company partner was willing to open license a slew of patents, RPI style. What we got back was from the EFF was a bunch of nerd arrogance and essentially this: We are too busy reading the news about the Snowden affair (which was new at the time) to talk with you. A month or two later we facepalmed reading a post from another EFF staffer about the importance of open patents...
This is all a little too cagey for anyone else to understand. It sounds like you got snubbed by someone at EFF at a time when they were somewhat distracted by arguably the largest geopolitical event the internet may ever have experienced. Can you point to what it is you're working on that is relevant to the announcement?
Are there any more details you can provide about this issue? (The present form is just a claim). Unless you're bound by contracts and can't disclose the group you were working with. If this is true, it is important to bring it to the attention of the public imo
I can't mention BigCo's name, they definitely wouldn't appreciate it and the deal would be off the table now anyway.
Other info: We asked to keep our discussions confidential. We weren't asking them to sign an NDA, we explicitly mentioned that their word would have been enough. It's pretty simple, they weren't willing to discuss it confidentially, so we let it drop after about 9 emails.
It's true it was a snubbing, but I'm not upset about it. It is however somewhat ironic to read this call for help after we proactively contacted the EFF with just such an offer of help.
A lesson I learned was - you can admire what an organization stands for, but not always the way that organization is run. It also may be an ineffective organization. I guess these comments could hold for quite a few charitable organizations.
"you can admire what an organization stands for, but not always the way that organization is run"
If you don't mind, it seems as if you may have a misconception about what they stand for. I clearly don't have any of the details, but it sounds like a non-sequitur to talk about an open wireless standard and an open wireless community and then require those discussions to be closed up in an NDA. You may not quite be on the same wavelength on the concept of open standards as they are.
Huh? We didn't require those discussions to be closed up in an NDA. We were just trying to do right by our partner, who wanted to negotiate the EFF / OpenWireless endorsement, neither of which they seemed to keen to give, so we walked away.
Do what you were going to do anyway. Wanted to open-licence the patents? Do it.
But unless you can open all the firmware, no-one who knows what they're doing will want to know, in this scenario. No excuses.
(As for the Raspberry Pi - actually, the stock firmware uses the ThreadX RTOS which Broadcom don't own and can't completely open-source - but they've got someone writing a set of open firmware, although it'll be a while in coming.)
I note that the bufferbloat.net project is looking for new hardware, and sponsors. The main foci of the project are apolitical in nature - just trying to build a faster, better internet. Most of cerowrt's original goals have been met, except the mandate to seriously improve wifi, which is next on the list.
>Allow small business and home users to easily enable an open network, so guests and passersby can get an Internet connection if they need one, while keeping a password-locked WPA2 network for themselves and their friends or coworkers.
Irrelevant.
>Let you share a bounded portion of your bandwidth on the open network, so guest users cannot slow down your Internet connection or use a large portion of your monthly quota.
Irrelevant too. You're not favoring any content over anybody's elses.
>Provide state-of-the-art network queuing, so most users can expect an improved Internet experience—especially with latency-sensitive applications—compared to what commonly available consumer grade routers are delivering today.
QoS is not a net neutrality violation, it favors certain aspects of a certain class of services. It's not an ISP slowing down Netflix in order to provide their own alternative, it's an ISP prioritizing VoIP over BitTorrent so that you don't get choppy video-calls. (Besides, you're not an ISP.)
>Offer a minimalist, secure, and elegant Web user interface to set up and configure the router. Advanced, non-minimalist administrative options are accessible by SSH.
>Advance the state of the art in consumer Wi-Fi router security and begin turning back the growing tide of attacks against them. Most or all existing router software is full of XSS and CSRF vulnerabilities, and we want to change that.
>Include a secure software auto-update mechanism. In addition to using HTTPS, firmware signatures and metadata are fetched via Tor to make targeted update attacks very difficult.
Net neutrality for this kind of application is a flawed premise. If you're offering it for free that means you're not offering it commercially. And that means any of the precedent or case law or regulations regarding common carriers or any of that.
Now if you started selling subscriptions? That would be a different story.
Indeed yes it will be very likely that a provider would be selling service. A coffee shop might provide a code for extra access on the receipt, or a home user might ask for a small but non-zero payment of cryptocurrency after a certain amount of free use, or a openwifi provider might want to let users pay small amounts of currency to prioritize packets. In either of these likely use cases, wouldn't the net neutrality principle that all packets be treated equally be violated?
This begs the following questions which are seperate from the discussion of the definition of violation of net neutrality: Won't such monetary incentives help encourage people to setup open wireless routers? Might net neutrality rules hamper the widespread deployment of open wireless?
"Net neutrality (also network neutrality or Internet neutrality) is the principle that Internet service providers and governments should treat all data on the Internet equally, not discriminating or charging differentially by user, content, site, platform, application, type of attached equipment, and modes of communication.
At its simplest, network neutrality is the principle that all Internet traffic should be treated equally.[20] According to Columbia Law School professor Tim Wu: "Network neutrality is best defined as a network design principle. The idea is that a maximally useful public information network aspires to treat all content, sites, and platforms equally"."
Both Wikipedia and Tim Wu's definition seem to be pretty clear about treating all data equally. Prioritizing a certain type of traffic like VoIP over bittorrent would indeed be a violation of both wiki's and Wu's definition. And prioritizing the owner's packets over the guests would be a violation as well. Does this wikipedia article need a correction?
tldr; consumer wifi stacks that allow open network bonding/pairing/ad-hoc connections, are dependent on the vendor-provided firmware blob having control over these features at the radio level. Thus, we need a fully open radio component to be truly, 'safe'.
</opinion>