What's new

Does alternative firmware break your router?

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

vnangia

Senior Member
Wonderful article - and definitely a useful piece to see what works and what doesn't in each firmware. I have to say though, the reason I swore off alternative firmwares was mainly for the speed (or lack thereof). For example, when I was still on a WRT54GL and using DD (v22, I think back then?), I saw about a third of the throughput that I saw with the stock. Did you run a similar speed test comparison while you had the different firmwares loaded?
 
Interesting article....
Gotta read it a second and possibly third time to digest it a bit more, or look at the tests thrown at it. But gotta head out for some onsites and go expand a network...

Years ago....in the old "early" days of home routers....the Linksys befsr and the wrt54 series....their firmware was quite....featureless, and it was well known that at least once a month or more, one had to go "reboot" the router to get the internet flowing smoothly again.

And back then I was big into online gaming, and read about the neat QoS features that 3rd party firmware had. So I got to playing with Hyper-WRT...and DD-WRT..and then found Tomato and that became my favorite.

Learned that reboots became a thing of the past.
Neat new features too...various VPN features, VLANs, wireless site surveys,

Back then...my home network had so much traffic on it, a load like a business network...I'd usually crush a home grade router and I had to turn towards *nix distros on x86 appliances...like IPCop, PFSense, m0n0wall, Endian, Smoothy, ...just to handle my loads. Regular home grade routers like Linksys, Netgear, DLink...I'd have them on their knees too much.

But a couple of years ago...I picked up a Cisco (Linksys really) e3000. For some reason my Atom D510 box was down (which was probably running PFSense at the time), or I had to use it for something else...so I converted my e3000 from access point mode...to be my primary router. Stock firmware. I was amazed at how well it handled the loads of my home network. (~11 devices...a son that torrents 24x7, he also online games about 20x7, has a laptop too, plus his smart phone, wife with her smartphone and laptop and Apple and iPad and daughter with her computer and ipad, me with my rig, laptop, smart phone....I'm sure I'm missing a few devices).

I had it running for a few months straight...stock firmware, no problems.
I saw Tomato firmware had a version released for it...so I stuck that on..just out of habit. But...really would have been fine with stock firmware.

What does this long winded blurb mean? Guess one might say...maybe manufacturers finally got their act together and are making some pretty stable firmware? I do wish they put in some more QoS features. Or maybe it's because the horsepower under the hood is getting better? Or a combination of both?

We do have those security concerns....Linksys got a pretty good reputation of having firmware on their popular home grade routers that was ripe with security holes. Recently we had that uPnP security issue circle around the media. I ran a test with my Tomato fired e3000 ..I had uPnP enabled...but I passed the test. Would the stock Stinksys firmware have passed the test?

My cliff notes...in the old days I definitely saw improvements both in stability, and performance...when replacing stock firmware with alternative firmware. Take the same network, same loads, same ISP.....instead of having to reboot a stock firmware fired router a couple of times a month, you could go for months and months or a year without reboots if you stuck on Tomato. (I still had to reboot with DD..but far less than stock...Tomato beat it for stability). I saw this behavior across many different routers back then.

But a couple of years ago, after the e3000 had been out for over a year maybe two...when I got it....was my first positive experience of stability with stock firmware. Flashing with tomato didn't increase performance or stability, seemed dead even.
 
Wonderful article - and definitely a useful piece to see what works and what doesn't in each firmware. I have to say though, the reason I swore off alternative firmwares was mainly for the speed (or lack thereof). For example, when I was still on a WRT54GL and using DD (v22, I think back then?), I saw about a third of the throughput that I saw with the stock. Did you run a similar speed test comparison while you had the different firmwares loaded?
I was going to do that, but had already done some of the tests when I thought of it. I tried to limit the flashes to a minimum to limit risk of bricking the router. The DD-WRT process in particular doesn't give me the warm fuzzies...
 
I was going to do that, but had already done some of the tests when I thought of it. I tried to limit the flashes to a minimum to limit risk of bricking the router. The DD-WRT process in particular doesn't give me the warm fuzzies...

Yup, definitely not. That's why I use stock. I've no idea how YeOldeStonecat got a higher performance out of Tomato than stock, but in general the open-source movement doesn't give priority to the "high speed" feature...

Well, if you still have the router in question to give it a shot, I think we'd all benefit from it.
 
