Ask Slashdot: Which Router Firmware For Bandwidth Management?

First time accepted submitter DeathByLlama (2813725) writes "Years ago I made the switch from DD-WRT to Tomato firmware for my Linksys router. I lost a couple features, but gained one of the best QoS and bandwidth management systems I have seen on a router to date. Admins can see graphs of current and historical bandwidth usage by IP, set minimum and maximum bandwidth limits by IP range, setup QoS rules, and see and filter graphs and lists of current connections by usage, class or source/destination — all from an elegantly designed GUI. This has allowed me to easily and intelligently allocate and adjust my network's bandwidth; when there is a problem, I can see where it's coming from and create rules around it. I'm currently using the Toastman's VPN Tomato firmware, which has about everything that I would want, except for one key thing: support for ARM-based routers (only Broadcom is supported). I have seen other firmware projects being actively developed in the last few years, so in picking a new 802.11ac router, I need to decide whether Tomato support is a deal-breaker. With solid bandwidth management as a priority, what firmware would you recommend? Stock Asuswrt? Asuswrt-Merlin? OpenWRT? DD-WRT? Tomato? _____?"

Comments

cfw

[hypergreatthing]

toastman?
Aren't those builds really, really old?
If you're going to use tomatousb, use shibby.
Use merlin if you want custom firmware as close to stock looking as possible.

OpenWRT all the way

[Anonymous Coward]

OpenWRT Is a real linux distro with package mgmt that spun out from the DD-WRT project. DD-WRT is really designed around the wrt54g and never really broke away from that model. Tomato and some other projects are front ends to OpenWRT. I think all the movement these days in this space comes from OpenWRT.

Re:OpenWRT all the way

[AlphaWolf_HK]

Tomato is a fork of HyperWRT, not OpenWRT, and in fact has nothing to do with it. HyperWRT itself was a fork of the stock WRT54g firmware.

OpenWRT is good, but not for the faint of heart. Tomato is suitable for everybody though, and in fact is IMO THE firmware to use if you are just all around unsure of which one to pick. I'd use Tomato over DD-WRT for many reasons, but the biggest one being a much cleaner UI (also in spite of what TFS says, Tomato actually has all of the same features as DD-WRT in addition to some extras; rather the author probably just isn't sure where to find the features he thought was missing.) Pretty much the only case I could ever think to take DD-WRT over tomato is that DD-WRT works on some hardware that Tomato does not; however if your router supports Tomato, there's no reason not to use it over DD-WRT.

Re:OpenWRT all the way

[AlphaWolf_HK]

Dunno but I wouldn't use that anyways. Without even looking it up, I'd actually wager that Tomato 1.27 was last updated before the patch that made heartbleed possible ever existed, so it isn't even relevant.

Tomato Shibby on the other hand is what you'd want, and yes, it definitely has that particular issue resolved as of the latest release:

http://tomato.groov.pl/?p=595

Re:Pfsense

[bill_mcgonigle]

In your haste to get FP, you missed the requirements in TFS.

I use pfSense extensively, but its bandwidth controls are not easy to use, and nobody would recommend deploying it on ARM in 2014.

You could give Gargoyle a try....

[SQLGuru]

You could give Gargoyle a try......
http://www.gargoyle-router.com...

Shibby tomato mod

[Anonymous Coward]

Shibby recently announced an ARM branch of his tomato mod.
http://tomato.groov.pl/?p=590

The Shibby mod is fairly active, with updates every couple months. Use 117 for the OpenSSL heartbleed fix.

Out of scope I think but....

[Raxxon]

Personally I've been enjoying Mikrotik. I don't think it's in the range for you because I'm 98% sure you can't load it on your hardware (I have a RouterBoard-based router/AP) but it's been damn solid and gives me WAY more features that I really plan on using... If you plan on upgrading routers at some point I'd suggest looking at them.

Re:Out of scope I think but....

[BillTheKatt]

I second Mikrotik. I've deployed them to all the small branches in our company and at the core as well. You get an amazing amount of features for the price. You can also get smaller units that are perfect for home use and cost around the same as a home AP.

I'd seriously think about a dedicated router

[Sycraft-fu]

