or Connect
AVS › AVS Forum › Gaming & Content Streaming › Networking, Media Servers & Content Streaming › Netgear R7000 Nighthawk AC1900 Router Review and Comments Thread
New Posts  All Forums:Forum Nav:

Netgear R7000 Nighthawk AC1900 Router Review and Comments Thread - Page 10

post #271 of 618
I had a weird thing today. I logged into my R700 (I also have a WNDR3800). Both are set as access points using the same SSIDs and passphrases. Of course both are on different channels for each band. When I logged into the R700 my passphrase for the 2.4GHz SSID was different than the 5GHz and different than what I had set it to before. The WNDR3800 was correct. I'm wondering if since I last updated the firmware (on only officially release version) there was something that changed it. It was something about phobic socks, etc... I can tell you that isn't something I would use. I can also tell you that I have changed the default password on both APs and I use WPA2 for encryption.

Anybody had this happen before?
post #272 of 618
Quote:
Originally Posted by Almighty2 View Post

I was thinking of using DD-WRT for it's features but ofcourse the hardware acceleration support is not there and from reading, people still have higher throughput even with lower than 200Mbps connections. I would try DD-WRT but it takes me 1 hour every time to reconfigure the R7000 because the R7000's updating settings progress bar takes forever so with each setting that I hit apply on, that's what is adding up on time, not the actual settings itself. I understand what you mean by firmware as in a way, it's almost like the people who get disconnected when idle so they have to ping it to keep the connection alive... Atleast you arent switching firmware every few hours or everyday. LOL.

You know, dd-wrt is the quickest firmware to setup that I've used, and Netgear is about the slowest, even slower than Asus...here's what dd-wrt has as far as setup speed ups go:

1. You have a "Save" button as well as an "Apply", and "Save" is very quick. So if you're setting things up using several pages you can just use "Save" on each page until you're done, and then "Apply" once, and it's much quicker. There is one place I've run into where you need a sequence of "Apply"'s, but "Apply" is so much quicker with dd-wrt that it really doesn't matter.

2. The dd-wrt firmware "Apply" is MUCH quicker than "Apply" on the Netgear firmware, in addition to being able to "Apply" saved settings from several pages. I get the sense that after doing "Apply" with dd-wrt, you may have to wait a couple of seconds more for the router to catch up before you can "Apply" again, it is pushing the limits with the timing, but it is so much faster than Netgear, you'll love that part of it *smile*. I can do a full setup on dd-wrt in just a couple of minutes. With the Netgear firmware, the process takes much longer, waiting for all the "Apply"'s to complete for each page changed.

So, if you try dd-wrt and like it, you'll be in the fast lane as far as setup goes. If you don't, it's an interesting thing to try anyways. I'm still waiting for tomato for the R7000, it's being ported to ARM processor as we speak *smile*. With Asus, I used RMerlin's firmware, so I'm used to using firmware that doesn't come from the router manufacturer.
post #273 of 618
Quote:
Originally Posted by rwheelwright View Post

I had a weird thing today. I logged into my R700 (I also have a WNDR3800). Both are set as access points using the same SSIDs and passphrases. Of course both are on different channels for each band. When I logged into the R700 my passphrase for the 2.4GHz SSID was different than the 5GHz and different than what I had set it to before. The WNDR3800 was correct. I'm wondering if since I last updated the firmware (on only officially release version) there was something that changed it. It was something about phobic socks, etc... I can tell you that isn't something I would use. I can also tell you that I have changed the default password on both APs and I use WPA2 for encryption.

Anybody had this happen before?

Oh, and I wasn't able to connect via my S4 on the 5GHz band. Passphrase was correct but it would only connect to the 3800 which is across the house. Once I rebooted the R700 I was able to connect.
post #274 of 618
Quote:
Originally Posted by rwheelwright View Post

Oh, and I wasn't able to connect via my S4 on the 5GHz band. Passphrase was correct but it would only connect to the 3800 which is across the house. Once I rebooted the R700 I was able to connect.

You're in good company. The top two sticky postings in the Netgear R7000 forum now are:

[NETGEAR R7000 Team] 2.4GHz performance degradation
[NETGEAR R7000 Team] 5GHz disconnection issue

and they have 8 and 11 pages of postings respectively. So you can post your experiences over there...the "NETGEAR R7000 TEAM" at the start of these two threads is supposed to mean that Netgear is reading them:

http://forum1.netgear.com/forumdisplay.php?f=153
post #275 of 618
Quote:
Originally Posted by RogerSC View Post

You know, dd-wrt is the quickest firmware to setup that I've used, and Netgear is about the slowest, even slower than Asus...here's what dd-wrt has as far as setup speed ups go:

1. You have a "Save" button as well as an "Apply", and "Save" is very quick. So if you're setting things up using several pages you can just use "Save" on each page until you're done, and then "Apply" once, and it's much quicker. There is one place I've run into where you need a sequence of "Apply"'s, but "Apply" is so much quicker with dd-wrt that it really doesn't matter.

2. The dd-wrt firmware "Apply" is MUCH quicker than "Apply" on the Netgear firmware, in addition to being able to "Apply" saved settings from several pages. I get the sense that after doing "Apply" with dd-wrt, you may have to wait a couple of seconds more for the router to catch up before you can "Apply" again, it is pushing the limits with the timing, but it is so much faster than Netgear, you'll love that part of it *smile*. I can do a full setup on dd-wrt in just a couple of minutes. With the Netgear firmware, the process takes much longer, waiting for all the "Apply"'s to complete for each page changed.

So, if you try dd-wrt and like it, you'll be in the fast lane as far as setup goes. If you don't, it's an interesting thing to try anyways. I'm still waiting for tomato for the R7000, it's being ported to ARM processor as we speak *smile*. With Asus, I used RMerlin's firmware, so I'm used to using firmware that doesn't come from the router manufacturer.

I read in a review where someone was comparing the Linksys EA6900, ASUS RT-AC68R/U and the Netgear R7000 and they said the Linksys was the one that didn't require all the reboots for changes and Netgear required the most. Maybe there is a certain order I should setup things since not all of them reboots or take as long and do the ones that takes long last.

Save definitely helps since with the Netgear, it seems like you have to save the changes with apply on each page you go through... These are Linux based routers and Linux doesn't require rebooting to change settings unless it's using a different kernel since if the kernel modules are for the same version as the booted system, all it takes is loading/unloading in real time.

I'll try dd-wrt one of these nights unlike last night when I disabled the 2.4Ghz radio instead of unchecking 20/40Mhz so I couldn't connect to the R7000 directly. Used my mobile phone and for whatever reason, even though it did the apply, it never rebooted and when I checked, the enable 2.4Ghz radio was unchecked and the enabled 20/40Mhz was still checked. I did it multiple times with the same results. Eventually I had to use the 2nd DSL modem/router Pace Wireless N that I am testing to get back into the R7000 using the WAN IP as I had remote management turned on. I wonder what happened to the Android based router firmware that was supposed to come out when the Netgear 6300 first came out. DD-WRT actually sounds better when used with Linksys as the WRT came from the WRT54. LOL. Atleast with RMerlin's firmware, it's basically an enhanced version of ASUS's firmware. That's why I said NETGEAR needs someone like RMerlin. Hopefully someone will be able to reverse engineer and able to get CTF/hardware acceleration working on the third party firmwares and you never know, they may be able to make it work even better.
post #276 of 618
Quote:
Originally Posted by Almighty2 View Post

That's why I said NETGEAR needs someone like RMerlin. Hopefully someone will be able to reverse engineer and able to get CTF/hardware acceleration working on the third party firmwares and you never know, they may be able to make it work even better.

Yes, I can think of a lot of enhancements to the Netgear firmware, especially to controls and logging available on the web interface, that would make the R7000 a better tool and easier to admin. Another RMerlin hasn't stepped up to take on the Netgear firmware, unfortunately, though. Dd-wrt is, as I said once or twice *smile*, making this router very useful for me at the moment, though. And the web interface is much better, the full text of syslog is available without all the DHCP song and dance. And, as a really simple example, the choices for channel width are the usual 20, 40, and 80 with dd-wrt. None of this confusing "20/40MHz coexistence" plus a speed range setting stuff , don't know who thought that one up. I had no intuition about what "20/40MHz coexistence" meant until I turned it on and off and saw what it actually did. I just wanted to choose 20MHz. channel width on 2.4GHz. and 40MHz. on 5GHz., but no, can't be that simple *smile*. I could go on and on, but I'll spare you that *smile*.

