LWN: Comments on "The EFF's open wireless router project"

The EFF's open wireless router project

zlynx — Fri, 01 Aug 2014 00:10:59 +0000

ECN also works pretty well. I used to use it on a T1 connection. I had a Linux router and I gave it an outgoing RED w/ECN queue on the LAN connection.

All of my Windows and Linux systems on the LAN cooperated with ECN quite well. It improved packet flow and reduced the number of packets that had to be dropped by the queue.

The EFF's open wireless router project

intgr — Thu, 31 Jul 2014 09:48:11 +0000

> the receiver can influence how fast the sender outputs data

Most likely it's just dropping packets like a congested router should do.

It's true that you can also throttle traffic by delaying ACKs so that the TCP window fills up, or shrinking the window in the first place, but that seems somewhat complicated and modifying packets is not a nice thing to do. I haven't heard of the kernel having any infrastructure to do either.

The EFF's open wireless router project

dlang — Wed, 30 Jul 2014 19:40:11 +0000

There have been a lot of people putting work into congestion algorithms. Many of them have published papers about how wonderful their solution is.

However, in every case, when combined with the traditional loss-based algorithm that's widely deployed, the new algorithm looses badly and so it can't be used on the Internet (possibly on Internet-next-next if no existing software is ever allowed to connect to it, but that's extremely unlikely to ever happen)

The EFF's open wireless router project

intgr — Wed, 30 Jul 2014 19:35:31 +0000

Thanks for this explanation.

Sorry if my initial post was confrontational. Back when the bufferbloat movement got started, I tried looking for reasons why the AQM approach was preferred, but all I found was some flamewars that seemed dismissive and poorly reasoned.

To be fair, back then there weren't any AQM algorithms to solve the problem entirely either. I have to wonder, if a similar amount of effort were to be put into developing TCP congestion control algorithms, maybe we would already have a solution to these drawbacks?

(PS: for anyone else wondering, FQ stands for "flow queue")

The EFF's open wireless router project

dlang — Wed, 30 Jul 2014 19:32:26 +0000

the receiver can influence how fast the sender outputs data, if it couldn't, there would be no way for a CeroWRT to affect the traffic inbound to it from the Internet.

I may be wrong on the exact mechansim, but there is only so much feedback that takes place. As I understand it, there is window size, and how quickly the receiver acks the data to tell the sender that it no longer needs to take up space in that window.

The EFF's open wireless router project

mathstuf — Wed, 30 Jul 2014 13:22:40 +0000

> It's your customer's time you're wasting.

This would seem to be more along the reality and explain why the administrators don't see it as them losing any time with congestion.

The EFF's open wireless router project

mtaht — Wed, 30 Jul 2014 12:40:59 +0000

oh, failed to make my point that lowered latency can increase throughput.

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

Now I have. :)

The EFF's open wireless router project

mtaht — Wed, 30 Jul 2014 12:38:04 +0000

The problem that we have seen with latency sensitive TCPs are threefold.

1) (and most damning) is the best a latency sensitive tcp has been seen to work at so far is a target of 100ms for things like bittorrent and LEDBAT. With AQM we get (eventually) below 20ms with pie and below 10ms with codel, and with FQ-based techniques it's closer to 0 for sparse traffic and the size of the queue for big flows. With the fq_codel hybrid, it's closer to 0 for sparse traffic, and less than 10ms for big flows. So doing it e2e is at least 10x worse than sticking a better algorithm at the bottleneck.

A lot of people reading this paper: http://perso.telecom-paristech.fr/~drossi/paper/rossi13tm...

miss that the alternative to AQM or FQ is using low priority congestion control AND accepting a *100ms delay target*. Which bugs me. Do you want nearly 0 delay or not? It's your time your wasting.

And despite all that, some early tests with LEDBAT seem to show you CAN get a lower delay target IF you assume a FQ'd system and couple your congestion controller to multiple flows, so there is still hope for and need for further research in this area.