The problem is all those consumer wifi+router deals tend to have kinda crap firmware. While there are, in theory, OSS alternatives they seem to be less than speedy with the updates and support for new hardware.

So I'd look elsewhere. The two things I'd put at the top of your list:

Monowall, on an APU.1C. It is like $150 for the unit, and then $20-30 for an enclosure and CF card. Monowall should support everything you need, it is really feature rich, is pretty easy to use, and the APU.1C is fast enough it shouldn't have issues even with fairly fast internet.

A Ubiquiti Edgerouter Lite. This is a funny looking and named lil' router with quite a bit of performance under the hood, thanks to the hardware routing logic its chip has. $100 and it can push gigabit speeds for basic routing setups. It is also extremely configurable, since it runs a Vayetta fork, which is a Linux OS customized for routing. However to configure the kind of things you want, you might have to hop in to the CLI, I don't know that the GUI has what you need. It supports that though, and you can even hop out of the specialized routing CLI and get a regular Linux prompt where you can install packages and such.

If you want a more supported solution, you could look at a Cisco RV320. Costs like $200 and is a fast lil' wired router (uses the same basic chip as the Edgerouter, just slower). I haven't used one but I'm given to understand you can make them do a lot. Sounds like they firmware may be a little flakey though.

You then just set your consumer WAP+router in to "access point" mode and have it just do the wireless functions.

This is all more expensive and complex than just running on a consumer WAP+router, but more likely to be able to do what you require. It also means you can change out components without as much trouble. Like say your WAP gets flakey, and you want a new one with the latest technology. No problem, just buy it. You don't have to worry if it supports the routing features you need because it doesn't do that for you.