If I was concerned with CTF, I think I'd feel differently. No need to that around here. Not even sure I could get 100Mbps download without paying for a business connection, or if I could get a business connection where I live...
post #277 of 618
This thread was started about 4 Months ago and it would appear that all the highly touted functions of the R7000 are either not working properly or are not fully implemented.

Netgear is not alone with this problem. It appears that "for competitive reasons" most vendors of consumer grade wireless products have chosen to release late Alpha or early Beta products for sale and use their Customers as unpaid testers. It is worse than that. Many branches of the Home Electronics industry use unpaid Beta Testers. However, these testers are provided with the products they are testing and have not had to reach into their wallets to buy them.

The combination of devices that must be supported by a product like the R7000 is essentially limitless and certainly no Test program can hope to come close to what the product will see in the wild. It is inevitable that problems will,be uncovered in the first few Months after the release of a product such as the R7000. This does not excuse the release of a product without the implementation of such a highly touted feature as Beam Forming or Quality of Service that is worse than not working.

Netgear has an opportunity to set a new standard for its industry by not using its customers as unknowing beta testers.

The approach that I would like to see is an early adopter program with purchases direct fron Netgear at a significant discount from the expected retail price. These early adopters would be expected to supply their existing configurations and a list of client devices at they time they request entry into the early adopter program. An explicit set of testing steps would also be provided and private feedback channels would also be established. While there would be a target date for formal product release, the product must NOT be released until all advertised features were working properly.

IMHO Netgear has done themselves considerable damage by the premature release of the R7000. I have a client that needs a refresh of their wireless Network. Last week when I started a search for the equipment to use it appeared that 7 R7000's would fill the bill. After doing more research both here, on the Netgear a Forums, and other places I am not so sure.
post #278 of 618
Quote:
Originally Posted by RogerSC View Post

Yes, I can think of a lot of enhancements to the Netgear firmware, especially to controls and logging available on the web interface, that would make the R7000 a better tool and easier to admin. Another RMerlin hasn't stepped up to take on the Netgear firmware, unfortunately, though. Dd-wrt is, as I said once or twice *smile*, making this router very useful for me at the moment, though. And the web interface is much better, the full text of syslog is available without all the DHCP song and dance. And, as a really simple example, the choices for channel width are the usual 20, 40, and 80 with dd-wrt. None of this confusing "20/40MHz coexistence" plus a speed range setting stuff , don't know who thought that one up. I had no intuition about what "20/40MHz coexistence" meant until I turned it on and off and saw what it actually did. I just wanted to choose 20MHz. channel width on 2.4GHz. and 40MHz. on 5GHz., but no, can't be that simple *smile*. I could go on and on, but I'll spare you that *smile*.

If I was concerned with CTF, I think I'd feel differently. No need to that around here. Not even sure I could get 100Mbps download without paying for a business connection, or if I could get a business connection where I live...

I think the best solution is really for Netgear to supply the licensed drivers from Broadcom to third party firmware developers and let the third party provide the firmware since it's a win-win situation as it's cheaper than hiring all the engineers that can't fix problems and everyone will be happy. I thought I knew what coexistence meant when reading smallnetworkbuilder's article but didn't really understand it until you explain it in a short and simple way on the NETGEAR forums. Actually, it seems the non-business connections for Comcast actually has a 200Mbps profile while the business one is less than 200Mbps.
post #279 of 618
RogerSC,

Just a update.... I decided to try DD-WRT r23490 last night and it wasn't a good experience since apparently r23490 has debugging enabled so clicking on save or even apply will take forever, even going from one tab to the next will take atleast 10 seconds before it shows up.

I tried the holding down reset for 8 seconds to do the reset to factory defaults but unlike the NETGEAR firmware, it isn't making the power led blinking orange and from looking at the dd-wrt R7000 thread on the dd-wrt forums, this is what kong said:
"30/30/30 does not work on new netgear models.

Turn off the router with the power button. Turn it on, now press reset button for 10s, release it and let the unit boot. This triggers cfe reset. Pressing the reset button for 10s while dd-wrt is running will trigger dd-wrt factory defaults. "

So basically I did the turn off with power, turn on and press reset button for 10 seconds and let the unit boot. How are you doing the reset to factory defaults with dd-wrt?

So anyways, on to my comments.. r23490 took me a total of 45 minutes to setup because it was slow as mentioned above. r23550 came out earlier today and this version is fast! r23550 took me 30 minutes total to configure. Hitting save and going between tabs is instant, even clicking on apply settings took less than 3 seconds flat. My normal config time on the NETGEAR firmware is 65 minutes.

One thing I noticed is the initial version .chk file is the exact same version as the .bin file as it seems the initial version is updated everytime dd-wrt is updated as you can tell from the date/timestamp of the file.

I'm still confused on what the options mean on "Extension Channel" under Wireless -> Basic Settings -> Wireless Physical Interface does.

Speaking of which, in DD-WRT, using bonded channels always shows channel A + channel B but using inSSIDer, whats the difference when it lists the channel as 11+7 vs 11-7 or are they the same thing as I noticed that some channels show a - between the numbers while some show a +.

Also, from the web interface, I am not able to get it to prompt for a login/password as it will directly show the router information page/ Under Adminstration -> Management, in the Web Access section, I already have it as follows:

Protocol HTTP and HTTPS are both checked
Auto-Refresh (in seconds) 3
Enable Info Site on Enable
Info Site Password Protection on Enabled
Info Site MAC Masking on Disable

As far as ping times is concerned, it seems like depending on the channel I pick, I can get the same low -> high -> low -> high repeating sequence as anky posted before instead of the random high as before:

Pinging 192.168.2.1 with 32 bytes of data:
Reply from 192.168.2.1: bytes=32 time<1ms TTL=64
Reply from 192.168.2.1: bytes=32 time=465ms TTL=64
Reply from 192.168.2.1: bytes=32 time<1ms TTL=64
Reply from 192.168.2.1: bytes=32 time=464ms TTL=64
Reply from 192.168.2.1: bytes=32 time=1ms TTL=64
Reply from 192.168.2.1: bytes=32 time=465ms TTL=64
Reply from 192.168.2.1: bytes=32 time<1ms TTL=64
Reply from 192.168.2.1: bytes=32 time=468ms TTL=64
Reply from 192.168.2.1: bytes=32 time<1ms TTL=64
Reply from 192.168.2.1: bytes=32 time=466ms TTL=64
Reply from 192.168.2.1: bytes=32 time<1ms TTL=64
Reply from 192.168.2.1: bytes=32 time=488ms TTL=64
Reply from 192.168.2.1: bytes=32 time<1ms TTL=64
Reply from 192.168.2.1: bytes=32 time=466ms TTL=64
Reply from 192.168.2.1: bytes=32 time<1ms TTL=64
Reply from 192.168.2.1: bytes=32 time=465ms TTL=64
Reply from 192.168.2.1: bytes=32 time=3ms TTL=64
Reply from 192.168.2.1: bytes=32 time=465ms TTL=64
Reply from 192.168.2.1: bytes=32 time=1ms TTL=64
Reply from 192.168.2.1: bytes=32 time=468ms TTL=64
Reply from 192.168.2.1: bytes=32 time=2ms TTL=64
Reply from 192.168.2.1: bytes=32 time=487ms TTL=64

Ping statistics for 192.168.2.1:
Packets: Sent = 22, Received = 22, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 488ms, Average = 235ms

and then I can get normal pings as seen here which is done just a few seconds later:
Pinging 192.168.2.1 with 32 bytes of data:
Reply from 192.168.2.1: bytes=32 time<1ms TTL=64
Reply from 192.168.2.1: bytes=32 time=1ms TTL=64
Reply from 192.168.2.1: bytes=32 time<1ms TTL=64
Reply from 192.168.2.1: bytes=32 time=1ms TTL=64
Reply from 192.168.2.1: bytes=32 time=1ms TTL=64
Reply from 192.168.2.1: bytes=32 time<1ms TTL=64
Reply from 192.168.2.1: bytes=32 time=2ms TTL=64
Reply from 192.168.2.1: bytes=32 time<1ms TTL=64
Reply from 192.168.2.1: bytes=32 time=1ms TTL=64
Reply from 192.168.2.1: bytes=32 time<1ms TTL=64
Reply from 192.168.2.1: bytes=32 time<1ms TTL=64
Reply from 192.168.2.1: bytes=32 time<1ms TTL=64
Reply from 192.168.2.1: bytes=32 time<1ms TTL=64
Reply from 192.168.2.1: bytes=32 time<1ms TTL=64
Reply from 192.168.2.1: bytes=32 time=1ms TTL=64
Reply from 192.168.2.1: bytes=32 time=5ms TTL=64
Reply from 192.168.2.1: bytes=32 time<1ms TTL=64
Reply from 192.168.2.1: bytes=32 time=1ms TTL=64
Reply from 192.168.2.1: bytes=32 time<1ms TTL=64
Reply from 192.168.2.1: bytes=32 time=1ms TTL=64
Reply from 192.168.2.1: bytes=32 time<1ms TTL=64
Reply from 192.168.2.1: bytes=32 time=1ms TTL=64

