The EFF's open wireless router project

The EFF takes the position that authenticating to the wireless AP, rather than having end-to-end encryption for the services you use, is the wrong approach.

You can see this in their reaction to the Google settlement. They felt that while it was in some sense wrong for Google to collect the data that had been carelessly flung into the ether unencrypted, it was at least as wrong to insist Google "educate" users about enabling WPA and especially WEP encryption. A Google car won't snoop on your WPA PSK connection, but actual bad guys will soon use one of the dozens of available attacks to find a weakness. So you've obtained only a false sense of security. If you instead e.g. switched on TLS w/ certificate checks for your email client you get _actual_ security without the hassle of setting up an encrypted AP.

The one hop auth approach is beloved of snoopers. They lose nothing (by placing themselves at the far side of the authenticated hop they still get to see everything you did in cleartext) but gain everything (now they can be confident which person is associated with the data they're seeing because it's authenticated). So there's no reason to encourage it when end-to-end is not only viable but far superior.

The gui is for cero only at this point, but the configuration variables are kind of obvious.

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

So this sort of thing (many other examples exist, see for example, gentoo's example) does wonders for latency, compensates for lousy modems, and moves control of prioritization to your own device rather than the CPE.

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

I do hope one day to reduce the measurement process done in the above url, to something that could "just run" and be called "calibration".

For example, there was truly excessive buffering in the PPP drivers before David Woodhouse smashed then down to 2 (1?) year(s) back. The invention of BQL (Tom Herbert), made it possible, to squeeze the ethernet tx ring down from up to 4096 64-64k packets down to less then 192Kbytes on 10Gig, and as small as a single large packet on 10Mbit - before BQL went into the device drivers, none of the new fangled flow queuing or aqm technologies had much effect.

I put BQL on a beaglebone black recently, and got a nice 15x reduction in network latency over the default pfifo_fast + non-bql version and a large improvement in bidirectional throughput:

http://snapon.lab.bufferbloat.net/~d/beagle_bql/beaglebon...

There is much room left to beat the bloat out of usbnet, and wifi can be thoroughly improved, in the linux stack, also.

Bufferbloat is not just a router based problem.

That won't help with TCP at all because TCP only reacts to packet loss, not latency. If TCP's congestion control were designed to react to latency, we wouldn't have this bufferbloat problem in the first place: buffers filling up increases latency and would signal it to scale back.

The bufferbloat movement seems to accept it as dogma that active queue management on every midnode is superior to latency-sensitive congestion control on just the end-nodes.