2) delay sensitive TCPs compete badly with loss based TCPs. From a game theory perspective, as soon as there is one loss based TCP on the link, everybody else loses. You can either upgrade everybody's tcp to delay based or incrementally deploy aqm and fq techniques.

3) I personally would have liked a split TCP world, where stuff exiting ethernet entered wifi and switched to a delay sensitive tcp. But that didn't happen.

Anyway, so we tried everything, early on in the bufferbloat project, and we continue to do so...

but at the moment...

fq_codel wins, spectacularly, over everything else we've tried, and it's getting pretty widely deployed.

Lastly, we are all in favor of continuing improvements to TCP and related transports, and perhaps missed in the noise about things like fq_codel are how much other parts of the host stack have had the latency ripped out of them, with new techniques like BQL and sch_fq, and better drivers, all of which have had spectacular effects across the kernel mainline - not just on latency reduction but on real world throughput due to the tighter control loops. BQL in particular did wonders for 10GigE, and does great things at any speed. Recently I added BQL to the beaglebone black, and got a 15x reduction in self induced latency overall vs the non-BQL, non-sch_fq version:

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

I sure wish everyone was adding BQL to their ethernet drivers, it's only about 7 lines of code, and in an age of ever slower internet of thingamabobs, it's needed.

Next up - make-wifi-fast - and this is driver and stack level rework more than it is fq/aqm stuff, to better handle packet aggregation in particular.

The EFF's open wireless router project

intgr — Wed, 30 Jul 2014 08:20:49 +0000

> you end up having to play games with how quickly you respond with acks to data that arrives

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.

The EFF's open wireless router project

mtaht — Sun, 27 Jul 2014 20:10:18 +0000

To clarify, bufferbloat happens at bottlenecks, period, not just on routers but inside network stacks as well.

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.

The EFF's open wireless router project

dlang — Sun, 27 Jul 2014 02:33:23 +0000

One other very important issue (which I managed to forget)

bufferbloat only shows up on routers that are bottlenecks. This can be something like the Verizon/Level3 interconnect, but it's also going to be on your home router where you go from gig-E to DSL/Cable at speeds around three orders of magnitude slower and at the ISP router where they go from their high speed internal network to your download link at speeds around two orders of magnitude slower.

If you aren't on the bottleneck, you really can't fix it.

However, what you can do is you can make a system that you control be the bottleneck (by configuring it to only use 95% of the bandwidth that you actually are paying for) and then BQL and fq_codel will work there.

Since you can't install something on your ISPs network, managing your download speed is MUCH harder, and you end up having to play games with how quickly you respond with acks to data that arrives and other similar games to try and trick the server on the other end of the Internet to send you data a bit slower until you get to the point where it's sending you data slow enough.

If your the two routers on each end of your ISP link were running fq_codel, bufferbloat would be solved for the wired networks.

The EFF's open wireless router project

mtaht — Fri, 25 Jul 2014 13:45:12 +0000

We wrapped fq_codel with htb and added DSL framing compensation in the "SQM" scripts in cerowrt. The code runs on openwrt, cerowrt, and debian/fedora derived systems (with a little tweaking).

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

The EFF's open wireless router project

jezuch — Fri, 25 Jul 2014 11:34:53 +0000

> If you do have bufferbloat problems, the ping times will skyrocket.

A practical example:

I got a DSL modem from my ISP. It was total crap; even when I managed to coerce it to actually work, everything was unbearably slow. I had a BitTorrent client running seeding some torrents and it saturated the outgoing pipe, but the modem just took whatever the client sent and happily buffered it. Ping times to the *modem itself* increased gradually to the multiple-seconds range and even the smallest request's RTT also increased along with it. Throttling the BT client helped, obviously, but still I celebrated when I got rid of this piece of junk and replaced with an actual router/modem :)