Ping statistics for 192.168.2.1:
Packets: Sent = 22, Received = 22, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 5ms, Average = 0ms

I can even do a high -> low -> high -> low repeating sequence:
Pinging 192.168.2.1 with 32 bytes of data:
Reply from 192.168.2.1: bytes=32 time=374ms TTL=64
Reply from 192.168.2.1: bytes=32 time<1ms TTL=64
Reply from 192.168.2.1: bytes=32 time=373ms TTL=64
Reply from 192.168.2.1: bytes=32 time<1ms TTL=64
Reply from 192.168.2.1: bytes=32 time=357ms TTL=64
Reply from 192.168.2.1: bytes=32 time<1ms TTL=64
Reply from 192.168.2.1: bytes=32 time=355ms TTL=64
Reply from 192.168.2.1: bytes=32 time=3ms TTL=64
Reply from 192.168.2.1: bytes=32 time=357ms TTL=64
Reply from 192.168.2.1: bytes=32 time<1ms TTL=64
Reply from 192.168.2.1: bytes=32 time=373ms TTL=64
Reply from 192.168.2.1: bytes=32 time=14ms TTL=64
Reply from 192.168.2.1: bytes=32 time=378ms TTL=64
Reply from 192.168.2.1: bytes=32 time<1ms TTL=64
Reply from 192.168.2.1: bytes=32 time=354ms TTL=64
Reply from 192.168.2.1: bytes=32 time<1ms TTL=64

Ping statistics for 192.168.2.1:
Packets: Sent = 16, Received = 16, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 378ms, Average = 183ms

What's weird is that I can ctrl-c the ping and the next run can either be normal or it will have the high -> low or low -> high on each packet.
post #280 of 618
Okay, doesn't sound good. R23490 should have been as quick on the web interface as any, it was for me. Did you flash the .chk image in the "Initial" directory first? If you didn't, and you can get back to stock, I'd do that, then flash the "Initial" .chk firmware image, and flash the dd-wrt .bin r23550 image from there (there's a new build today, I've flashed it already and it looks good, fixes a bug that you'd have to fix manually otherwise).

So the sequence when you're flashing from stock to dd-wrt is:

1. Flash the .chk firmware in "Initial" directory in the firmware repository. The README file tells you to do this.

2. Wait until that comes up, don't worry about configuring it, you're only going to use it to flash the current .bin image. Flash the current .bin image...if it asks you if you want to reset to defaults at that point, say "yes".

3. What I do at that point is to use the router button to do a manual reset before giving name and password in the initial window. Then reload the web interface, and given the admin name and password that you want to use.

4. Configure your settings, and it should be fast on the web interface no matter what firmware you've picked. If it isn't, I would power-cycle it. If it isn't fast at that point, I'd reset it, and start over at step 2, reflash the .bin dd-wrt firmware image.

If you're upgrading from dd-wrt to later version of dd-wrt, that's simple. Just flash the dd-wrt .bin, selecting "reset to factory defaults" at the point when you upgrade.

There's something wrong if you're not seeing a quick web interface when you configure it, hopefully it's just related to how you flashed it. There's no debug turned on, or any other reason why the web interface would be slow.

And yes, when you hold down the reset button with dd-wrt installed, the power light goes solid rather than flashing amber. There are two ways to reset to factory defaults with dd-wrt, you can use the reset button in the usual way, or use the web interface to reset to factory defaults ("Administration" -> "Factory Defaults").

Just pinged my router from my laptop (connected via 5GHz. wireless, channel 161 with 157 as the extension channel). It was 1ms. every time, 25 times in a row. This also leads me to suspect that something went wrong in your flashing, or the sequence that you did things.

I'll answer the rest of your questions when I get some more answers *smile*.

Edit: I see that you did use the .chk file, but somehow you got a bad flash...not sure how that happened, I haven't had that happen. I haven't had to use the 30-30-30 equivalent yet, I just do regular resets as I mentioned above. And usually end up doing a power-cycle after flashing and resetting. Seems to help. Can you please tell me which band and channel you are getting weird pings to your router on, I'd like to check that out here.

The extension channel(s), one for 40MHz channel width (450Mbps), or two for 80MHz. channel width (1300Mbps), are the bonded channels to give the extra bandwidth for 450Mbps or wireless-ac. They have to be consecutive channel number to be able to be used for bonding to allow the extra bandwidth required for wireless-ac or even 450Mbps.
Edited by RogerSC - 2/7/14 at 1:52pm
post #281 of 618
Yes, like I said, I flashed .chk first which has an identical version number as the .bin file which I flashed afterwards. Since I don't think you can flash anything other than .chk anyways. Initially I thought I flashed the .bin by accident but when I went to browse files, I was in the initial folder since I kept the initial in a different subdirectory and the rXXXXX folder for the actual .bin file. I wonder is it a absolute requirement to flash to back to stock netgear first since couldn't one just flash the dd-wrt .chk and then flash the latest .bin on top of it? It seems the initial/.chk file gets updated as the firmware is updated since when r23490 was available, the initial/.chk file was r23490 dated 02/02/2014 and now the .chk file in initial is dated 02/07/2014. I also wonder if it makes a difference which version of the NETGEAR firmware you flash the initial .chk on as I did it from V1.0.3.12_1.1.18 beta.

How exactly are you doing step #3 though since the holding reset for 8 seconds where the power led turns to flashing orange as in the NETGEAR firmware doesn't happen so kong said to someone else to do the reset.... I just remember when I went with r23550, I rebooted and then held the reset button for 10 seconds without doing the power cycle, hopefully that resetted the cfe and not just reset dd-wrt to defaults as kong mentions here:
http://www.dd-wrt.com/phpBB2/viewtopic.php?p=876967#876967

So trying to figure out if you resetted just dd-wrt to factory defaults which is holding reset after dd-wrt has booted or resetting just the cfe which is power of then on and then reset.

I'll try what you mention later when I get a chance.... but R23490, I applied the following as kong mentiionedat the dd-wrt forums, I did it for R23550 as well...

To fix the wireless regression in the latest 23490 build, just run:

nvram set wl0_atf=0
nvram set wl1_atf=0
nvram commit
reboot

Next builds will default to this again. The rest should be absolutely fine in 23490.

As for the debugging, there is debugging turned on in previous builds as mentioned here:
http://www.dd-wrt.com/phpBB2/viewtopic.php?p=877877#877877

I only see the slow web interface and save/apply settings which both uses apply.cgi in R23490, R23550 seems to be fast which is a upgrade on top of R23490 and all I did was hold down reset for 10 seconds as soon as I rebooted, I forgot to power off and on before doing the reset.

One other thing I forgot to mention is with R23490, when setting channel 11 at 40Mhz, even though dd-wrt shows it using 11 + 7, inSSIDer is only showing channel 11 and ofcourse my wireless NIC sees the signal from one channel. With R23550, it works correctly.
post #282 of 618
Quote:
Originally Posted by Almighty2 View Post

Yes, like I said, I flashed .chk first which has an identical version number as the .bin file which I flashed afterwards. Since I don't think you can flash anything other than .chk anyways. Initially I thought I flashed the .bin by accident but when I went to browse files, I was in the initial folder since I kept the initial in a different subdirectory and the rXXXXX folder for the actual .bin file. I wonder is it a absolute requirement to flash to back to stock netgear first since couldn't one just flash the dd-wrt .chk and then flash the latest .bin on top of it? It seems the initial/.chk file gets updated as the firmware is updated since when r23490 was available, the initial/.chk file was r23490 dated 02/02/2014 and now the .chk file in initial is dated 02/07/2014. I also wonder if it makes a difference which version of the NETGEAR firmware you flash the initial .chk on as I did it from V1.0.3.12_1.1.18 beta.

