R7000: dd-wrt versus stock firmware

[RogerSC]

I've looked at this several times, but with either dd-wrt Kong build 25090M or 25735M, I'm seeing iperf at nearly 33% higher with dd-wrt than using stock firmware.

At the moment I just have mobile clients that I can easily carry around, my laptop is pretty much a desktop at this point (external display, keyboard, and mouse). So I got an iperf3 app for my iPad Air 2 just for fun, installed the corresponding Windows version of iperf3 for the server end, and compared the 5GHz. throughput results for stock versus dd-wrt firmware in my living room. This is where I use my iPad the most. This is also the furthest point in my house from the R7000 router, so of most interest that I get good performance there.

What I saw was that the stock firmware ran around 65Mbps average, and the dd-wrt firmware ran around 85-90Mbps average. I was surprised, so repeated these tests several times, with pretty consistent results. Found this quite surprising, but repeatable.

I also checked out the RT-AC68P, and with RMerlin's firmware, it also ran around 65Mbps on average. I haven't yet tried dd-wrt on the RT-AC68P, but I suspect I would see comparably higher throughput with dd-wrt.

Anyways, just thought this was interesting, even though the tools are on the light and fluffy side *smile*. So guess what, I'm staying with dd-wrt on the R7000 for the moment *smile*. IPv6 even works well, until I reboot or power-cycle the router, at which point I lose my internet connection when the router comes back up. I guess that you can't have everything.

 

[AdvHomeServer]

I'm using DD-WRT on a couple of Netgear routers, a R6300v1 and a R6300v2. Both host older Kong versions dated from after the Heartbleed fix. After they combined the NEWD and OLDD versions into one build, reliability seemed to suffer. Lots of complaints about stability appeared on the DD-WRT Broadcom forum topic. The forum appears to be printing fewer and fewer complaints as the revised versions are issued, but I'm still a little reluctant to go as new as your versions.

I'm wondering if router technology has surpassed the ability of DD-WRT to keep up. It originated with the older 2.4GHz lynksys routers and has morphed into an all powerful router / server combination.

My routers are solid for what I ask of them and speeds are acceptable. I'm too timid to upgrade just for the fun of it.

The features I rely on are OpenVPN server using a tun connection, custom certificates, and password authorization to incoming clients on the main router and 5GHz client bridging with an open for use 2.4 GHz radio on the wireless bridge router.

 

[RogerSC]

Well, dd-wrt has been doing great for me with the R7000 pretty much since I've had it. I used Kong's firmware releases in place of stock firmware for a long time after getting the R7000 back in October of 2013. Then went to stock firmware for a while when Netgear finally got that working. But stock firmware is really lightweight in terms of network monitoring capability, even something as basic as "Attached Devices" (the current router client list) has spotty and incomplete information. Now I'm back on dd-wrt for performance reasons, and it is performing really well for me again. And I have a real router log and have a much better idea what's going on in my home network.

So, no, I don't find that dd-wrt is not able to keep up with stock firmware or router features, it has been consistently ahead in both performance and features on the R7000. Don't know about other routers, though. I've only used dd-wrt for extended periods of time on the R7000.

 

[kbp]

RodgerSC

can you give me the link for the 25735M

thanks

 

[forty9er]

Here you go:

http://desipro.de/ddwrt/K3-AC-Arm/dd-wrt.v24-K3_AC_ARM_STD.bin

 

[kbp]

Thanks to both ...

 

[paraplu]

I've looked at this several times, but with either dd-wrt Kong build 25090M or 25735M, I'm seeing iperf at nearly 33% higher with dd-wrt than using stock firmware.

At the moment I just have mobile clients that I can easily carry around, my laptop is pretty much a desktop at this point (external display, keyboard, and mouse). So I got an iperf3 app for my iPad Air 2 just for fun, installed the corresponding Windows version of iperf3 for the server end, and compared the 5GHz. throughput results for stock versus dd-wrt firmware in my living room. This is where I use my iPad the most. This is also the furthest point in my house from the R7000 router, so of most interest that I get good performance there.

What I saw was that the stock firmware ran around 65Mbps average, and the dd-wrt firmware ran around 85-90Mbps average. I was surprised, so repeated these tests several times, with pretty consistent results. Found this quite surprising, but repeatable.

I also checked out the RT-AC68P, and with RMerlin's firmware, it also ran around 65Mbps on average. I haven't yet tried dd-wrt on the RT-AC68P, but I suspect I would see comparably higher throughput with dd-wrt.

Anyways, just thought this was interesting, even though the tools are on the light and fluffy side *smile*. So guess what, I'm staying with dd-wrt on the R7000 for the moment *smile*. IPv6 even works well, until I reboot or power-cycle the router, at which point I lose my internet connection when the router comes back up. I guess that you can't have everything.