The EFF's open wireless router project

dlang — Fri, 25 Jul 2014 04:23:41 +0000

Bufferbloat destroys latency under load.

The easiest way to see if you have bufferbloat problems is to start a ping going, and then do a large file transfer that saturates your pipe.

If you don't have bufferbloat problems, the ping times will remain about the same (within a few ms of unloaded times)

If you do have bufferbloat problems, the ping times will skyrocket.

slide 6 of this presentation shows the difference: http://snapon.lab.bufferbloat.net/~d/Presos/CaseForCompre...

The bufferbloat development has been happening as part of Cerowrt (with Dave Taht doing the vast majority of the work with virtually no financial support), so it has the latest and greatest improvements :-)

It's not really something that you can take care of with configuration. You can shrink your buffer allocations down a bit, but it's not possible to configure them to a point where you both get good throughput with small packets and good latency in the face of large packets.

the changes to the kernel to do buffers by bytes rather than packet count (BQL) makes a huge difference and lets the buffer sizes be sized to reasonable levels.

fq_codel queue management also makes a huge difference.

both of these are in the core kernel now (I don't remember what version each of them got in and on by default)

But it doesn't help you that much to have a bloat-free desktop and server if the router in between them is bloated. The most critical point to be de-bloated is the router that connects a high-speed network to a slow network (something like your access point connecting your gig-E wired network to your 10Mb Internet connection)

Wireless networks add a lot more problems to this, and the wireless drivers do a lot of buffering that's hidden from the OS, which just makes it worse. Debloating the wireless stack is on the TODO list for CeroWRT

Does this answer a lot of your questions?

The EFF's open wireless router project

jackb — Fri, 25 Jul 2014 02:55:01 +0000

So I've been hearing about bufferbloat for years, and here is a project that claims to have the "latest bufferbloat fixes" and yet the entire thing is still a mystery.

I don't use wireless routers - I have a PC that servers as a firewall/router, and a wifi AP for wireless devices to connect through.

How would I know if I have bufferbloat problems? If I want to fix it, are there any kernel options I should enable/disable? Is there any kind of user space configuration involved, or is simply compiling in something like fq_codel enough?

For all the talk about bufferbloat, there's little in the way of tutorials or instructions available.

The EFF's open wireless router project

dmarch — Thu, 24 Jul 2014 23:25:01 +0000

Well the main idea I had in mind with Tor is to help reduce liability to the person operating the open WIFI router and it might also help prevent an ISP from TOSing them for having the open WIFI.

For instance I would run an open WIFI router gladly with all connections going through Tor. But without Tor I am too afraid of people accessing highly illegal pornographic content and then getting in a huge legal mess.

The EFF's open wireless router project

fb — Thu, 24 Jul 2014 19:30:40 +0000

Hi arnd, I need to thank you again for the multiple informative posts on newer ARM based platforms that are getting used for routers and for your comments on their software support. Thank you! Very sincerely appreciated!

The EFF's open wireless router project

intgr — Thu, 24 Jul 2014 07:16:25 +0000

That's an easy claim to make, but is there any evidence, at all, to support this?

The EFF's open wireless router project

nbd — Wed, 23 Jul 2014 15:41:35 +0000

You won't be able to use b43 on any Broadcom wifi chip that even remotely counts as recent.

As for the Marvell wifi, it's probably possible to add support for the chip to mwl8k (not mwifiex). I don't know if anybody is going to do that though.
The chip doesn't seem to be used in a lot of devices, and all the interesting bits are of course hidden away in a crappy firmware blob.

The EFF's open wireless router project

arnd — Wed, 23 Jul 2014 15:35:36 +0000

FWIW, I've looked at the firmware image for Archer C8: It's bcm4709 (same chip as bcm4708, but running 1 GHz) with 16MB flash, so probably not worth waiting for, because there are lots of other models out already with that chip and more flash.

For the Marvel wlan driver, the model is 88w8864 and it's related to earlier ones for which some reverse-engineering has been done in the past. The wifi firmware now runs on a Cortex-A9, which is probably faster than a lot of router SoCs.

The EFF's open wireless router project

gdt — Wed, 23 Jul 2014 12:54:45 +0000

Tor isn't necessarily a security win, because the NSA run a high proportion of the exit nodes.

The EFF's open wireless router project

ranga — Wed, 23 Jul 2014 03:27:59 +0000

Support for secure upgrade of the entire firmware image is in the current EFF router software release. This security is against a threat model that will be described in the threat model document on the OpenWireless github repo (TODO).

The need to upgrade the entire image is a problem for people who customize the router by installing their own pkgs. Since we use the sysupgrade utility built into OpenWRT, such users will need to re-install their packages manually. So even if we wanted to just upgrade the linux kernel we would have to make available a full new image. Similar comment applies to upgrading a specific pkg currently if it is to be done by the EFF through the current automated update mechanism. Users are of course free to manually upgrade specific pkgs themselves with "opkg upgrade pkg1 pkg2 ...".

We would like to move to a system where kernel or individual packages are automatically upgraded. We don't currently have a design for this and will review the current activity in OpenWRT mentioned by Dave above and try to arrive at a solution down the road. Resolving this problem is not a high priority item for us currently.

More concerning is the possibility of routers getting "bricked" during an upgrade. We will be adding the ability to gather "bricking rate" to see whether the current upgrade mechanism is something we can live with. Ideally we would be able to have two copies of the image, with one being live and would only upgrade the backup copy. Then if an upgrade fails we would always be able to boot up into the functioning copy etc. Given the flash of 16MB on the Netgear 3800 we can't implement this yet. In a more modern platform we expect this will be possible.

Dave describes the relationship between the EFF router software release and CeroWRT well. We are focused on innovating in the security of SOHO routers and in making the sharing of the WiFi with guests worry free and easier, and in protecting the privacy of guests themselves. We look to CeroWRT to continue its innovation in the networking and queuing realms and to continue to improve performance and internet experience. Such a division of labor, we hope will result in a healthy exchange of code and ideas between the two projects.

The EFF's open wireless router project

jsha — Tue, 22 Jul 2014 22:24:43 +0000

We do have a warning, under 'Terms of Service considerations' at https://openwireless.org/. We are also calling on ISPs to explicitly permit open wireless networks.

wndr3800

arnd — Tue, 22 Jul 2014 22:19:13 +0000

I've bought the wndr3800 myself two years ago because of CeroWRT support and have been fairly happy with it, except that I'd prefer an ARM CPU core since that's what I work on in the kernel ;-)

My prediction is that over the next three years, most of the high-end routers will move to ARM CPU cores, now that five of the main SoC vendors in this area (Qualcomm, Mediatek, Broadcom, Marvell and Realtek, no idea about lantiq or others) all have either products out or announced licenses for CPU cores. The highly integrated low-end will stay with MIPS24K/74K but not move on to faster MIPS cores (Aptiv/Warrior).

This means you basically have the choice between the qca9558 or similar as the last of its kind with high compatibility to wndr3800 on the one side, or a completely new platform like the ipq8064 that uses the same network drivers but shares nothing else on the other side.

wndr3800

dlang — Tue, 22 Jul 2014 22:04:12 +0000

> Secondly, many of the "newer chipsets", contained cost reductions that bothered me, for example clock speeds were reduced by 10-20% in later chipsets). I wanted to hit new performance targets, not get slower...

