Hacker News Reader

Comment by ibisum | Hacker News Reader

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'.

</opinion>

View on HN

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.

Is a Raspberry Pi powerful enough to do the job? Could a customer version be made with wifi chipset onboard?

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:

http://www.pcengines.ch/apu.htm

Although once you add the wifi, case, power supply, and SD card or mSATA SSD, it's a bit on the expensive side.

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.

People definitely need to be more aware of the x86 BSD based routing platforms like m0n0wall: http://m0n0.ch/wall/ and its fork pfsense: https://www.pfsense.org/

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.

An alternative, if you want to truly get it manufactured yourself (the schematics and materials list are all open source):

https://www.turris.cz/en/hardware

This device is a lot more powerful than the PC Engines APU. As nice as the APU is, its CPU cannot support 1Gbps throughput over the NICs.

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.

1. http://planet.ipfire.org/post/pc-engines-apu1c-a-review

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.

>AFAIK the Atheros drivers are open

(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.

Some of the Atheros Wi-Fi firmwares are open: https://github.com/qca/open-ath9k-htc-firmware

Unfortunately ath9k_htc is mostly found in USB devices.

Thanks for the pointer. I didn't know about this. That's very cool.

If you can point me towards some of the USB devices that have ath9k inside I'd be grateful - I seem to get ralink or realtek every time I buy one.

http://goo.gl/LEp8kK wikidevi list

AFAIK Atheros radios are softmac which moves most of the work into the driver, which is open.

Complaining about "big issues" that no one has the resources/will to fix always sounds like martyrdom to me.

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.

Actually, I think this comment highlights the real motivation for this project: https://news.ycombinator.com/item?id=8061355

It is open source, but that's not the point. The point is "open wireless." More info: https://openwireless.org/

Reply on news.ycombinator.com