How exactly are you doing step #3 though since the holding reset for 8 seconds where the power led turns to flashing orange as in the NETGEAR firmware doesn't happen so kong said to someone else to do the reset.... I just remember when I went with r23550, I rebooted and then held the reset button for 10 seconds without doing the power cycle, hopefully that resetted the cfe and not just reset dd-wrt to defaults as kong mentions here:
http://www.dd-wrt.com/phpBB2/viewtopic.php?p=876967#876967

So trying to figure out if you resetted just dd-wrt to factory defaults which is holding reset after dd-wrt has booted or resetting just the cfe which is power of then on and then reset.

I'll try what you mention later when I get a chance.... but R23490, I applied the following as kong mentiionedat the dd-wrt forums, I did it for R23550 as well...

To fix the wireless regression in the latest 23490 build, just run:

nvram set wl0_atf=0
nvram set wl1_atf=0
nvram commit
reboot

Next builds will default to this again. The rest should be absolutely fine in 23490.

As for the debugging, there is debugging turned on in previous builds as mentioned here:
http://www.dd-wrt.com/phpBB2/viewtopic.php?p=877877#877877

I only see the slow web interface and save/apply settings which both uses apply.cgi in R23490, R23550 seems to be fast which is a upgrade on top of R23490 and all I did was hold down reset for 10 seconds as soon as I rebooted, I forgot to power off and on before doing the reset.

Sorry, I was doing the no-no of adding to my posting instead of doing a new posting, so I've added information to my original response that might be helpful.

Yes, you should be able to go back to the "Initial" .chk firmware image instead of back to stock, but this is untrodden ground for me. My flashes have all worked as I expected, just lucky I guess.

To reset the router when you've installed dd-wrt, all you need to do is to hold the reset button for about 10 seconds (or until the power light goes full on amber, the power light doesn't flash, as you've noticed). You can also reset to defaults using the web interface, as I mentioned above. I like the physical router reset myself, since sometimes the hardware needs the kick, I think. You shouldn't need the 30-30-30 equivalent of powering the router on and then holding the reset button in ordinary circumstances.

Yes, I did the fix that you mention when I was using r23490, that's why I was happy to see r23550, since then I didn't have to worry about doing that should I need to reset the router.

Anyways, the web interface should be fast if things are going correctly. And I would like to hear which wireless channel you were using when you got the funky ping sequences, since I haven't seen that here with dd-wrt.

Edit: On the debugging thing, that's just extra symbols in the object module that will then appear in a router crash dump to make finding the crash context easier. It doesn't affect the runtime speed to have those extra symbols. It's a good idea for dd-wrt to help the maintainer take care of business, but will not affect you just using the firmware. It isn't like writing debug information to the log as you're running or something like that, just passive symbols to use for debugging after a crash.

Also, sounds better if r23550 web interface is fast, it should always be fast *smile*. Still concerned by the ping issues that you were seeing, though.
Edited by RogerSC - 2/7/14 at 2:15pm
post #283 of 618
I'll reply to the the post before this and bits missed in the other post in this reply.

I forgot to mention that I'm using 2.4Ghz and not 5Ghz as I only have a Atheros 150Mbps N card in this notebook at the present time and basically doing channel 11.

I think where I am confused with extension channel is with the 40Mhz, there is upper and lower. and with 80Mhz, there is lower lower, lower upper, upper lower, upper upper. That's the part that is confusing as I don't know what it means other than if you click save and selected the wrong channel after touching the Extension channel setting, the channel selected will go back to auto.

It seems there are 4 ways to reset in dd-wrt...

1) power off/power on and then hold reset for 10 seconds, this resets the CFE.
2) while dd-wrt is running, hold reset for 10 seconds, this resets DD-WRT to factory defaults
3) ("Administration" -> "Factory Defaults") in the web interface.
4) issue the following in the command prompt:
erase nvram
reboot

Seems like 2-4 does the same thing and resets dd-wrt while not sure exactly what #1 does except I thought just like with the NETGEAR or any firmware on routers, #3 might or might not work as well.

About the flash, I don't think one can flash the .bin file from the NETGEAR firmware as it seems to allow .chk only even though I did flash .chk inside of dd-wrt as I did initially thought I flashed the .bin by accident when the first screen showed:
Firmware: DD-WRT v24-sp2 (02/02/14) kongac

and status shows:
DD-WRT v24-sp2 (02/02/14) - build 23490M

but it seems like the initial is always the same version number as the latest dd-wrt version as I think it gets updated since even the current initial is dated 02/07/2014 on the ftp server.

Does it matter what version of stock NETGEAR firmware the initial .chk is flashed from?

The weird ping behavior I'm getting is kind of funny because it seems if the ping works correctly, all the packets sent/received in that ping will be good or will be bad as this is done about a minute ago:
C:\Users\Vince>ping -t 192.168.2.1

Pinging 192.168.2.1 with 32 bytes of data:
Reply from 192.168.2.1: bytes=32 time=17ms TTL=64
Reply from 192.168.2.1: bytes=32 time=347ms TTL=64
Reply from 192.168.2.1: bytes=32 time=1ms TTL=64
Reply from 192.168.2.1: bytes=32 time=355ms TTL=64

Ping statistics for 192.168.2.1:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 1ms, Maximum = 355ms, Average = 180ms
Control-C
^C
C:\Users\Vince>ping -t 192.168.2.1

Pinging 192.168.2.1 with 32 bytes of data:
Reply from 192.168.2.1: bytes=32 time<1ms TTL=64
Reply from 192.168.2.1: bytes=32 time=1ms TTL=64
Reply from 192.168.2.1: bytes=32 time<1ms TTL=64
Reply from 192.168.2.1: bytes=32 time<1ms TTL=64
Reply from 192.168.2.1: bytes=32 time<1ms TTL=64

Ping statistics for 192.168.2.1:
Packets: Sent = 5, Received = 5, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 1ms, Average = 0ms
Control-C

Even the traceroutes are strange:

This is the normal traceroute which is the actual ping times to the ISPs router as I have a wired GiGE going to the HP Layer 3 Managed Switch is 5-6ms for comparison:

Tracing route to google.com [74.125.239.101]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms DD-WRT-NETGEAR-R7000 [192.168.2.1]
2 7 ms 6 ms 7 ms x-x-x-1.dsl.static.sonic.net [x.x.x.1]

3 7 ms 7 ms 7 ms 127.at-X-X-X.gw3.200p-sf.sonic.net [208.106.96.1
93]
4 7 ms 11 ms 7 ms 0.ae2.gw.200p-sf.sonic.net [70.36.211.53]
5 9 ms 10 ms 8 ms 0.xe-5-1-0.gw.equinix-sj.sonic.net [208.106.27.1
21]
6 10 ms 14 ms 13 ms eqixsj-google-gige.google.com [206.223.116.21]
7 12 ms 10 ms 12 ms 216.239.49.170
8 69 ms 12 ms 11 ms 66.249.95.29
9 480 ms 11 ms 10 ms nuq05s01-in-f5.1e100.net [74.125.239.101]

Trace complete.

dd-wrt on 90% of the traceroutes I do seem to increase the 7ms first hop to ISP ping times to 20+ms:
Tracing route to google.com [50.0.2.207]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms DD-WRT-NETGEAR-R7000 [192.168.2.1]
2 23 ms 39 ms 23 ms x-x-x-1.dsl.static.sonic.net [x.x.x.1]

3 25 ms 24 ms 28 ms 127.at-X-X-X.gw3.200p-sf.sonic.net [208.106.96.1
93]
4 25 ms 25 ms 150 ms 0.ae2.gw.200p-sf.sonic.net [70.36.211.53]
5 23 ms 23 ms 23 ms as0.gw2.200p-sf.sonic.net [208.106.96.250]
6 108 ms 24 ms 23 ms 0.ge-7-2-0.gw.pao1.sonic.net [69.12.211.117]
7 27 ms 7 ms 8 ms cache.google.com [50.0.2.207]

Trace complete.

Here's a traceroute from the DD-WRT CLI:

traceroute to google.com (74.125.239.110), 30 hops max, 38 byte packets
1 x-x-x-1.dsl.static.sonic.net (x.x.x.1) 5.428 ms 5.427 ms 6.338
ms
2 127.at-X-X-X.gw3.200p-sf.sonic.net (208.106.96.193) 11.776 ms 5.739 ms 6.
247 ms
3 0.ae2.gw.200p-sf.sonic.net (70.36.211.53) 5.980 ms 5.827 ms 5.986 ms
4 0.xe-5-1-0.gw.equinix-sj.sonic.net (208.106.27.121) 7.958 ms 7.274 ms 7.2
65 ms
5 eqixsj-google-gige.google.com (206.223.116.21) 8.659 ms 8.988 ms 8.646 ms
6 216.239.49.170 (216.239.49.170) 10.668 ms 21.346 ms 10.388 ms
7 66.249.95.29 (66.249.95.29) 14.081 ms 9.226 ms 9.034 ms
8 nuq05s01-in-f14.1e100.net (74.125.239.110) 9.157 ms 9.192 ms 8.949 ms
post #284 of 618
Yes, there are multiple ways of doing a simple reset to factory defaults, I think that you hit them all, and then there's the 30-30-30 reset equivalent. What the 30-30-30 reset is supposed to do is go into the router's "recovery mode", where you can use tftp on your computer to send firmware image to the router. This is like an almost last resort (serial cable, etc. is actual last resort *smile*) fallback to rescue your router, and shouldn't be needed unless something really bad happens. It is equivalent to using the "firmware rescue" utility with Asus routers, only you have to do it manually with tftp. If things are going as they should, you should be always be flashing using the administration firmware upgrade, as you know *smile*.

And yes, that why the "Initial" firmware is supplied for getting to dd-wrt, about the only reason for it as far as I know, is because Netgear stock firmware only allows flashing .chk files (which is most likely a good thing for preventing major mistakes). After you've flashed .chk from dd-wrt, it then is set up to flash .bin firmware images, which is the full dd-wrt firmware image.

I'll look at 2.4GHz. channel 11, then to see how my pings look there. By the way, I have a Linksys AE3000 USB network adapter, which I find very useful. It only cost me about $50 new (probably less, now), and does 450Mbps on both 2.4 and 5GHz. I've gotten a lot of use out of it *smile*. I suppose that the weird pings you're seeing could even be the network adapter driver doing something weird, don't know. I assume that you've got the latest driver for your wireless network adapter.

Sounds like you're on the right track, now, so enjoy. I'm finding dd-wrt to be very functional and stable. My intention is to stay with it until Netgear drops its next firmware release. Then I'll decide if I want to try it, after I see the early reviews *smile*.

Edit: Just did a whole load of pings to my router on channel 11, and nearly all were 1ms. a few were anomalous, up to 22ms max, but no alternating patterns, nothing over the 22ms (which may have hit the system when it was doing something *smile*). About what I expected, 2.4GHz. is busier and has more going on than 5GHz., so I would expect to see that in the ping results. Haven't seen what you're seeing yet, but I only did a couple of series of pings, about 60 pings each time.
Edited by RogerSC - 2/7/14 at 2:55pm
post #285 of 618
Hmm, i thought for dd-wrt, power off/power on then holding reset for 10 seconds is called a CFE reset whatever that is. I know about the recovery mode which is almost like how to unbrick a device. I wouldn't mind tftp flashing a device over the network as I do have a tftp server which I need to use for flashing the enterprise HP switch I have.

Since the initial firmware file always matches the version of the latest dd-wrt firmware, I wonder what the differences are between the initial and the actual .bin file when flashed as they are both about 18MB in size. I was trying to find a 3 stream USB adapter, I have the Netgear AC1200 which is 867Mbps but haven't tried it yet since it's shrinkwrapped. Are you using a internal wifi card on the notebook? Since I think like I said before, the Atheros 150N inside notebooks do not handle mixed mode properly since single channel is always 65Mbps and two channels is 150Mbps link rate. I know it works with my NETGEAR FWAG114 which is a Atheros 108Mbps Super G ProSafe VPN/Router so perhaps I'll look at getting the Intel AC NIC cards for the notebook and see if it makes a difference. Either that or there are some R7000's that have defective hardware since it's always possible to get a lemon. On my pings, basically I do about 120 pings each time, ctrl-c and then do the next one. I mean the weird part is if it's weird behavior, even each ping would vary but either they are all fine or they will have the problem as mentioned earlier. I'll reflash to stock and then the latest initial and .bin for dd-wrt sometime late tonight and see if it makes a difference. Still trying to figure out what the difference is between:

6+2 when I select channel 6
11-7 when I select channel 11
in inSSIDER as dd-wrt shows it as 11+7. I wonder what the - or + means.
post #286 of 618
Quote:
Originally Posted by Almighty2 View Post

Hmm, i thought for dd-wrt, power off/power on then holding reset for 10 seconds is called a CFE reset whatever that is. I know about the recovery mode which is almost like how to unbrick a device. I wouldn't mind tftp flashing a device over the network as I do have a tftp server which I need to use for flashing the enterprise HP switch I have.

Since the initial firmware file always matches the version of the latest dd-wrt firmware, I wonder what the differences are between the initial and the actual .bin file when flashed as they are both about 18MB in size. I was trying to find a 3 stream USB adapter, I have the Netgear AC1200 which is 867Mbps but haven't tried it yet since it's shrinkwrapped. Are you using a internal wifi card on the notebook? Since I think like I said before, the Atheros 150N inside notebooks do not handle mixed mode properly since single channel is always 65Mbps and two channels is 150Mbps link rate. I know it works with my NETGEAR FWAG114 which is a Atheros 108Mbps Super G ProSafe VPN/Router so perhaps I'll look at getting the Intel AC NIC cards for the notebook and see if it makes a difference. Either that or there are some R7000's that have defective hardware since it's always possible to get a lemon. On my pings, basically I do about 120 pings each time, ctrl-c and then do the next one. I mean the weird part is if it's weird behavior, even each ping would vary but either they are all fine or they will have the problem as mentioned earlier. I'll reflash to stock and then the latest initial and .bin for dd-wrt sometime late tonight and see if it makes a difference. Still trying to figure out what the difference is between:

6+2 when I select channel 6
11-7 when I select channel 11
in inSSIDER as dd-wrt shows it as 11+7. I wonder what the - or + means.

Yes, I don't know about the "+"'s and "-"'s, my intuition would say "+" is upper, and "-" is lower. Which doesn't really help with 6+2, seems like it should be 6-2. I don't use 40MHz. channels on 2.4GHz. here, too crowded. Only on 5GHz., and wireless status currently says "161+157". I have it set for channel 161, and the extension channel is upper. There is no upper channel, so the router is using 161 and lower. But it doesn't show 161-157, just 161+157, in that order. So, since there's no "upper" above 161, it uses 157 below it. So there isn't anything obvious about the +'s and -'s.

You might ask this one on the dd-wrt forum *smile*. It isn't a burning question for me, same for the content of the "Initial" .chk firmware image, so I wouldn't bother to ask either question *smile*.

Edit: Ah, here's a quote from the firmware maintainer on the current dd-wrt firmware images (r23550): "With this build I also updated the intial chk files, they are identical to the bin files, thus it is not necessary to load the bin after the chk file." You have to be careful though, the timestamp on the "Initial" file isn't always the same as the .bin firmware image, so he doesn't always update the .chk like he did this time, I know that for sure. So I guess it's easier (for me) to just flash the .chk and then the .bin, and not worry about whether they're the same image or not *smile*.

Oh yeah, you asked about my wireless network adapter...the one in my laptop is a single stream, 150Mbps max adapter. The one that I'm using is the Linksys AE3000 USB adapter that I mentioned earlier. It's 3-stream, 450Mbps on both 2.4 and 5GHz. It was pretty cheap when I got it a while ago, and seems to work just fine. May be cheaper now, too.
Edited by RogerSC - 2/7/14 at 4:00pm
post #287 of 618
This is an intense conversation...
post #288 of 618
You are probably right about the "+"s and "-"'s although who knows since basically on the Wireless tab under Wireless Physical Interface, if you change the Extension channel and then click on Save, you will see the Wireless Channel selection has either changed or the list is different since it seems when extension is on upper for 2.4Ghz for example, it will only show channels 6 and under available in the Wireless Channel selection and when it's on upper, it will show only channels above 6 in the Wireless Channel selection.

I was trying to use inSSIDer on my Android phone which has both 2.4Ghz and 5Ghz to see if it shows the secondary channels but it seems the mobile app only shows the primary channel but according to status -> Wireless page, it shows my 5Ghz using 149 + 155. From what I remember, when it's on 80Mhz, it's supposed to have one primary and 3 secondary channels or 4 channels in total, atleast on the NETGEAR firmware.