especially given the fact that the current CPU is running into performance bottlenecks on high-speed home connections today.

The EFF's open wireless router project

dlang — Tue, 22 Jul 2014 22:02:14 +0000

The problem is that in many cases the firmware implements very large buggers, so you can't assume that you can ignore the firmware.

The firmware that has been opened shows this to be the case repeatedly, so there's no reason to believe that the closed firmware is going to be better.

binary blobs

jsha — Tue, 22 Jul 2014 21:51:07 +0000

> insistence on no binary blobs is not something that other projects might care about, in particular. (have no idea what the EFF stance is on this issue, for example.)

I work for EFF, and I can say: We definitely also insist on a platform with no binary blobs. It's vital to both security and user freedom, and is part of the reason we chose CeroWRT and the WNDR3800 as our base platform.

The EFF's open wireless router project

arnd — Tue, 22 Jul 2014 20:14:54 +0000

This is what I know about the ARM based platforms with 802.11ac support:

Marvell armada-xp (WRT1900AC):
* CPU is dual-core Marvell PJ4 (ARMv7)
* Ethernet driver is drivers/net/ethernet/marvell/mvneta.c, I see no hint of blobs in there.
* wireless driver is not known yet, probably a variation of drivers/net/wireless/mwifiex, which comes with a blob, see also https://forum.openwrt.org/viewtopic.php?pid=240734