If you are stuck on doing an all in one, then you could look at a Netgear Nighthawk R7000 or the new Linksys WRT1900AC. The Netgear does have bandwidth management and QoS in its native firmware (I haven't played with the features, but I can confirm they are there as I own one) and there is a "myopenrouter" site that has OSS firmware for it (ddwrt mod I think). The Linksys router supposedly is going to have OpenWRT support soon as Linksys worked directly with the OpenWRT team for it.

Re:I'd seriously think about a dedicated router

[greg1104]

I am highly skeptical of claims toward the OSS router firmware scene being less useful than manufacturer provided ones. You're right that speed to support new features lags in OSS, but who cares? I buy the router based on the hardware compatibility list, not the other way around. Reliability and longevity is a lot more important to me than the new shiny. You're also right that today it may be difficult to meet all the requirements with open code, with AC support being a sore point. I'd use that as a reason to delay the purchase until i can though, not as an excuse to head any distance back toward less open development models.

I still have two Linksys WRT54GL units left in operation. Long after Cisco/Linksys stopped worrying about that hardware, I was happily served by the software communities around DD-WRT and then Tomato. Manufacturers like Ubiquiti are useful to me to the extent they embrace that philosophy. In the last year Linksys seems to be moving back in the right direction again. We'll see how that plays out.

I'm also skeptical that having two points of failure in a network can ever be more reliable than one, which complicates your flexibility argument. Whenever I decouple routing and wireless onto separate boxes, problem resolution is harder compared to having a single unit to swap out. One of the reasons I ended up with so many cheap WRT54GL units is that I could easily have a spare with a duplicated configuration for every install. At any scent of trouble, I just replaced the whole unit.

Mikrotik?

[imag0]

I've had really good luck with my RB2011UAS-2HND-IN from Mikrotik. It's pretty easy to configure queues by interface, all the way down to tagging the packets and throttling down to individual TCP/UDP ports.

Costs slightly more than a cheap home router, but you have something pretty sturdy and extremely flexible to work with.

Re:Pfsense

[AaronLS]

From the perspective of the rest of the network, the architecture of the router is pretty irrelevant, but I understand why they might want ARM but they didn't identify those reasons. I have a feeling their desire for ARM is not a direct requirement, but an indirect requirement from a desire for some of the attributes of ARM. They might find that an Intel Atom box meets the same needs. Low profile, low heat, cheap, passive heat sinks(eliminates risk of fan failure).

I went with PFSense + Intel Atom box and am happy. The web interface is pretty straightforward. Getting setup initially is a bit of a pain, attaching SSD/Card to one box and flashing, etc. Some of the documentation is terrible.

Agreed that certain scenarios are indeed poorly documented and/or pain to setup. Not that pfsense supports those scenarios poorly, but you just have to dig into command line/config editing and really have to know what you are doing.

Re:Pfsense

[omnichad]

nobody would recommend deploying it on ARM in 2014

Guess they were wrong on one point.

Seconded.

[Slartibartfast]

Before I posted, I searched to see if someone else had mentioned Gargoyle already. And, indeed... someone had. I really like it. It's *NOT* as powerful as (say) OpenWRT, but jeepers, it's got a nice GUI and pretty much all the features you discuss, and a decent (but not great) slate of plugins. I'd definitely recommend kicking the tires on it.

NONE, get a smart switch

[spire3661]

Seriously, dont rely on a consumer grade router for this, add a consumer grade managed switch for it. I use a Netgear GS108T. That way your router can keeps its CPU dedicated to encryption and throughput. I'm sure there are some badass routers out there, but this is an easy and relatively cheap add-on that works for sure.

Re:NONE, get a smart switch

[greg1104]

I don't know when you got your Netgear GS108T units at, but somewhere in that product's lifecycle it turned bad. My experience mirrors the highest rated critical review at Newegg, circa 2011 and talking about the decline. There are several reasons why the current version of the product only averages 3 stars there, and why 28% of buyers are giving this 1 star now. I have a good, older GS108T and a worthless newer one. Each firmware update is rolling the dice.

That's actually the core argument behind why I won't buy a manufacturer only firmware network product anymore. When the Netgear firmware on a Netgear product is broken and that's the only option, you now have a paperweight. The Tomato firmware upgrade scene for routers is more complicated than I'd like sometimes, but it always gives you multiple options. I'm using an Asus RT-N66 right now, and I don't ever expect its CPU performance is going to be a bottleneck for me. I'm using the Netgear switches only to add more wired ports than it supports.

Re:Pfsense

[Bengie]

Someone recently asked this on the PFSense forums and the response was the Tomato's QoS is too simplified. They could create a wrapper to translate QoS style GUI into PFSense settings, but it wouldn't play well if some decided to make any manual changes. PFSense has a much more powerful QoS.

Almost all router bandwidth management is shit.

[tlambert]

Almost all router bandwidth management is shit.

Bandwidth management schemes currently used by everything you mention are all base on rate limiting packet delivery based on some mythical QoS value, and they ignore the actual problem that the people who are using these things are attempting (and failing) to address.

The problem is that the point of a border routers is to hook a slower border uplink to a faster interior connection; on the other end of the slower uplink, you have a faster ISP data rate. In other words, you have a gigabit network in your house, and the ISP has a gigabit network at their DSLAM, but your DSL line sure as hell is *NOT* a gigabit link.

What that means is that software that attempts to "shape" packets ignores an upstream-downloads or a downstream-uploads ability to overwhelm the available packet buffers on the high speed side of the link when communicating to the low speed side of the link.

So you can start streaming a video down, and then start an FTP transfer, and your upstream router at the ISP is going to have its buffers full of untransmitted FTP download packets worth of data, instead of your streaming video data, and it doesn't matter how bitchy you are about letting those upstream FTP packets through your router on your downstream side of the link, it's not going to matter to the video stream, since all of the upstream router buffers that you want used for your video are already full of FTP data that you don't want to receive yet.

The correct thing to do is to have your border router lie about available TCP window size to the router on the other end, so that all intermediate routers between that router and the system transmitting the FTP packets in the first place also lie about how full the window is, and the intermediate routers don't end up with full input packet buffers with nowhere to send them in the first place.

Does your border router do this? No? Then your QoS software and AltQ and other "packet shaping" software is shit. Your upstream routers high speed input buffers are going to end up packed full of packets you want less, and you will be receiver live-locked and the packets that you *do* want won't get through to you because of that.

You can either believe this, or you can get a shitty router and not get the performance you expect as the QoS software fails to work.

Then you can read the Jeffrey Mogul paper from DEC Western Research Labs from 1997 here: http://citeseerx.ist.psu.edu/v... ...after which, you should probably ask yourselves why CS students don't read research papers, and are still trying to solve problems which were understood 27 years ago, and more or less solved 17 years ago, but still have yet to make their way into a commercial operating system.

BTW: I also highly recommend the Peter Druschel/Guarav Banga paper from Rice University in 1996 on Lazy Receiver Processing, since most servers are still screwed by data buss bandwidth when it comes to getting more packets than they can deal with, either as a DOS technique against the server, or because they are simply overloaded. Most ethernet firmware is also shit unless it's been written to not transfer data unless you tell it it's OK, separately from the actual interrupt acknowledgement. If you're interested, that paper's here: http://citeseerx.ist.psu.edu/v... and I expect that we will be discussing that problem in 2024 when someone decides it's actually a problem for them.

Re:Almost all router bandwidth management is shit.

[tlambert]

OK, as someone who has been trying different methods of QoS over the past years, with varying levels of success, mainly to have my VoIP phone rock solid over DSL, I'm very interested in what you're saying.

Is there a reason this approach hasn't been implemented yet? Does it break something? If my router is lying to one my upstream router about its TCP window size, wouldn't that impact both the FTP and video stream?

You lie about the window size on a per connection basis, so no, since it's not a global policy, it's a resource policy by application, and potentially by port/IP tuple, so it's not a problem. The point is to keep the upstream router packet buffers relatively empty so that the packets you want don't have to be RED-queued. Nothing breaks because of it.

It generally won't work, unless everyone "plays fair", and the port overcommit ratio for upstream vs. downstream bandwidth is relatively low. As the downstream data rate increases to approach the upstream data rate, the technique loses value, unless you get rid of overcommit, or do it on a per-customer "flow" basis (as opposed to a per virtual circuit "flow" basis) within the upstream router itself, or move to a "resource container" or similar approach for buffer ratio allocation in the upstream router.

So in theory, Comcast (as an example) could do it if they made everyone use the router they supplied, and their routers all participates in limiting upstream buffer impact.

Maybe the next time they replace everyone's cable modems, they'll bother to do it?

Without the deployed infrastructure, it's easier to RED-queue and just intentionally drop packets, forcing a client to request a retransmit as a means of source-quenching traffic. This wastes a lot of buffers, but they probabilistically get through, and for streaming video, that's good enough if there's a lot of client overbuffering going on before playback starts (JWZPlayer, for example, is a common player used for pirated content that will habitually under-buffer so intentional drops tend to make it choppy).

For VOIP, unfortunately, forced retransmit causes things to just typically suck, unless you use a sideband protocol instead, where the router at the one hop upstream peer agrees to reserve buffers for specifically that traffic. This is why Skype is terrible, but your phone calls over your wall jacks which are actually wired to the same packet interface instead of a POTS line are practically as good as a land line or cell phone.

Google hangouts tend to get away with it because they are predominantly broadcast, and are either "gossip"-based CSMA/CD (ALOHA style) networks between participants (i.e. people talk over each other, or wait until the other end is done before talking themselves). It means they tolerate large latencies in which 1:1 VOIP/Skype connections won't. They can be a bit of a PITA for conference calls because of that (Google uses it internally, and gets away with it, but mostly because Google has its own, parallel Internet, including transoceanic fibers), but if Google employees never see the problem, they never fix the problem. Same way any company that assumes local-equivalent bandwidth works as well for their customers as it does for them (free hint to Microsoft inre: Office 386 there).

whatever you use, use HFSC

[HighBit]

I just use a fanless box (made by cappuccino pc, but there are other vendors too) with several ethernet ports (at least two for WAN and LAN) running standard debian.

But then I apply linux's best-kept traffic shaping secret, HFSC. See https://gist.github.com/eqhmco... .You should be able to apply that same script to any linux distro or mini-distro.

The idea is you do AQM first, and QoS only later or even not at all, to get both low-latency for interactive TCP sessions and throughput for bulk session.

AQM is all about dropping packets to throttle TCP and prevent it from overwhelming your ISP's bandwidth caps. When done properly, it works amazingly well, and HFSC + SFQ can do it properly.