[R7000] Tomato or DD-WRT?

[Mordred]

I vote for dd-wrt.

I have no idea why tomato can't get wireless working. Regulation settings are all messed up, bad throughput. No beamforming
Besides that several feature are still broken on hese arm builds. How many people need hw acceleration?
I need a reliable router and tomato is unstable. I had uptimes of more then 90 days with dd-wrt and only rebooted after an update.
Tomato is still on a 2.6 kernel, 2.6 has been eol a while ago, thus no security fixes etc.

DD-WRT has built in update routine, comes with incldued adblocking, no need to poke around and pull in adblock sources from 3rd party, that can be manipulated.
Straight forward secure software package installation for additional software.

Never had any issues with dd-wrt, all features I use have been working from the beginning.

Thus give both a try and decide yourself.

 

[microchip]

I vote for dd-wrt.

I have no idea why tomato can't get wireless working. Regulation settings are all messed up, bad throughput. No beamforming
Besides that several feature are still broken on hese arm builds. How many people need hw acceleration?
I need a reliable router and tomato is unstable. I had uptimes of more then 90 days with dd-wrt and only rebooted after an update.
Tomato is still on a 2.6 kernel, 2.6 has been eol a while ago, thus no security fixes etc.

DD-WRT has built in update routine, comes with incldued adblocking, no need to poke around and pull in adblock sources from 3rd party, that can be manipulated.
Straight forward secure software package installation for additional software.

Never had any issues with dd-wrt, all features I use have been working from the beginning.

Thus give both a try and decide yourself.

ehmm, Tomato is very stable here. I'm up for 50 days now and during the time I changed enough things without needing a reboot. Range and throughput is great (at least for the tests I did on my Sammy Galaxy J5). Latest Tomato includes adblocker too, which I successfully use

As for the kernel, keep in mind that ASUS and all forks of it also use it. It's heavily patched, not vanilla

Also I need CTF. I'm now on 240/30 and in the near future I'll get Gbit speeds so DD-WRT is out of the question for me

 

[RogerSC]

I agree that tomato is stable for my R7000 as well. Last time I used it, I was staying with v132 since some changes were made after that de-stabilized subsequent, but v132 was quite stable. The problems with later versions may have been fixed by now, I don't know since I've been using an R7800 for a while now. And appropriate security fixes are backported to the 2.6.x kernel used for router firmware by the router manufacturers. If you've ever used Merlin's firmware, last time I looked he was using a 2.6.x kernel as well, it's part of the wireless driver delivery from the router OEMs to the third-party firmware folks.

 

[Mordred]

I agree that tomato is stable for my R7000 as well. Last time I used it, I was staying with v132 since some changes were made after that de-stabilized subsequent, but v132 was quite stable. The problems with later versions may have been fixed by now, I don't know since I've been using an R7800 for a while now. And appropriate security fixes are backported to the 2.6.x kernel used for router firmware by the router manufacturers. If you've ever used Merlin's firmware, last time I looked he was using a 2.6.x kernel as well, it's part of the wireless driver delivery from the router OEMs to the third-party firmware folks.

If router manufacturers could backport security fixes, then they would just upgrade to a newer kernel, but they have been using this old kernel for ages, since that is what they get from their tier 1.

The result is, that for example tomato shibby comes with security issues:

https://github.com/firmadyne/firmadyne/blob/master/paper/paper.pdf

10 years ago, tomato was one of the best fw out there, nowadays it struggles to even add basic support for a few new broadcom models. I think R7000 build was release 1year after dd-wrt added support.
That pretty much says it all.

 

[RMerlin]

The result is, that for example tomato shibby comes with security issues:

That document is not a good reference. It's a whitepaper about their exploit detection system, and if you read it you will see that they downloaded a bunch of obsolete firmware versions to prove their point. They did not test the latest version for these test subjects.

And Shibby's entry shows a single exploited result, which is lower than a lot of the other firmwares. If anything, that says that Tomato is actually MORE secure than a lot of OEM firmwares.

 

[Mordred]

Tomato has a history of beeing insecure, a good example which you also find in current builds, you can press ses button to start a telnet daemon that does not require a password. Thus everyone that can access the router will have full access to the router, can read all passwords through telnet session. Amateur stuff.

You are probably right, more secure then other OEM fw., of course you know as you are an expert on Asus fw, which is probably one of the most insecure firmwares out there, one just needs to read the changelogs. Not sure how many critical bugs asus had to fix in the past 2 years.
No wonder FCC put asus under pressure for that.

 