Atheros ipq8064 (Archer C8?):
* CPU is dual-core Qualcomm Krait-300 (ARMv7)
* Ethernet driver is likely to be drivers/net/ethernet/atheros/atl1c/ (no blobs that I can see)
* Wireless is almost certainly ath10k

Broadcom bcm4708 (R6250 and others):
* CPU is dual-core ARM Cortex-A9 (ARMv7)
* Ethernet driver is drivers/net/ethernet/broadcom/bgmac.c (no blobs)
* wireless driver is drivers/net/wireless/b43 (with blobs)

wndr3800

fb — Tue, 22 Jul 2014 19:27:12 +0000

> I think fb was confusing wndr3700 and wndr3800 in the comment above

Indeed. Thanks for noticing and bringing it up.

wndr3800

mtaht — Tue, 22 Jul 2014 19:23:05 +0000

The wndr3800 was used by cerowrt, samknows & FCC, the bismark project, and innumerable other science and measurement projects. It had a very high build quality, had enough flash for tools, and sufficient ram as well, along with a huge development community centered around the chipset that didn't exist (at the time) for (examples) the iwl products or ra or broadcom products. It has been nearly unbrickable, and I'm glad we chose it 3 years back...

but... I have been painfully aware of how rare the wndr3800s for the past year. However, the ar71xx/ath9k chipset that the wndr3800 is based on is used by *100s* of other manufacturers products (buffalo, tp-link, ubnt, etc), and the successor chipsets from atheros are largely similar, so... there are 100s more products to choose from with very few changes to the build, if we were to switch to something being currently manufactured.