I must say this certainly cements what I've already thought about DD-WRT. Don't get me wrong, I've used it before and loved it but for the past two years I've been using OpenWRT. It is FAR better than DD-WRT once you learn how to use the UCI and LuCI together. Support is rather minimal (it's definitely a DIY firmware) but muddling through it you tend to learn quickly.

I would hope this would be a wake-up call for DD-WRT founders, but they're probably too busy listening to their corporate sponsors than to refocus on the fan-base that made them popular. Oh well.

One thing to note - when you make firewall changes on these firmware, I would restart the router to make sure it boots up with that setting. I've found many times that a firewall change wouldn't take affect until the next restart.
 
One thing to note - when you make firewall changes on these firmware, I would restart the router to make sure it boots up with that setting. I've found many times that a firewall change wouldn't take affect until the next restart.
The first thing CDRouter does in a test sequence is prompt you to restart the router, which I did.
 
Same here. I think pfSense is the gold standard - pity it was not tested in this review.

I was just about to ask the very same thing! It would be good to compare a stock / modified firmware against an Linux distro like pfsense/monowall or some type of UTM like astaro or endian.
 
Like others, I will have to re-read this article a few more times to fully digest it. A few comments I'd like to bring (too bad Tim won't get the chance to test these theories):

1) Both Asuswrt-Merlin and Tomato (Shibby build) have recently switched to a much newer version of Miniupnpd (the uPNP server they use). Would have been interesting to see if this new build resolved any of the noted issues (altho Tomato Shibby's latest release has a broken config file for miniupnpd)

As for DD-WRT, it uses a completely different uPNP daemon (I forgot its name).

2) By default both Asuswrt and Asuswrt-Merlin (don't know about Tomato's default state) have a SIP helper enabled by default, which is meant to help in the routing of SIP clients toward a remote (outside of your network) PBX. Disabling the helper is possible in Tomato and Asuswrt-Merlin (and possible in Asuswrt through a manual nvram setting change). I wonder if having this helped enabled by default might not be responsible for at least some of these failures.

Very nice article. As I said, I'll have to re-digest it a few times. :)
 
speed and coverage

Yup, definitely not. That's why I use stock. I've no idea how YeOldeStonecat got a higher performance out of Tomato than stock, but in general the open-source movement doesn't give priority to the "high speed" feature...

Well, if you still have the router in question to give it a shot, I think we'd all benefit from it.

Thanks for the testing. I would second a comparison of speed and coverage.
I use Tomato mainly for the parental controls (access restrictions), but I have a suspicion that Merlin gave more speed and coverage. It is not always easy to balance features with perfomance, so any further comparison would be greatly appreciated.
 
You must test Tomato Toastman and OpenWRT as well at least.

For the sake of the great Tomato community, you don't want to put Tomato Shibby in a representative position, also because his builds are the quickest updated of all.

Tomato Toastman and Tomato RAF tend to wait for updates, they don't have many addons like Tomato Shibby and the builds are also lighter.
 
Last edited:
As for DD-WRT, it uses a completely different uPNP daemon (I forgot its name).

It's an implementation made by Broadcom. It's really buggy. And apparently has a vulnerability: http://blog.defensecode.com/2013/02/defensecode-security-advisory-cisco.html

As far as I can tell, dd-wrt is still vulnerable.

I also would have liked to see OpenWRT as the firmware has a newer kernel and better code in general.

edit:
Tomato Toastman and Tomato RAF tend to wait for updates, they don't have many addons like Tomato Shibby and the builds are also lighter.
Completely irrelevant since both Tomato RAF and Toastman's builds will exhibit the same results as shibby's builds. The things that were tested are practically the same between all of those builds.
 
Last edited:
The firewall_2 failure is something I was aware of. A user reported me that behaviour a couple of months ago, and at the time I decided it wasn't really worth fully investigating because the only scenario where it might become an issue is one where the router would be fronting another LAN that you don't control, rather than your ISP. I forgot the details because it's been so long, but this could possibly be resolved with a single iptable rule.

I wonder if their demo would be actually usable to re-test the upnp and sip stuff... I could try adding a USB NIC to my laptop. The minimal configuration required by CDRouter is two NICs, plus a third for your lab (in this case, it would be the wireless). I'll have to bring home that age old Linksys USB NIC that's been gathering dust in my workshop.
 
Last edited:

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top