[RMerlin]

You are probably right, more secure then other OEM fw., of course you know as you are an expert on Asus fw, which is probably one of the most insecure firmwares out there, one just needs to read the changelogs. Not sure how many critical bugs asus had to fix in the past 2 years.
No wonder FCC put asus under pressure for that.

I deny your claim that Asus is the most insecure firmware out there. Let's look at the competitors, who DELIBERATELY had backdoors in their firmware, until they got caught:

Netgear: https://wiki.openwrt.org/toh/netgear/telnet.console#
TP-Link: https://sekurak.pl/tp-link-httptftp-backdoor/
Netgear/Linksys: http://www.geek.com/chips/netgear-and-linksys-hide-router-backdoor-instead-of-closing-it-1591929/
DLink: https://nakedsecurity.sophos.com/20...-flaw-lets-anyone-login-using-joels-backdoor/

Just because you see Asus fixing a lot of security issues and reporting them in their changelog doesn't mean the competitors are more secure. It simply means they actually fix the issues. It doesn't imply that their competitors don't have issues - and I have strong reasons to believe that most of them simply ignore those issues, hoping that nobody is going to notice them.

Personally, I'm far more worried about an obsolete version of OpenSSL or proftpd than an obsolete version of the kernel, because Linux in general tends to be pretty good security-wise.

I did the legwork a couple of months ago, checking how thorough various popular SOHO router manufacturers were in keeping their code up-to-date with security fixes. You want to see how more "secure" the other manufacturers are? Check this list:

https://docs.google.com/spreadsheets/d/1q9CPKS0-kkSdT6Y3mmOFuFCJ2kdQILQXydpaFBv9CW4

This is an area where third party firmware devs, be it Tomato or DD-WRT, tend to be more on the ball than all manufacturers.

You can also do a search on the CVE database sometime for any of these manufacturers. Almost every SOHO router manufacturer has a disastrous track record (considering their products are meant to be fronting one's network, and secure it against the Internet).

Asus' security track record isn't great. But it's not worse than the rest, who are just as bad, and often even worse. They just got more visibility, for some reason For too many years, all these manufacturers haven't cared about security, and this is only slowly beginning to change.


(BTW, the FCC has absolutely nothing to do with firmware security).

 

[Mordred]

Sorry I meant FTC:

https://www.ftc.gov/news-events/pre...rges-insecure-home-routers-cloud-services-put

Of course you defend your baby, but it is a fact, that asus adds self developed software that lacks security/testing and I recall a lot of amateur bugs in asus firmware, that show that asus has no real QA, but leaves it to 3rd party devs to find them.

 

[lepa71]

Sorry I meant FTC:

https://www.ftc.gov/news-events/pre...rges-insecure-home-routers-cloud-services-put

Of course you defend your baby, but it is a fact, that asus adds self developed software that lacks security/testing and I recall a lot of amateur bugs in asus firmware, that show that asus has no real QA, but leaves it to 3rd party devs to find them.

Why don't you fix some and share. It's open source after all.

 

[RMerlin]

Sorry I meant FTC:

https://www.ftc.gov/news-events/pre...rges-insecure-home-routers-cloud-services-put

Of course you defend your baby, but it is a fact, that asus adds self developed software that lacks security/testing and I recall a lot of amateur bugs in asus firmware, that show that asus has no real QA, but leaves it to 3rd party devs to find them.

Asus's firmware isn't my baby, it's theirs. If anything, I'm more aware than anyone here as to the bugs that keep creeping up within each new release they issue, since I have both hands deep within that code myself. I've never attempted to hide them, I even explicitly mention it in my changelog whenever something that I fix was a bug in Asus's code. I merely pointed out that, within the global picture, almost all of those home gateway routers have pretty poor firmware, which leads back to my original claim that, ultimately, Tomato is not the security disaster you implied it was - it's probably better than a lot of OEM firmwares.

All those router manufacturers need to stop treating those home gateways as gadgets, and start treating them as the security devices they are meant to be. That means getting rid of the 10+ years old crud still present in some of their firmware, keeping up-to-date with new components that are security-sensitive (OpenSSL for starter should ALWAYS be the latest version at the time they release a new firmware, unless they are willing to backport security fixes as they are issued). Someone needs to address the issue of Samba as well. Manufacturers stick to prehistoric versions of Samba (3.0.xx) for two reasons:

1) Licensing (some are not comfortable with the licence used by Samba in newer releases - oddly enough NAS manufacturers never complained about that)
2) Optimizing for embedded devices. The OpenWRT devs did so with 3.6.x, however the nightmare that is the Samba 4 build system makes it painful to re-implement, and the Samba devs clearly said that embedded devices weren't their concern, and that someone else would have to do it for them if they really wanted a more modular, and optimized Samba build for embedded devices.