It's not a burning question for me either but sometimes learning exactly what it means might be a learning experience since it's weird it would show channels 7-11 when it's on lower and when it's on upper, it would show channels 1-6. I think dd-wrt would work better if you choose the Extension Channel and then it just updates the Wireless Channel selection list instead of having to hit save first before it updates.

Seems like both r23490 and r23550 have updated initial .chk files to match except this post mentions something interesting that neither of us did:
http://www.dd-wrt.com/phpBB2/viewtopic.php?p=877930&sid=7d513a15557bac031ee66cbefcb322b9#877930

"Yes, but be carefull, if you are on stock firm you first have to load Initial fo Netagear r7000 at http://www.desipro.de/ddwrt/K3-AC-Arm/Initial/ then wait 5 minutes up to when router finishes it load.
After that follow the prompts, then you can load the latest one, at same time check the box "reset to default settings" and always wait 5 minutes, don't hurry you can brick.
If you are on dd-wrt just "reset to defaults" and load the latest that up to now is the best one. "

So not sure if waiting the 5 minutes or not makes the difference.

I don't have a account on the dd-wrt forums yet but I figure it's a good time to create one which I just did.

You are right about the timestamp since I only look at the date, not the time for the file so it can be different and for all I know, the .bin might be a newer revision even though the version reads the same.

What wireless chipset does your laptop wireness network adapter use? It seems the AE3000 got replaced with the AE3000-NP, are these simultaneous dual band adapters or can you only use one channel at a time? I never even realized there were 3 stream USB adapters since I thought 2 streams was normal.

Anyways, this is what my inSSIDer looks like, other than the ones I've crossed out, which channel would you use for the primary channel?

LEAD Technologies Inc. V1.01
LEAD Technologies Inc. V1.01
Edited by Almighty2 - 2/7/14 at 10:02pm
post #289 of 618

Has anyone heard if Netgear plans on adding ReadyCloud to the R7000 in the near future?

post #290 of 618
From what I see in your inSSIDer graphics, I'd just use channel 1 or 11 and 20MHz. channel width. But that's me. If you're going to use a 40MHz. channel width with all those other signals, I don't know if it would be stable, since you might find it backing off to 20MHz. anyways with that strong signal you're competing with on channel 6...and your neighbors might lynch you if they found who owned that wireless network that was taking up 1/2 of the available bandwidth...Like I said, just my opinion. If I were going to do high bandwidth streaming, I'd do it on 5GHz.,, no question. Very little interference around here, works great. I just use 2.4GHz. for mobile phones, a Verizon Network Extender, a Kindle, and casual surfing, etc. Like I said, my laptop, that I do stream to occasionally *smile* is connected on 5GHz., using a 40MHz. channel.

And yes, I remember several of Kong's releases where he didn't change the "Initial" firmware image, so I just flash 'em both and don't worry about it. The intermediate flash doesn't take any time, I just set user/password, and go straight to "Administration" and flash the .bin image.
post #291 of 618
Now you know I wasn't kidding about this being a busy wireless neighborhood despite that I live in a neighborhood in the city/county of San Francisco which is supposed to be one of the least-densely populated neighborhoods.

The only problem with the 20Mhz is with this notebook, single channel connects at 65Mbps while bonded channel will connect at 150Mbps. Now that you mention the word lynch, I remember reading something about this neighborhood so I decided to Google it and basically it says that this neighborhood was so quiet that in 1971 a newspaper profile called it "An Island of Tranquility Amidst Big City Turmoil." A year later some of that big city turmoil showed up in a series of bizarre and gruesome pet lynchings that took place in Forest Hill Extension. After a few days of sensationalism and headlines, the police identified a teen-aged girl as the killer. Guess we don't need another lynching because of some guy talking up 1/2 of the available bandwidth on channel 6 some 42 years later. I know channel 1 doesn't work well with 40Mhz mode because that was the one I got unreliable connections with the V1.0.2.197_1.0.17 stock NETGEAR firmware where it will keep losing the connection. Don't you mean using 2.4Ghz for cordless phones as mobile phones only work at 850Mhz/1.9Ghz. As far as your laptop, do you happen to know what brand is the wireless NIC you're using? I just know it isn't Atheros and probably Intel if my guess is right. As for the 5Ghz, I always thought 80Mhz is supposed to use 4 channels and not just 2 since basically each 20Mhz is 1 channel. Atleast on the stock NETGEAR firmware, it always has one primary and 3 secondary channels but dd-wrt seems to only use 2 channels on 80Mhz.

In any case, I'm writing as I am flashing and here is what I did:
1) from dd-wrt r23550, I flashed NETGEAR V1.0.0.96_1.0.15 stock firmware using the Admin page and then selected reset to defaults.
2) When it rebooted, I then powered the unit off to check the antennas since it seems very easy to have the screw losen.
3) I took off all the antennas and then applied Caig Deoxit D100 on the gold plated areas on both the antenna side and the router side as it Improves Conductivity, Deoxidizes, Cleans & Preserves, Reduces Intermittent Connections, Reduces Arcing & RFI, Reduces Wear & Abrasion and then screw the antennas back on to make sure it's tight and then powered on.
4) After I was able to connect to webadmin, I did the reset using the reset button for 8 seconds and allowed it to boot up.
5) I then proceeded to flash dd-wrt r23550's initial dd-wrt.K3_R7000.chk and waited until I can connect to the router and the webadmin
6) At this point, I wait for the uptime to be atleast 5 minutes before I flash dd-wrt's r23550's dd-wrt24-K3_AC_ARM.bin file and select reset to factory defaults and let it reboot until I can connect to the router and the webadmin.
As I have a connection with the default settings with dd-wrt using channel 6 which I think is on auto, this is the ping results:

Pinging 192.168.1.1 with 32 bytes of data:
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64
Reply from 192.168.1.1: bytes=32 time=4ms TTL=64
Reply from 192.168.1.1: bytes=32 time=19ms TTL=64
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64
Reply from 192.168.1.1: bytes=32 time=3ms TTL=64
Reply from 192.168.1.1: bytes=32 time=3ms TTL=64
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64
Reply from 192.168.1.1: bytes=32 time=3ms TTL=64
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64
Reply from 192.168.1.1: bytes=32 time=7ms TTL=64
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64
Reply from 192.168.1.1: bytes=32 time=25ms TTL=64
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64
Reply from 192.168.1.1: bytes=32 time=3ms TTL=64
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64
Reply from 192.168.1.1: bytes=32 time<1ms TTL=64
Reply from 192.168.1.1: bytes=32 time=5ms TTL=64
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64

Ping statistics for 192.168.1.1:
Packets: Sent = 24, Received = 24, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 25ms, Average = 3ms
Control-C
^C
C:\Users\Vince>ping -t 192.168.1.1

Pinging 192.168.1.1 with 32 bytes of data:
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64
Reply from 192.168.1.1: bytes=32 time=446ms TTL=64
Reply from 192.168.1.1: bytes=32 time<1ms TTL=64
Reply from 192.168.1.1: bytes=32 time=443ms TTL=64
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64
Reply from 192.168.1.1: bytes=32 time=445ms TTL=64
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64
Reply from 192.168.1.1: bytes=32 time=451ms TTL=64
Reply from 192.168.1.1: bytes=32 time<1ms TTL=64
Reply from 192.168.1.1: bytes=32 time=462ms TTL=64
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64

Ping statistics for 192.168.1.1:
Packets: Sent = 14, Received = 14, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 462ms, Average = 161ms

So it still has that behavior even on a single 20Mhz channel 6 which is crowded as you said earlier.

7) At this point, I wait for the uptime to be atleast 5 minutes before I hold down the reset button for 10 seconds to do the reset to factory defaults and let it boot.
8) After connecting and getting in to the webadmin, I configure everything, clicking save on everything I changed and then click on Apply settings at the Administration page and reboot the router from the same page. Saving, clicking tabs and applying settings are all very fast and instant. The configuration process took
21 minutes total.
9) When the router reboots, I power off and wait 30 seconds and then turn on the router.
One thing I noticed is that from the Status -> Wireless page, under Wireless Packet Info:
For 2.4Ghz:
Received (RX)
100%3550 OK, no error
Transmitted (TX)
100%4650 OK, 1 errors

For 5.0Ghz:
Received (RX)
100%118 OK, no error
Transmitted (TX)
100%975 OK, 3 errors

This has 5 clients connected including my notebook

And as I finish that process, let's see the results of ping using different channels:

