Ask Slashdot: Which Router Firmware For Bandwidth Management? 104
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? _____?"
Re:Pfsense (Score:5, Interesting)
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.
Re: (Score:3)
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
Re: (Score:3)
nobody would recommend deploying it on ARM in 2014
Guess they were wrong on one point.
Re: (Score:3)
Re: (Score:2)
Especially since pfsense is x86 ONLY. So yeah.
cfw (Score:4, Informative)
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.
Re: (Score:1)
I don't know. I don't think a build on Monday is really really old.
http://www.4shared.com/dir/v1BuINP3/Toastman_Builds.html#dir=t6vb5PBo
Re: (Score:1)
Re: (Score:2)
I use shibby builds and they are nice. Toastman had a changelog dated for the 14th so not that old. I believe shibby lists toastman as a contributor for some recent features also...
Re: (Score:1)
http://at.prahec.com/ [prahec.com]
OpenWRT all the way (Score:4, Informative)
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: (Score:2)
OpenWRT rocks, but as far as I am aware, there is no support for the type of bandwidth management the OP is after within the web interface. I'm sure you can achieve the same control from the CLI with a few extra packages and command line magic, but it sounds like the OP specifically wants all this to be done from the web interface.
Re:OpenWRT all the way (Score:5, Informative)
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: (Score:1)
Re:OpenWRT all the way (Score:5, Informative)
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 [groov.pl]
Re: (Score:1)
Re: (Score:2)
I'm still waiting for my 5 year old Linksys WRT320N to be supported by OpenWRT. Still in progress.
However, it's been supported by DD-WRT for a number of years.
From where I sit the only movement from OpenWRT is of the bowel variety and apparently pretty constipated from what I can see.
You could give Gargoyle a try.... (Score:4, Interesting)
You could give Gargoyle a try......
http://www.gargoyle-router.com... [gargoyle-router.com]
Seconded. (Score:3)
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.
Re: (Score:2)
Re: (Score:1)
I also second this suggestion, I have been using Gargoyle for a while now (over a year) and bandwidth management is simple and it actually works.
Shibby tomato mod (Score:2, Informative)
Shibby recently announced an ARM branch of his tomato mod.
http://tomato.groov.pl/?p=590 [groov.pl]
The Shibby mod is fairly active, with updates every couple months. Use 117 for the OpenSSL heartbleed fix.
Out of scope I think but.... (Score:5, Informative)
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: (Score:3, Interesting)
Re: (Score:1)
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'm sorry, but if you're doing Mikrotik at the core... your entire business is tiny.
Re: (Score:2)
You can load it on your PC:
http://www.mikrotik.com/softwa... [mikrotik.com]
It can also be installed on a PC and will turn it into a router with all the necessary features - routing, firewall, bandwidth management, wireless access point, backhaul link, hotspot gateway, VPN server and more.
Re: (Score:2)
Yes, but AFAIK you can't load it onto the same consumer router hardware that DDWRT was popularized on which is why I think my comment was technically out of scope for the discussion...
IPv6 support (Score:2)
I checked out the wiki page [wikipedia.org], and looks like out of the 11 models, 6 support IPv6 (and a few other features such as VLANs, 5GHz) while the other 5 don't. How exactly does one know if one is getting Tomato which ones do? Also, the bandwidth management & superior QoS - is that there for both IPv4 AND IPv6? Also, except Shibby, none of them have IPSEC support.
Incidentally, which CPU is Tomato geared towards? MIPS? Given that it's there for Broadcom routers?
Toastman Tomato (Score:1)
I'd seriously think about a dedicated router (Score:5, Interesting)
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.
Using DD-WRT (Kong latest "old" driver version) (Score:2)
on a Netgear R6300 and it has been very fast, great with signal quality, and the QoS features are working as expected.
Both the R6250 and R6300 have a dual-core 800MHz CPU, so they have the power to handle a decent QoS requirement without bogging down potential throughput too much. I'm satisfied, and it wasn't that expensive. If your situation isn't too terribly complex (many dozens of users and extensive QoS rules) then it might be a good choice.
The R7000 is even faster and supports external antennas, so I
Re: (Score:2)
WHERE HAVE YOU BEEN ALL MY LIFE???
I must have been using the wrong search terms.. I scoured NewEgg up and down for something exactly like that Edgerouter Lite but kept coming up empty. I knew there had to be something between some crappy consumer router that I prayed I could get a halfway-decent firmware running on, an uber-expensive business-class rackmount unit, and building my own micro PC. Many thanks, I'm ordering one now...
Glad to help (Score:2)
It's a pretty new product, which is why you haven't heard of it. It isn't the greatest thing EVAR, as its web UI could use some work, and some of the features it has can hit the limited CPU pretty hard (VLANs and encryption notably) but it is pretty damn good.
It is what lives at the edge of my home network, and I'm real happy with it.
They also make larger models, should you have the need.
Re: (Score:3)
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 re
Re: (Score:2)
Ummm, if you bothered more than a cursory glance at my thing you'd notice I AM advocating open solutions. Monowall is FreeBSD, with some mods and a nice WebUI stuck on it for configuration. EdgeOS, that runs on the ERL, is a fork of Vayetta, which is a fork/mod of Debian.
Both are open solutions but both are under active development and support by a team. Hence I'm a pretty big fan. Monowall was last updated in January, and they still support their legacy version for old hardware like WRAP systems, and their
Re: (Score:2)
Re: (Score:2)
I concur.
Been running m0n0wall for about 5 years on an Alix board and for many years before that on a P3 500. Never had to reboot it once. When my WAP54g started to flake out I replaced it with an Ubiquiti UniFi UAP which blows the old Linksys WAP54g away. The old 54g could barely push a signal 2 floors down to the kitchen, living room, and the basement was a dead zone. Now I have a strong signal throughout the house. It has a boat load of features and is 70 bucks on newegg.
I did not know about the APU.1C,
Re: (Score:2)
If you like Ubiquiti you could look at their Edgerouter Lite. I'm real happy with mine. $100 and it'll outperform monowall and pfsense on way more expensive hardware. With a basic NAT setup, plus SPI firewall (the basic "permit established and related, drop others" rules) I've measured it at over 500mbps throughput. It probably would do faster, it's CPU wasn't fully loaded, that is just as fast a test server as I could easily get to.
Now of course it is more on the routing, less on the firewall n' such so if
Mikrotik? (Score:5, Informative)
I've had really good luck with my RB2011UAS-2HND-IN [amazon.com] from Mikrotik [routerboard.com]. 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: (Score:2)
haha. See if this link works:
http://www.amazon.com/Mikrotik-Routerboard-RB2011UAS-2HND-IN-port-Ethernet/dp/B00BGIXOHQ [amazon.com]
At worst, you can just google for the model (RB2011UAS-2HND-IN). Pretty close to the top link
Re: (Score:1)
Amazon is in a death spiral, or is already dead to technical people? Dude, you know how to tell a funny story, I'll give you that. I am more troubled by Bezos's inconsistent stand on patents than knee-jerk characterization of his personal politics. Hint: is he a conservative Republican tool, or a super rich liberal [halfsigma.com]? Labels are so tricky.
tomato is old and rotten (Score:1)
tomato of is old they are still running k2.6.* no real progress has been made in terms of core functionality or fixes in -lit years
running QOS on a router is a silly idea gargoyel looks like something 1998 threw back
NONE, get a smart switch (Score:3)
Re: (Score:3)
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 [newegg.com], 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
Re: (Score:2)
dd-wrt works for me (Score:2)
The bufferbloat experimenters user cerowrt (Score:2)
OpenWRT on AR71XX hardware. (Score:2)
Only if you Pick AR71XX hardware though.
Which I use the WDR4300/TPLINK
Does an excellent job for managing QoS bandwidth in my house.
It has a nice GUI if you are not a technical person, and you can build the firmware source by yourself.
Almost all router bandwidth management is shit. (Score:5, Interesting)
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... [psu.edu] ...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... [psu.edu] and I expect that we will be discussing that problem in 2024 when someone decides it's actually a problem for them.
Re: (Score:1)
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?
Re: (Score:3)
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 downstre
QoS (Score:2)
TCP window sizes are on a per-connection basis, and obviously only affects TCP traffic. Most VoIP, gaming, and many common file sharing protocols don't use TCP so any of these would be unaffected by QoS using the above techniques. Also, having many multiple simultaneous TCP connections in the order of hundreds or thousands would also render this technique useless as you would need to shrink each window so small so in case they all filled up that you could respond in a reasonable time frame that latency (v
Re: (Score:2)
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.
What? The TCP window is meant to be negotiated only by the end points, not the routers. Core Internet routers don't care about TCP windows, that's layer 4, they just forward packets as fast as the can. If your downstream is getting overwhelmed, blame your your client OS or blame your ISP for over-subscribing too much, but don't blame the bandwidth differences.
If you have reliable download bandwidth, you shouldn't get latency issues. I have a baseline 12.5ms ping and it may "spike" to 30ms if I'm downloadi
Re: (Score:2)
Exactly. It's a problem of over buffering, not a lack of layering violation voodoo.
Research papers (Score:2)
Well, you might want to reread the first paper, which talks about live lock, which is a completely different cause than the one you describe, although similar. You seem to understand what the problem is, but I fail to see how you don't understand why your solution is so wrong.
Live lock as described in the paper you linked was solved over a decade ago using the method described in the paper under section 5.1, at least under windows. It's a standard property to rate limit the interrupts under heavy load, an
whatever you use, use HFSC (Score:3, Informative)
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... [github.com] .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.
Inbound trafic (Score:2)
Re: (Score:1)
Correct, once the packets are transmitted to you, its too late to apply QoS. The only thing you can control is your outbound requests which as it happens has a directly (although not linear) relationship to the amount of traffic sent back to you. This article outlines it brilliantly and is a must read for anyone using QoS on most consumer grade equipment:
http://www.linksysinfo.org/ind... [linksysinfo.org]
That said, classification of traffic is a much more challenging problem than QoS is and is what really needs to be addre
Re: (Score:1)
Why not RouterOS? (Score:1)
Fuck Routers, use a PC (Score:1)
Why do people spend $150 on a shitty little computer for which they then spend a week of their time trying to find an ideal firmware that manages to squeeze all of the features they want into a measly 4 MB of flash memory? ...and, fuck, last I checked I still couldn't find one with IPv6 support.
You know that PC you have in the closet that's always on, doing whatever the fuck important task you have it performing 24/7? For a mere $30 you can add a wireless network card, a second ethernet card, and a five po
iptables (Score:1)
I'm not sure I understand what you're asking, as I had to look up "dual-homed" as I've never heard the term before, and it sounds like a contradiction as the descriptions I'm seeing say that dual-homed hosts specifically don't route between their two network connections, which would rule out NAT.
Are you not aware of iptables? The kernel itself supports routing, or if you want a "dual-homed" host it also supports not routing, and it certainly does the stateful packet inspection necessary for NAT. There's n
Re: (Score:1)
I sure hope your $30 computer can handle 1gb of symmetrical bandwidth.
The computer isn't $30, that's just the cost of the components you need to use the computer as a router. As for whether it can handle it, my router (a WRT54GL) has a 200 MHz single-core CPUs. Anything it can do, my PC can do with 2% CPU utilization.
Anyway, my point is that most people who desire to load a custom firmware onto their router probably already have several computers anyway, and at least one that is always on for one reason or another. I personally just don't ever turn my computers off. I als
CeroWRT (Score:1)
CeroWRT [bufferbloat.net] could be worth a try. It's focused on traffic management, and has had good reviews in terms of handling throughput intelligently.
Hardware support is a bit limited though (it's beta and somewhat of a development/research platform, so they're not aiming for multi-platform support).
wrtbwmon (Score:2)
If you want to know how much each device uses by hour, day, month, then you need wrtbwmon.
It is a simple shell script that uses iptables, and runs on OpenWRT just fine.
wrtbwmon shows a graph for each device by MAC address. if you configure OpenWRT to use a fixed IP address per MAC address, then you see the device name that you assign on all graphs.
The original is here [google.com]. There is also this fork [gitorious.org].
I have modified it to run off of a USB memory stick, and store its data there as well. It does not use much storage,
All in one is a terrible way to go (Score:2)
If you want to do all in one ap/router/switch on consumer grade hardware, with a magical GUI to solve all your networking problems, you are going to be looking a long time. Most issues are due to exceeding the capacity of the horrible chip set.
Here is what I have setup at my house as my production network:
Pfsense edge router running on a foxcon barebones oem nettop.
|
Cisco 3560 core switch
|
WNDR3800 AP (multiple SSID/vlans trunked up to the Cisco core)
With this setup the household is happy. Wife, myself, room