(I fairly regularly do builds for the ubnt picostation and nanostation, as well as for a few other more current and widely available products... but haven't found one - or enough support from the manufacturer. Secondly, many of the "newer chipsets", contained cost reductions that bothered me, for example clock speeds were reduced by 10-20% in later chipsets). I wanted to hit new performance targets, not get slower...

And we'd (cerowrt) like to have a new platform to deploy for 3+ years, so we can get good data back, and that's kind of hard to figure out at the moment as the industry switches over to 802.11ac and the resulting chaos in the chipsets and raw quality of the code - (this disruption is also a good thing, in that things like "streamboost" are entering that market, we have a chance to influence future designs, etc)

Frankly, given all the help Netgear has been (e.g. none), I'm planning on finding another board from another vendor, rather than fix their stuff anymore. I have some hope we'll work with multiple other projects including openwireless.org and others in this space (very long list), to choose a chipset and vendor that we can work with, to further the advancement of the internet... but every project has different goals, and our (bufferbloat.net's) insistence on no binary blobs is not something that other projects might care about, in particular. (have no idea what the EFF stance is on this issue, for example.)

The 3 years of work in openwrt/cerowrt/etc has led to a home router build that works really well with ipv6, and I do hope tons of people iron out the last bugs in barrier breaker - on any of the 100s of platforms available - to take full advantage of ipv6 as it rolls out.

http://corporate.comcast.com/comcast-voices/comcast-reach...

The EFF's open wireless router project

johill — Tue, 22 Jul 2014 19:20:45 +0000

Intel, Broadcom, and others have binary blobs for wifi firmware, but if you're looking for bufferbloat only you have to ask yourself what that firmware can do. Intel's and Broadcom's don't really buffer frames - if they're on the HW queue they're going out to the air ASAP.

The EFF's open wireless router project

luto — Tue, 22 Jul 2014 18:57:16 +0000

It might be worth contacting the Candela people if you're really interested in ath10k. They have firmware source.

But yes, blobless is clearly preferable.

The EFF's open wireless router project

mtaht — Tue, 22 Jul 2014 18:53:48 +0000

The most major requirement of the CeroWrt project is zero binary blobs. We are here to strip the bufferbloat out of everything, and a binary blob firmware for wifi, in particular, is unacceptable, as that is precisely the area of the internet we are trying to fix.

The ath10k at least, has firmware that can be obtained and may be open sourced one day, so we have some hope for that. I have been playing with the archer c7 v2 in particular - but the cpu is kind of weak. I have fiddled with a couple arm based products and am somewhat encouraged, but the ethernet interfaces are behind blobs we cant fix and exhibit bufferbloat....

The ath9k is more or less the "reference standard" for open linux wireless drivers, and that will probably become the focus of the upcoming make-wifi-fast effort. (and it's the other card in the archer c7v2)

Now, if another chipset with entirely open drivers and firmware arrives, we'd take it under consideration. Does that broadcom have binary blobs in the ethernet or wifi drivers?

The EFF's open wireless router project

NightMonkey — Tue, 22 Jul 2014 17:08:17 +0000

Tomato by Shibby still does. :)

wndr3800

corbet — Tue, 22 Jul 2014 15:33:44 +0000

Um, a quick search on US Amazon turns up this offering. I would not be at all surprised if some people were buying this to try to put openwireless on it. That is not going to lead to happy testers...

wndr3800

arnd — Tue, 22 Jul 2014 15:31:18 +0000

I think fb was confusing wndr3700 and wndr3800 in the comment above: wndr3800 and wndr3700v1/v2 are the same hardware with different amounts of memory. They are supported by CeroWRT but are no longer produced as far as I can tell. The recommendation is to buy wndr3800 because you know exactly what you get then -- there is only one version of this device.

For wndr3700, there are also v3 and v4 versions. v4 is actually much nicer hardware (same as wndr4300) than v2, is available for a reasonable price and has some OpenWRT support in the latest snapshots but doesn't work with CeroWRT because it requires a separate image.

The main disadvantage of all of the supported systems is that they are two-generation old high-end devices: a new mid-range router (e.g. TL-WDR3600) can do the same things for less, while a new 802.11ac router (e.g. Archer C7) would be better for a similar price.

The EFF's open wireless router project

tialaramex — Tue, 22 Jul 2014 15:30:52 +0000

CeroWRT is not necessarily open-as-in-no-password, but that's a big element of this EFF 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.

wndr3800

fb — Tue, 22 Jul 2014 15:27:01 +0000

PS: Where I wrote Amazon, you folks should read Amazon.FR :-P

wndr3800

fb — Tue, 22 Jul 2014 15:25:54 +0000

The market is well aware of this, last time I looked around (6 months ago? Probably more), I could find new WNDR3800 but it surely commanded a very steep price. Today a cursory (Amazon) search did not show anyone selling it.

wndr3800

corbet — Tue, 22 Jul 2014 14:51:49 +0000

So wait...are you saying that if people run out to buy WNDR3800 devices to play with this software they are going to end up with a doorstop? If so, that seems like something to scream from the rooftops, not to bury in a comment stream...?