With router on single 20Mhz channel/channel 1:

Pinging 192.168.2.1 with 32 bytes of data:
Reply from 192.168.2.1: bytes=32 time=17ms TTL=64
Reply from 192.168.2.1: bytes=32 time=47ms TTL=64
Reply from 192.168.2.1: bytes=32 time=1ms TTL=64
Reply from 192.168.2.1: bytes=32 time=1ms TTL=64
Reply from 192.168.2.1: bytes=32 time=1ms TTL=64
Reply from 192.168.2.1: bytes=32 time=1ms TTL=64
Reply from 192.168.2.1: bytes=32 time=1ms TTL=64
Reply from 192.168.2.1: bytes=32 time=79ms TTL=64
Reply from 192.168.2.1: bytes=32 time<1ms TTL=64
Reply from 192.168.2.1: bytes=32 time=115ms TTL=64
Reply from 192.168.2.1: bytes=32 time=1ms TTL=64
Reply from 192.168.2.1: bytes=32 time=110ms TTL=64
Reply from 192.168.2.1: bytes=32 time=1ms TTL=64

Ping statistics for 192.168.2.1:
Packets: Sent = 13, Received = 13, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 115ms, Average = 28ms

Pinging 192.168.2.1 with 32 bytes of data:
Reply from 192.168.2.1: bytes=32 time=1ms TTL=64
Reply from 192.168.2.1: bytes=32 time=117ms TTL=64
Reply from 192.168.2.1: bytes=32 time=2ms TTL=64
Reply from 192.168.2.1: bytes=32 time=113ms TTL=64
Reply from 192.168.2.1: bytes=32 time=1ms TTL=64
Reply from 192.168.2.1: bytes=32 time=127ms TTL=64
Reply from 192.168.2.1: bytes=32 time=2ms TTL=64
Reply from 192.168.2.1: bytes=32 time=142ms TTL=64
Reply from 192.168.2.1: bytes=32 time=1ms TTL=64
Reply from 192.168.2.1: bytes=32 time=157ms TTL=64

Ping statistics for 192.168.2.1:
Packets: Sent = 10, Received = 10, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 1ms, Maximum = 157ms, Average = 66ms

Pinging 192.168.2.1 with 32 bytes of data:
Reply from 192.168.2.1: bytes=32 time=1ms TTL=64
Reply from 192.168.2.1: bytes=32 time=91ms TTL=64
Reply from 192.168.2.1: bytes=32 time=1ms TTL=64
Reply from 192.168.2.1: bytes=32 time=104ms TTL=64
Reply from 192.168.2.1: bytes=32 time=1ms TTL=64
Reply from 192.168.2.1: bytes=32 time=137ms TTL=64
Reply from 192.168.2.1: bytes=32 time=1ms TTL=64
Reply from 192.168.2.1: bytes=32 time=140ms TTL=64
Reply from 192.168.2.1: bytes=32 time=1ms TTL=64
Reply from 192.168.2.1: bytes=32 time=158ms TTL=64
Reply from 192.168.2.1: bytes=32 time=1ms TTL=64
Reply from 192.168.2.1: bytes=32 time=160ms TTL=64
Reply from 192.168.2.1: bytes=32 time=1ms TTL=64
Reply from 192.168.2.1: bytes=32 time=198ms TTL=64
Reply from 192.168.2.1: bytes=32 time=1ms TTL=64
Reply from 192.168.2.1: bytes=32 time=191ms TTL=64
Reply from 192.168.2.1: bytes=32 time=1ms TTL=64
Reply from 192.168.2.1: bytes=32 time=191ms TTL=64
Reply from 192.168.2.1: bytes=32 time=1ms TTL=64
Reply from 192.168.2.1: bytes=32 time=230ms TTL=64
Reply from 192.168.2.1: bytes=32 time=1ms TTL=64

Ping statistics for 192.168.2.1:
Packets: Sent = 21, Received = 21, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 1ms, Maximum = 230ms, Average = 76ms

With router on single 20Mhz channel/channel 11:

Pinging 192.168.2.1 with 32 bytes of data:
Reply from 192.168.2.1: bytes=32 time=71ms TTL=64
Reply from 192.168.2.1: bytes=32 time=1ms TTL=64
Reply from 192.168.2.1: bytes=32 time=45ms TTL=64
Reply from 192.168.2.1: bytes=32 time=3ms TTL=64
Reply from 192.168.2.1: bytes=32 time=29ms TTL=64
Reply from 192.168.2.1: bytes=32 time<1ms TTL=64
Reply from 192.168.2.1: bytes=32 time=57ms TTL=64
Reply from 192.168.2.1: bytes=32 time<1ms TTL=64
Reply from 192.168.2.1: bytes=32 time=42ms TTL=64

Ping statistics for 192.168.2.1:
Packets: Sent = 9, Received = 9, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 71ms, Average = 27ms

Pinging 192.168.2.1 with 32 bytes of data:
Reply from 192.168.2.1: bytes=32 time=1ms TTL=64
Reply from 192.168.2.1: bytes=32 time<1ms TTL=64
Reply from 192.168.2.1: bytes=32 time<1ms TTL=64
Reply from 192.168.2.1: bytes=32 time=1ms TTL=64
Reply from 192.168.2.1: bytes=32 time<1ms TTL=64
Reply from 192.168.2.1: bytes=32 time=3ms TTL=64
Reply from 192.168.2.1: bytes=32 time=2ms TTL=64
Reply from 192.168.2.1: bytes=32 time<1ms TTL=64
Reply from 192.168.2.1: bytes=32 time<1ms TTL=64
Reply from 192.168.2.1: bytes=32 time=2ms TTL=64
Reply from 192.168.2.1: bytes=32 time<1ms TTL=64

Ping statistics for 192.168.2.1:
Packets: Sent = 11, Received = 11, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 3ms, Average = 0ms

Pinging 192.168.2.1 with 32 bytes of data:
Reply from 192.168.2.1: bytes=32 time=1ms TTL=64
Reply from 192.168.2.1: bytes=32 time=1ms TTL=64
Reply from 192.168.2.1: bytes=32 time=34ms TTL=64
Reply from 192.168.2.1: bytes=32 time<1ms TTL=64
Reply from 192.168.2.1: bytes=32 time<1ms TTL=64
Reply from 192.168.2.1: bytes=32 time=1ms TTL=64
Reply from 192.168.2.1: bytes=32 time<1ms TTL=64
Reply from 192.168.2.1: bytes=32 time=2ms TTL=64
Reply from 192.168.2.1: bytes=32 time=1ms TTL=64
Reply from 192.168.2.1: bytes=32 time<1ms TTL=64

Ping statistics for 192.168.2.1:
Packets: Sent = 10, Received = 10, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 34ms, Average = 4ms

Pinging 192.168.2.1 with 32 bytes of data:
Reply from 192.168.2.1: bytes=32 time=114ms TTL=64
Reply from 192.168.2.1: bytes=32 time=1ms TTL=64
Reply from 192.168.2.1: bytes=32 time=48ms TTL=64
Reply from 192.168.2.1: bytes=32 time<1ms TTL=64
Reply from 192.168.2.1: bytes=32 time=48ms TTL=64
Reply from 192.168.2.1: bytes=32 time=2ms TTL=64
Reply from 192.168.2.1: bytes=32 time=48ms TTL=64
Reply from 192.168.2.1: bytes=32 time<1ms TTL=64
Reply from 192.168.2.1: bytes=32 time=181ms TTL=64
Reply from 192.168.2.1: bytes=32 time<1ms TTL=64
Reply from 192.168.2.1: bytes=32 time=64ms TTL=64
Reply from 192.168.2.1: bytes=32 time=1ms TTL=64
Reply from 192.168.2.1: bytes=32 time=44ms TTL=64
Reply from 192.168.2.1: bytes=32 time=1ms TTL=64
Reply from 192.168.2.1: bytes=32 time=62ms TTL=64
Reply from 192.168.2.1: bytes=32 time=1ms TTL=64
Reply from 192.168.2.1: bytes=32 time=45ms TTL=64
Reply from 192.168.2.1: bytes=32 time=1ms TTL=64
Reply from 192.168.2.1: bytes=32 time=65ms TTL=64
Reply from 192.168.2.1: bytes=32 time<1ms TTL=64
Reply from 192.168.2.1: bytes=32 time=43ms TTL=64