So for the original question, I consider both Tomato and DD-WRT good alternatives for the R7000. I would favor DD-WRT since it has been more thoroughly tested on the R7000 specifically (as that's what Kong was using himself as his router while developing for it), and there are still a few rough edges regarding Tomato and the ARM platform (more specifically the 6.37 SDK used by that platform). The biggest problem with DD-WRT is figuring out which specific build to use, as it does not follow any release schedule.

 

[elkido122]

Whats up with people saying dont use ddwrt if you have more than a 250meg connection?

 

[L&LD]

Whats up with people saying dont use ddwrt if you have more than a 250meg connection?

No hardware acceleration, is why.

And you'll be effectively capped to those speeds.

 

[RogerSC]

Whats up with people saying dont use ddwrt if you have more than a 250meg connection?

That's actually a little low, depending on the router. For the faster routers, like the R7000 or R7800 you can go higher than that, but if you're over 500Mbps, don't bother. For example, the R7800 has a pretty fast CPU, haven't heard how fast it can go on dd-wrt yet. It was said that if you had an R7000 and overclocked it from 1GHz. to 1.2GHz., you might get up to 350-400Mbps or so. But dd-wrt is limited by not having hardware acceleration as has been mentioned. Around here, we're not in danger of hitting that limit...we're supposed to be getting 200Mbps, but at prime time, speeds are generally around 150Mbps or lower. I just love Comcast.

Tomato does have CTF, so you should be able to get 1Gbps if your router is capable of it. For the R7000, I think that XVortex also has CTF and FA, so you can most likely get up to 1Gbps with that as well.

 

[RMerlin]

Too bad Kong never finished debugging the open source CTF replacement that was being developped for DD-WRT. It was looking promising.

Routers are currently stuck between offering advanced features or offering support for the new near-gigabit services. Solutions such as CTF are more or less dirty hacks IMHO, as they come with a heavy price, and various serious limitations. Port-forwarded traffic, for instance, is NOT accelerated.

 

[Mordred]

That's actually a little low, depending on the router. For the faster routers, like the R7000 or R7800 you can go higher than that, but if you're over 500Mbps, don't bother. For example, the R7800 has a pretty fast CPU, haven't heard how fast it can go on dd-wrt yet. It was said that if you had an R7000 and overclocked it from 1GHz. to 1.2GHz., you might get up to 350-400Mbps or so. But dd-wrt is limited by not having hardware acceleration as has been mentioned. Around here, we're not in danger of hitting that limit...we're supposed to be getting 200Mbps, but at prime time, speeds are generally around 150Mbps or lower. I just love Comcast.

Tomato does have CTF, so you should be able to get 1Gbps if your router is capable of it. For the R7000, I think that XVortex also has CTF and FA, so you can most likely get up to 1Gbps with that as well.

Google "iperf R7800 dd-wrt" -> http://www.dd-wrt.com/phpBB2/viewtopic.php?t=289788&highlight=r7800

I see 840Mbps. Obviously there are dd-wrt routers out there now, that can handle gigabit speeds.

 

[RogerSC]

Google "iperf R7800 dd-wrt" -> http://www.dd-wrt.com/phpBB2/viewtopic.php?t=289788&highlight=r7800

I see 840Mbps. Obviously there are dd-wrt routers out there now, that can handle gigabit speeds.

Glad to hear it, that's the R7800 with the faster CPU that I was wondering about. I'm using that router right now. By the way, I did try the latest Kong firmware for this router, and the latest firmware has some wireless range and speed problems. You'll see that if you read through the thread starting at the end. I'll be happy when that firmware is working as it should, and we'll see what the speed is at that point. It may well be faster, since Kong is indicating that he got the 840Mbps with one CPU. We'll see. It would make me very happy to see the R7800 get up to 1Gbps with dd-wrt.

 

[ccx125]

I wanted to note that VPN tunneling onboard a router is often limited by the router CPU. Your throughput speed is bottlenecked by the CPU which is handling all of the encryption. If anyone wants to buy a new router make sure you prioritize CPU speed!

http://www.enginoor.com/list-of-tomato-compatible-routers/