Hi RogerSC, assuming you have this running as access point, could you please enlighten us with the 5Ghz settings you are using? I am currently running this Kong build as well but am unable to see any 5Ghz improvement compared to latest (excellent) Netgear stock.
Thanks very much.

 

[RogerSC]

When I took those measurements I was using the R7000 as my main router. Right now, I'm using the RT-AC68P, since I just put some new firmware on it. Vanilla settings for dd-wrt on the R7000, the only odd thing that I do is set "short" preamble on both 2.4GHz. and 5GHz. bands. Other than that, it's pretty much like Kong's wireless setup documents. I do set channel numbers and channel widths (20MHz. on channel 6 on 2.4GHz. and 80+80/upper upper for wireless-AC on channel 161 on 5GHz.). I leave beamforming on, and turboQAM off. And leave the mode on "Auto".

I have had some variable results since I did this posting, but I've seen dd-wrt stay ahead of the stock firmware on 5GHz. consistently here. From what I read, though, there are a lot of variables with these sort of measurements in real environments.

 

[stevech]

I used DD-WRT long ago to get features that weren't in WIFi routers of that era. Not so, today.

 

[RogerSC]

For the R7000, dd-wrt was working much better and more consistently until relatively recently, at a very basic level, than Netgear's stock firmware. In addition to providing a platform to be able to use some interesting software on the router. Also, Netgear has worked hard to dumb their firmware down to the point that it's nearly impossible to figure out what's going on. Seems to be a common situation these days. With dd-wrt firmware it's easy to see what's going on with one's LAN.

Have you seen the stock web interface for the R7000?

 

[paraplu]

Agree with RogerSC statement. Stock Netgear firmware is pretty poor in interface and flexibility, and has a nasty broadcast every 5 sec looking for something = broadcasting to all wifi devices!

Had a peek in the Netgear firmware a while ago, when they mistakenly released a telnet-able firmware, but man, what a messy shirt.

Ddwrt instead has only a couple of daemons running on top of a clean os.

Also seems to be running stable, with proper Broadcom 5G driver which enables beamforming. Cannot see a difference between stock and ddwrt at the moment, in terms of reception, on both bands. Thank you Kong.

What I especially like about ddwrt is the option to enable true-isolated guest wlan, in access point mode. Try to establish that with stock firmware!

 

[microchip]

Agree with RogerSC statement. Stock Netgear firmware is pretty poor in interface and flexibility, and has a nasty broadcast every 5 sec looking for something = broadcasting to all wifi devices!

Had a peek in the Netgear firmware a while ago, when they mistakenly released a telnet-able firmware, but man, what a messy shirt.

Ddwrt instead has only a couple of daemons running on top of a clean os.

Also seems to be running stable, with proper Broadcom 5G driver which enables beamforming. Cannot see a difference between stock and ddwrt at the moment, in terms of reception, on both bands. Thank you Kong.

What I especially like about ddwrt is the option to enable true-isolated guest wlan, in access point mode. Try to establish that with stock firmware!

My R7000 also runs only a couple things. I do not understand what you're trying to say. If I telnet to my R7000 and run top or ps, I only see stuff I'm actually using. No minidlna, no bftpd, no openvpn, etc running which I don't use

Also, you don't have to wait for NETGEAR to make a mistake and release FW which allows telnet. There are small program on the Net allowing you to enable telnet on any firmware

 

[paraplu]

My R7000 also runs only a couple things. I do not understand what you're trying to say. If I telnet to my R7000 and run top or ps, I only see stuff I'm actually using. No minidlna, no bftpd, no openvpn, etc running which I don't use

Also, you don't have to wait for NETGEAR to make a mistake and release FW which allows telnet. There are small program on the Net allowing you to enable telnet on any firmware

Interesting. How do you telnet into latest Netgear R7000 stock firmware?

 

[microchip]

Interesting. How do you telnet into latest Netgear R7000 stock firmware?

By downloading this small python script and following the instructions

https://github.com/insanid/netgear-telenetenable

 

[RogerSC]

Here's another reference for remodeling telnetenable.py to use UDP instead of TCP:

https://code.google.com/p/netgear-telnetenable/issues/detail?id=2

I did follow this the other day, using a VMware Player Linux VM, and it was really easy to do. Most of the time was spent setting up the VM and getting updated vmware-tools installed, as well as getting the Crypto.Cypher module that's available for python installed. Actually modifying the script was just a cut-and-paste job. If you already have a Linux VM or a Linux box, then this would be very quick.

This was much easier for me to on Linux than Windows, although I if you have Windows development experience that you could also set up the proper environment there to do this.

Anyways, it does work to enable telnet to the R7000, and isn't hard at all.