Ping statistics for 192.168.2.1:
Packets: Sent = 21, Received = 21, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 181ms, Average = 36ms
post #292 of 618
For Almighty and RogerSC:

Just to clear things up for you guys and I hope this helps(been in the DD-WRT community for a bit). According to Kong(the dev working on the R7000 project) here's a quote on the r23550 build.

"With this build I also updated the intial chk files, they are identical to the bin files, thus it is not necessary to load the bin after the chk file.

I recommend to reset to factory defaults through webif this time, so we can be sure you start with the default params which are now well tested.

I did some serious testing this time + went through all the trac tickets and fixed a few older bugs.

I consider this one of the best dd-wrt builds ever. I might use this revision to only fix bugs and release updates without adding new stuff that has the potential to break things again."

Hope this helps clear up a few things.
post #293 of 618
Thread Starter 
Quote:
Originally Posted by ae1245 View Post

Has anyone heard if Netgear plans on adding ReadyCloud to the R7000 in the near future?

Yes ReadyCloud will be added. It is undergoing a complete redesign and will be a few months before released. But the R7000 with most certainly have it.

Bob Silver Netgear AV Consultant
post #294 of 618
Quote:
Originally Posted by Helidoc View Post

For Almighty and RogerSC:

Just to clear things up for you guys and I hope this helps(been in the DD-WRT community for a bit). According to Kong(the dev working on the R7000 project) here's a quote on the r23550 build.

"With this build I also updated the intial chk files, they are identical to the bin files, thus it is not necessary to load the bin after the chk file.

I recommend to reset to factory defaults through webif this time, so we can be sure you start with the default params which are now well tested.

I did some serious testing this time + went through all the trac tickets and fixed a few older bugs.

I consider this one of the best dd-wrt builds ever. I might use this revision to only fix bugs and release updates without adding new stuff that has the potential to break things again."

Hope this helps clear up a few things.

Yes, thank you for helping, I read this on the R7000 dd-wrt forum as well. I also quoted the part of this that mentions that he updated the .chk Initial firmware age above.
post #295 of 618
It might be helpful if the DD-WRT discussions were moved to a dedicated thread.

While it is true that they pertain to the R7000 hardware, they are off topic for those of us that prefer to stay with the Netgear Firmware.
post #296 of 618
Quote:
Originally Posted by Almighty2 View Post

Don't you mean using 2.4Ghz for cordless phones as mobile phones only work at 850Mhz/1.9Ghz. As far as your laptop, do you happen to know what brand is the wireless NIC you're using? I just know it isn't Atheros and probably Intel if my guess is right. As for the 5Ghz, I always thought 80Mhz is supposed to use 4 channels and not just 2 since basically each 20Mhz is 1 channel. Atleast on the stock NETGEAR firmware, it always has one primary and 3 secondary channels but dd-wrt seems to only use 2 channels on 80Mhz.

By mobile phones, I mean like our iPhone and Samsung S3, which we use on 2.4GHz. We have the DECT cordless home phones, and they're on 1.9GHz. And my USB network adapter is Ralink-based. There are several online databases where you can look up the chipset of an adapter from the model number. Tim Higgins pointed out to me a while ago that he has that information online at Smallnetbuilder, as well, which I didn't know.

Anyways, I see that your ping times can be really inconsistent...what is your experience surfing the internet and streaming? Does it seem sluggish at all, or as fast as you're used to? My experience, when I see that kind of inconsistent ping time, takes me to thinking about wireless adapters and adapter drivers. Also, if you are getting a lot of interference on 2.4GHz., like too much signal from neighbors, that could most likely cause your router to exhibit this sort of inconsistent behavior as well, which suggests using 5GHz. band as much as possible. On 2.4GHz., I can pick a channel (channel 6 for me) where there is some interference but not enough to be a problem. If you don't have that opportunity, then 5GHz. is a better bet. It could be a broken router, but that's the last thing that I would exchange, you would probably have the same results with another router.

To summarize for 2.4GHz., I would spend more time with inSSIDer, use 20MHz. channel width on the most open channel that I could find, and update my wireless network driver (and perhaps try a different wireless adapter, as well). But would also be planning to switch over to 5GHz. as much as possible, that's really where your router is designed to shine *smile*.
post #297 of 618
Quote:
Originally Posted by RDHolmes View Post

It might be helpful if the DD-WRT discussions were moved to a dedicated thread.

While it is true that they pertain to the R7000 hardware, they are off topic for those of us that prefer to stay with the Netgear Firmware.

I agree, that's what the dd-wrt forum is for. Things did get a little out of hand here, I really apologize to those that were not interested in this discussion. There didn't seem to be much discussion of the Netgear firmware, so I kind of got carried away.

Sorry.
post #298 of 618
Quote:
Originally Posted by Helidoc View Post

For Almighty and RogerSC:

Just to clear things up for you guys and I hope this helps(been in the DD-WRT community for a bit). According to Kong(the dev working on the R7000 project) here's a quote on the r23550 build.

"With this build I also updated the intial chk files, they are identical to the bin files, thus it is not necessary to load the bin after the chk file.

I recommend to reset to factory defaults through webif this time, so we can be sure you start with the default params which are now well tested.

I did some serious testing this time + went through all the trac tickets and fixed a few older bugs.

I consider this one of the best dd-wrt builds ever. I might use this revision to only fix bugs and release updates without adding new stuff that has the potential to break things again."

Hope this helps clear up a few things.

Actually, RogerSC already quoted what you wrote in a post earlier and I saw the same post on the dd-wrt forums yesterday. Before kong posted that sometime yesterday after I already installed r2350, I was saying that the r23490 was in both the .chk and the .bin files. I think the only thing I was trying to figure out before kong wrote that was even if the version was the same, was the chk file's contents different but guess not.
post #299 of 618
Quote:
Originally Posted by RDHolmes View Post

It might be helpful if the DD-WRT discussions were moved to a dedicated thread.

While it is true that they pertain to the R7000 hardware, they are off topic for those of us that prefer to stay with the Netgear Firmware.

Actually, the discussions are not off topic because the topic of the thread is "Netgear R7000 Review and Comments" which would include discussing all the options available. If it was about DD-WRT only and doesn't involve the R7000, that would be off-topic but in this case, we were all trying to see if the problem was caused by the Netgear firmware or if it's the hardware itself. Normally, with hardware in general, you don't have a choice with software but with the R7000, even Netgear on their product page claims open source support which includes dd-wrt. Many of us would prefer Netgear firmware too but as everyone knows by now, it has it's own share of problems as seen on this and other forums. When you have an alternative firmware such as dd-wrt used in a comparison, it is one way to know if the problem is really their firmware or not. As in my case, it appears the problem is either the hardware or I just happen to have a defective unit since while all hardware might have certain specs, they will never be 100% identical, some will exceed the specs and some will not. So there will be those who prefer to stay with the official firmware or choose to run anything but the official firmware, that is a personal choice and as long as the discussion involves the Netgear R7000 in any way, shape or form, it would be on-topic.
post #300 of 618
Quote:
Originally Posted by Almighty2 View Post

Actually, the discussions are not off topic because the topic of the thread is "Netgear R7000 Review and Comments" which would include discussing all the options available. If it was about DD-WRT only and doesn't involve the R7000, that would be off-topic but in this case, we were all trying to see if the problem was caused by the Netgear firmware or if it's the hardware itself. Normally, with hardware in general, you don't have a choice with software but with the R7000, even Netgear on their product page claims open source support which includes dd-wrt. Many of us would prefer Netgear firmware too but as everyone knows by now, it has it's own share of problems as seen on this and other forums. When you have an alternative firmware such as dd-wrt used in a comparison, it is one way to know if the problem is really their firmware or not. As in my case, it appears the problem is either the hardware or I just happen to have a defective unit since while all hardware might have certain specs, they will never be 100% identical, some will exceed the specs and some will not. So there will be those who prefer to stay with the official firmware or choose to run anything but the official firmware, that is a personal choice and as long as the discussion involves the Netgear R7000 in any way, shape or form, it would be on-topic.

I beg to differ. 99.9% or more of the purchasers of the R7000 are going to use the Netgear Firmware. I would suspect that more than 70% of the readers of this forum would NOT be interested in using third party Firmware.

Please use the appropriate thread for the DD-WRT discussions.
New Posts  All Forums:Forum Nav:
  Return Home
AVS › AVS Forum › Gaming & Content Streaming › Networking, Media Servers & Content Streaming › Netgear R7000 Nighthawk AC1900 Router Review and Comments Thread