Reply
Highlighted
Tutor

New R7000 Owner, Stunned by Bugs, Bad Support

Hello All,

Sorry in advance for ranting on my first post.
I'm about 9 days into attempted use of an R7000.
I'm coming from an ASUS RT-N16 running Tomato which has been incredibly rock solid.
I'm not a router / wireless / network expert, but I'm at the higher end of the technically competent scale.

I chose the R7000 based on the glowing buzz out there. Should have done more homework before pulling the trigger.

My network topology and usage are reasonably straightforward. I have cable internet delivered by an ARRIS docsis 3 cable modem. R7000 is the next in line. It serves as my wireless access point, firewall and dhcp server. I only have 1 device hard wired to the R7000, an HP ProCurve 1810G-24 switch which serves my hardwired network devices.
This is for a home / home office environment with 40+ wired and wireless devices of various types. I only use one subnet, 192.168.0.xxx. I use 0.xxx for historical reasons and ease of dealing with a couple of devices with fixed IP addresses.

I'm currently running Netgear's latest firmware: V1.0.3.56_1.1.25. I'm tempted to try Tomato and DD-WRT, but most likely I'll just return the R7000.

I found the web administration with the genie software to be fairly straightforward. UI is better than past efforts but could benefit from some UI/UX attention.

DHCP

I like to reserve IP addresses for the known / fairly static clients in my network and serve a smaller range of dynamic IP addresses for transient clients, visitors and new devices. Makes it easier to access the stable network clients while keeping an eye on what's new.

I haven't found a nice way to do this yet on the R7000. If I create static reservations in the xxx.xxx.xxx.2-xxx.xxx.xxx.127 range and then specify the DHCP range as xxx.xxx.xxx.128-xxx.xxx.xxx.254, the static reservations outside that range aren't served to their devices. I had to specify the whole 2-254 range for DHCP in order to have the static assignments properly delivered. Irritating. Now the dynamically served IP addresses intermingle with the statics, making it hard to easily see which is which.

I've found that the DHCP server sometimes provides incorrect DNS entries to the clients. I hard specify two DNS IP addresses, so it doesn't seem like this should be tough to do right.

I've found that the DHCP server doesn't always retain the name/description of devices as given in the static reservation. Devices often show up with empty (---) values in the Attached Devices display.

I hate that you can't sort the DHCP reservation entries. They are shown in entry order. I would love to be able to sort by IP address, name, MAC, etc.

Performance

When it works, I'm really pleased with the performance. My new Macbook Pro AC wireless connection is faster than the wired gigabit ethernet (via the thunderbolt to ethernet adapter). Nice. My throughput to the WAN is no longer bottlenecked by the router as well. Nice.

Range

I have not done thorough testing, but I perceive the range to be substantially better than the ASUS it's supposed to replace.

Initial Teething Problems

Out of the box connection followed by an update to the current firmware, I was surprised to have odd issues with connectivity, both wired and wireless. I could get out to the internet on one client but not another. I could ping from client A to client B but not from client B to client A. I had wired devices (a windows home server and a Synology NAS) that would be accessible for a while, only to drop and become inaccessible. Irritating.

Calling and/or chatting with support

Really challenging experiences with substandard wait times and not-up-to-the-task technical support staff. After a long wait, followed by the serial number purchase date gauntlet, followed by the hard core upsell for premium support, I found that the "technician" really couldn't follow the basic situation of what my problem was. I simplified it down to a pretty easy conceptual problem and associated question(s), and the tech couldn't grasp the basics, wanted to take me through basic items like checking my SSID, password, which wireless bands were on, what list of devices, complete with MACs, desired IPs, versions, manufacturers, was I using or planned to use. Really? Really. I was hoping for a much better technical support experience and had left the router in it's "odd state" thinking they might want to examine logs or peak at it while it was not behaving. Wrong. The first solution was to power cycle the device. OK. I'd already done that. It usually improved the situation, at least for a while. I didn't need them to suggest that and I certainly can't see power cycling the router or rebooting the router at some regular interval to keep things working. Grrr.

I was told to reflash the device with the latest firmware. I reset it to factory defaults, flashed it once, flashed it twice, reloaded the settings, had the same issues. I reset it and flashed it again, setting up a real simple wireless network and still ran into issues. It was sometimes usable, sometimes horrible, always unacceptable.

Routing Issues

A major irritation for me has to do with what I perceive to be routing / routing table issues. I read that others are having troubles with devices, often printers, becoming unreachable. That was one of my initial experiences as well, but with a twist. As I was setting up a new printer and installing drivers on various computers, I found that some computers installed the printer easily, others couldn't even see it. Hmm. Digging in, I found that I could ping the printer from two computers but couldn't ping it from another. All computers could ping each other. All devices showed up in the attached devices list on the R7000 admin page. I could access the admin page from all three computers. Odd. So I switched the printer to a hardwired ethernet. Initially I could see the printer from all three computers. After a bit, I could only see/ping it from one computer. What? It was acting like the routing table was getting corrupted. Just to clarify, I'm always pinging by IP address, not DNS name, all on the same subnet, no duplicate IP addresses, all devices visible in the attached devices page. If I can't ping a device on the network, the network really isn't of much value...

I tried to test all the variations: from the 2.4, from the 5G, from wired connection, to wired, to 2.4. No obvious standout problematic route. The problem was routes disappearing.

Last night, I waited 1.5 hours to speak with another fairly non technical support staffer. After explaining the basic situation, I was told that we needed to check my wireless setup, channels, interference, range, etc. I asked why, since the device currently unreachable from computer A could be reached from computers B and C. Clearly the radio connection between the R7000 and the device had to be working. The support person couldn't understand that logic, so we proceeded to examine, test and change all of the wireless settings, obviously to no avail. Numerous attempts to get escalated went unheeded. I'm terminally polite, but I was becoming beyond irritated. I've now been on the phone for over 3 hours, all the time knowing we haven't even begun to address the real problem. After untold number of holds, consults with others, etc. I was again told to reflash the firmware and that should fix the problem. Oh boy. I explained that I had already done this numerous times, and that doing so would not likely fix the problem and would mask our ability to diagnosis it. Another consult. The new solution was to reinstall the printer driver from the Win 7 x64 box that currently couldn't see the printer. I asked how I could install the printer driver if I can't ping the printer / see the printer from the computer. I was told the printer driver installer would fix it. Joy. I feel like I'm training the support staff in basic diagnosis / basic networking stuff. I was then told, after another hold/consult, that there was a setting on the R7000 that must be incorrect, only they couldn't find the location of the check box I needed to examine in the Genie admin page.

I politely gave up and determined the router and the associated support team are just not ready for prime time.

I immediately did some searching on DD-WRT and Tomato for the R7000. I may play with it for a bit, but it seems like there are still issues with both of those options.

I'm back to the ASUS for now. Rock solid. There's peace in my network and my home tech life (happy wife and kids).

While I enjoying dabbling at the bleeding edge of technology to a degree, I hate it when gear is so problematic, especially when it's supposed to be a centerpiece / critical element of my technical infrastructure. This $200 piece of wonder has cost me days of trouble without leading to a positive outcome. Seems sad they could release something that seems so not-ready-for-primetime. I would have been better off spending $1K and getting something stable, if there is such a beast out there.

Sorry for the long rant. Hopefully others will find it, find solidarity and find some kernel that helps them overcome their issue or spend less time coming to an understanding of what might be going on.

RMA is in process. The quest for a suitable replacement begins.
Message 1 of 21
Highlighted
Virtuoso

Re: New R7000 Owner, Stunned by Bugs, Bad Support

I would play with dd-wrt at this point. Tomato is coming, but not here yet. For reserving static addresses with dd-wrt, just leave the lease period field empty, that works for me. You'll find it stable, and the performance is great....I'm using Kong's version 24045M (NEWD STD version), works really well. For support, there's a whole forum devoted to Kong's releases for the R7000.

Note that if you have problems with the NEWD (new wireless drivers), you can just fall back to the OLDD version (old wireless drivers).

Or not, up to you, of course. Works really well for me, though.
Message 2 of 21
Highlighted
Novice

Re: New R7000 Owner, Stunned by Bugs, Bad Support

Yes, NetGear has been largely disappointing.....terrible. Given that they have the best of Broadcom drivers available, it would seem after this time this would be together.

I have been running DD-WRT Kong version firmware for months with great success. Currently, I just flashed Kong version 24170 NEWD (New Driver).

This hardware is powerful and good stuff with the right firmware. I have had three NetGears in a row, WNDR4500, R6300 v1, and this R7000. The R7000 has remarkable range and speed.

If you flash DD-WRT, be sure to flash the INITIAL build when going from NetGear. You don't have to change it to the DD-WRT right away (same build normally) but with .chk extension. But, then you use the normal DD-WRT .bin files after that.

I have flashed back to NetGear when they release a new firmware version to try it, but end up back on DD-WRT. The most recent NetGear firmware dropped my NAS constantly, rock solid on DD-WRT.
Message 3 of 21
Highlighted
Novice

Re: New R7000 Owner, Stunned by Bugs, Bad Support

Oops, I just checked and the INITIAL .chk file is from 8 April, but just flash 23900 or 24170 after that.

http://www.desipro.de/ddwrt/K3-AC-Arm/


There's the link.
Message 4 of 21
Highlighted
Mentor

Re: New R7000 Owner, Stunned by Bugs, Bad Support

I see a number of issues here that make me wonder ...

If I create static reservations in the xxx.xxx.xxx.2-xxx.xxx.xxx.127 range and then specify the DHCP range as xxx.xxx.xxx.128-xxx.xxx.xxx.254, the static reservations outside that range aren't served to their devices. I had to specify the whole 2-254 range for DHCP in order to have the static assignments properly delivered. Irritating. Now the dynamically served IP addresses intermingle with the statics, making it hard to easily see which is which.


Think about this for a minute - you want to specify the DHCP range as .128~.254 and then you wonder why it won't issue an address in the .2~127 range??? How about because YOU told it not to.

Routing Issues

A major irritation for me has to do with what I perceive to be routing / routing table issues. I read that others are having troubles with devices, often printers, becoming unreachable. That was one of my initial experiences as well, but with a twist. As I was setting up a new printer and installing drivers on various computers, I found that some computers installed the printer easily, others couldn't even see it. Hmm. Digging in, I found that I could ping the printer from two computers but couldn't ping it from another. All computers could ping each other. All devices showed up in the attached devices list on the R7000 admin page. I could access the admin page from all three computers. Odd. So I switched the printer to a hardwired ethernet. Initially I could see the printer from all three computers. After a bit, I could only see/ping it from one computer. What? It was acting like the routing table was getting corrupted. Just to clarify, I'm always pinging by IP address, not DNS name, all on the same subnet, no duplicate IP addresses, all devices visible in the attached devices page. If I can't ping a device on the network, the network really isn't of much value...


WHAT routing issues? You have a "flat - single broadcast domain/single subnet - network" - the only routing you're doing is presumably to/from the internet, and that is not what you're having problems with..

Let me put it this way - IF - the network portion of the address doesn't change (the 192.168.0) the data doesn't get routed.

NOW - if computer B & C can see the printer, and computer A can't - why do you think the problem is "router related" - obviously - there is connectivity to the printer and to computers B & C - given that computers A, B & C, can also see one another, there is also connectivity to computer A - this would suggest to me that you need to focus on computer A - possibly it's firewall settings.

Let me make it clear - I'm not attacking you, and heaven knows I'm not going to try to defend Netgear's tech support (I have my own issues with them), but, as a practicing tech support professional, I have to wonder, we (in the profession) see end users all the time who think they know more than they do, or, who expect one manufacturer's equipment to work in the same fashion as another's (because it's what they are accustomed to), when in fact the unit that the perceive as working properly does not.

I can't offer you support on the R7000, I've never tried it (and probably never will), but two of the "bugs" you're calling out aren't "bugs", or at least, not the way you describe them - I'm not saying there are no "bugs" (heaven forbid), I currently have no less than four open support cases on two different pieces of equipment, because of bugs (generally speaking, if I open a support case, you can bet there will be a "bug"), I've already implemented "work-around"s for all four issues, but really I shouldn't have to.

And just so it's clear - the reason I would never buy an R7000 is because I don't like wireless routers - I prefer to run a wired router with a separate wireless access point - this allows me to locate the access point for optimum coverage, without having multiple UTP cables running to that location.

Give a man a fish, feed him for a day
Teach a man to fish, feed him for life.
Message 5 of 21
Highlighted
Virtuoso

Re: New R7000 Owner, Stunned by Bugs, Bad Support

haven't found a nice way to do this yet on the R7000. If I create static reservations in the xxx.xxx.xxx.2-xxx.xxx.xxx.127 range and then specify the DHCP range as xxx.xxx.xxx.128-xxx.xxx.xxx.254, the static reservations outside that range aren't served to their devices. I had to specify the whole 2-254 range for DHCP in order to have the static assignments properly delivered. Irritating. Now the dynamically served IP addresses intermingle with the statics, making it hard to easily see which is which.


This is normal if you are using Address reservation under LAN setup. You have to choose all the IP using under Address reservation within the DHCP.

Now the dynamically served IP addresses intermingle with the statics, making it hard to easily see which is which.


Choices are for you design specially range AA ~BB (DHCP range for address reservation while rest can for DHCP.


ex.
DHCP range 192.168.0.2~ 192.168.0.50
192.168.2.~ 192.168.0.25 for DHCP client
192.168.0.26-~ 192.168.0.50 for Address reservation


I've found that the DHCP server sometimes provides incorrect DNS entries to the clients. I hard specify two DNS IP addresses, so it doesn't seem like this should be tough to do right.


What DNS entries?

I've found that the DHCP server doesn't always retain the name/description of devices as given in the static reservation. Devices often show up with empty (---) values in the Attached Devices display.


LAN address reservation name has no relation to attach devices as router will read t he actual device name like ARP command does. In some cases it does (-) . You will find that not only in R700 but other model in the forum
VPN Case Study

VPNCASESTUDY.COM

"Our Second To None VPN Related Setup Case Study[/COLOR][/URL]

"One Stop Solution To Your Netgear VPN Connectivity"

*Visit the site for Non-VPN related Doc & Links* [Windows & Mac user/support]





June Mizoguchi-
Message 6 of 21
Highlighted
Aspirant

Re: New R7000 Owner, Stunned by Bugs, Bad Support

I have nearly every device on my network with static IP's as assigned by DHCP. All of the assigned IP's are outside the range (i.e. 10.0.1.1-10.0.1.80, but assignable IP's is still set to 10.0.1.100-10.0.1.200). I haven't had any problems with devices getting properly assigned IP's. You may need to reset your router to get it to work properly. The assignable IP's should be set higher than your reserved IP's to prevent conflicts. I agree with the table being annoying. There should be an option to sort by IP address.
Netgear R7000

DD-WRT Kong 24345

overclocked to 1.2 GHz
Message 7 of 21
Highlighted
Retired_Member
Not applicable

Re: New R7000 Owner, Stunned by Bugs, Bad Support

The issue that he's describing with the wireless printer *IS* a bug but it's not a routing issue, it's a switching issue.

It's well-documented with Netgear support and there are multiple reports of the problem here as well.

A byproduct of this behavior is that the R7000 loses track of which clients are wired and which are wireless. At the time the problem manifests (usually 2 days after a reboot), all wireless devices appear in "Attached Devices" as wired devices and wired devices can no longer communicate with them.
Message 8 of 21
Highlighted
Tutor

Re: New R7000 Owner, Stunned by Bugs, Bad Support

Thank you all for the replies.
So nice to bump into sharp folks on a similar journey.

@RogersSC, @csm746
Thanks for the encouragement on DD-WRT. I'll give it a shot. Sounds like it's been a viable option for you both.

@fordem, @jmizoguchi, @ericnix
Re: DHCP setup, I'm attempting to duplicate how I've setup DHCP in the past on other routers that has worked for me. It's possible that there is a better solution for doing this with Netgear's Genie interface, but I've not figured it out. On my ASUS with Tomato, it will serve whatever IP address I give in the static reservation and use the range I specify for dynamic addresses.

A small example to clarify my experience:

static reservations
192.168.0.5 airport express
192.168.0.10 HP Switch

with the DHCP range set as 192.168.0.2 - 192.168.0.254 I get something like:
192.168.0.2 macbook pro
192.168.0.3 ipad 1
192.168.0.4 samsung galaxy note 3
192.168.0.5 airport express
192.168.0.6 mac mini
192.168.0.7 iphone
192.168.0.10 HP Switch

with the DHCP range set as 192.0.100 - 192.168.0.254 I get something like:
192.168.0.100 macbook pro
192.168.0.101 ipad 1
192.168.0.102 samsung galaxy note 3
192.168.0.103 airport express
192.168.0.104 mac mini
192.168.0.105 iphone
192.168.0.106 HP Switch

Note that this isn't the exact behavior I saw, but I don't have time to set it up exactly as it was and reproduce it. Basically, my static reservations were ignored/not preserved, presumably because they were outside of the specified DHCP range. Essentially, I am wrong in assuming that the DHCP range applies only to the dynamically served DHPC clients. What I'm trying to do does not appear to be a feature of the current firmware.

For completeness, what I hoped to see was:
192.168.0.5 airport express
192.168.0.10 HP Switch
192.168.0.100 macbook pro
192.168.0.101 ipad 1
192.168.0.102 samsung galaxy note 3
192.168.0.103 mac mini
192.168.0.104 iphone

@fordem
Sorry for my routing terminology faux pas. Perhaps "I'm having a switching issue" would be more accurate.
It's not the firewall of computer A. It's the R7000. I know this for several reasons:
1) It's not always computer A that can't reach destination D. Sometimes it's A, sometimes it's B, sometimes it's A and C.
2) Destination D is not always the same device. Sometimes it's printer A, sometimes it's printer B, sometimes it's NAS N, sometimes it's my windows home server.
3) It's not related to the OS of the pinging computer. I've had the problem on Windows 7 x64 Ultimate, Windows 8.1, Mac OS X Mavericks, Mac OS X Mountain Lion
4) It would seem if it were a firewall issue on computer A:
1) it wouldn't likely start out OK and then stop working
2) it would prevent connectivity to more than just a single device
5) When I replace the R7000 with my ASUS running tomato, everything works perfectly with no changes on any of the computers

I realize that tech support sees it all. I've been on the tech support side of the fence plenty. I understand the drill and I'm sympathetic to the challenges they go through. I appreciate that they need to be systematic and validate the clues they are given to accurately assess the problem. In my recent experiences with Netgear's first level support, I was unable to quickly convey the situation and get to the point that we were on the same page / same level, working on the same problem. The troubleshooting steps suggested on their end clearly indicated that we never got to that level of understanding where progress would be possible. My total time on the phone in the last week or so with Netgear support is approximately 3 hours of wait time, and 4.5 hours of support time. The "solution attempts" boiled down to: power cycle, reflash, reset and watch. Of course I had already done these on my own to no avail. For completeness, I did them again, several times, to ensure support and I were on the same page.

I like your wired router with access point topology and would consider that, but I do need a firewall as the gatekeeper / first device into my environment. My current wireless router location is not optimal, but serves the primary spaces well. I have a 2nd wireless access point on a drop to fill in a guest room and homeschool area. The R7000 range may make the 2nd access point unnecessary.

@jmizoguchi
I like your solution of having the dynamic range below the statics. It would keep the ranges separate unless you end up with a large number of dynamics and they start to overlap with the statics.

My situation has some history that makes it much more convenient to have static IP addresses where they have been for a long time (some lower, some upper) and a range for dynamics in the .100-.199 area.
I have a couple of devices with static IP addresses that are not easy to change: old Windows CE devices, hardware projects
I have a handful of printers that have been at IP addresses for a long time. Their associated printer drivers / ports expect them at those IP addresses. Sure I can change the ports, but I have over 25 clients between physical machines and VMs spread across many operating systems.

The DNS entries I'm referring to are the DNS server IP addresses that you can specify. I usually set one of my DNS servers to a member of my broadband provider's DNS server pool and set another to one of Google's DNS server pool.

I have had odd results with the R7000 providing clients with the DNS server IP addresses via DHCP. Sometimes they get what I specify. Sometimes they get the IP addresses the R7000 receives as a DHCP client of the WAN (the IP addresses provided by the ARRIS cable modem), sometimes it serves it's own address as the DNS server IP. I never dived into troubleshooting this issue as I had bigger problems to solve.

Regarding the LAN address name issue, I've not done extensive troubleshooting to characterize the problem accurately. In my case, I have a handful of devices (Panasonic TV, Sony Blu-ray player, Apple TV, Printer, ObiHai VOIP SIP) that all have given names in their respective network setups. Sometimes that name shows up in the attached device list on the R7000, sometimes it doesn't. It's annoying when the entry is blank as I have too many devices to memorize MAC addresses anymore. Sometimes if I duplicate the name in the static IP reservation, it solves the problem. Sometimes it doesn't. And sometimes I get what seems to be a random name assigned. My Apple TV for instance shows up in the attached devices as Apple-TV-2, despite being named AppleTV in both the AppleTV network settings and the static reservation I've made for it on the R7000. No MAC address conflicts, no duplicate IPs. I've got no idea why the name has a dash between 'Apple' and 'TV' and I'm not sure why the '-2' is being appended.

@ericnix
It sounds like you got the R7000 DHCP server working exactly as I intended. My results were as I mentioned above, even after resets. I think my only difference is that I had some reserved IP's below the dynamic range and some above. Historical reasons.
192.168.0.2 - 192.168.0.99 static IP assignment range
192.168.0.100 - 192.168.0.199 dynamic assignment range
192.168.0.200 - 192.168.0.254 handful of static IP assignments

@htismaqe
Thanks for your input. It sounds like I'm bumping into the bug you describe, perhaps with a twist. My wireless printers are a common culprit for disappearing / becoming unreachable from one or more computers. I find it odd that I can see all of the devices in the 'Attached Devices" and can reach them from some but not all computers.

I've had the same behavior happen with 3 wired devices, a Synology NAS, a windows home server and one of the printers that I switched to wired mode.

Bumping into this issue has been the most disconcerting challenge. It's core to the functionality of a device that's a critical part of my infrastructure.

When the printers become unreachable, it's annoying because I'm now getting complaints from my wife and kids, who of course want instant results Smiley Happy

When the Synology becomes unreachable I get annoyed as it breaks my backups, network shares, music and video server, etc. Not OK.

I don't think it's heat related in my case, but I suppose it's possible. The R7000 is in a spot that's 70 degrees F or less and well ventilated. Haven't looked into device temp issues. My R7000 is quiet and doesn't feel overly warm.
Message 9 of 21
Highlighted
Virtuoso

Re: New R7000 Owner, Stunned by Bugs, Bad Support

With dd-wrt, I can give devices static addresses and names, and put their addresses below the DHCP pool. My DHCP pool is 192.168,1.[100-250]. Static addresses are 192.168.1.99 and downwards. The names that I give those devices appear in the router lists and tables, so I can actually read the tables without having to know all the MAC addresses.

Everything that I use in dd-wrt works well, and no workarounds are necessary. Lots of monitoring capability if you want or need that, too.

I think that you'll like it.
Message 10 of 21
Highlighted
Retired_Member
Not applicable

Re: New R7000 Owner, Stunned by Bugs, Bad Support

1) Regarding DHCP pools and reservations, my experience with the Netgear and Asus firmwares was the same - DHCP reservations do NOT need to be inside the DHCP scope defined.

For example I could assigned a LAN IP address of 192.168.1.1/24 to the router and then configure DHCP reservations for 192.168.1.5 and 192.168.1.6. Then I could assign a DHCP pool of 192.168.1.20-40 and everything would work fine.

The only GUI I've used recently that was not this way is Linksys Smart Wifi. With that GUI, the DHCP reservations MUST be inside the defined DHCP pool. So in the above example, I would have to define my pool at 192.168.1.5 through .40 in order for the two reservations to work correctly.

I believe you're seeing this behavior because your scope and DHCP reservations overlap. I'm not sure though as I've never configured it that way.

2) Regarding the device naming in the R7000 - it's broken, plain and simple. Devices are ultimately self-identified. Regardless of what names you enter in places like DHCP Reservations and MAC filtering, those names aren't universal.

3) Regarding the LAN/WLAN connectivity issues - it got really messy for me because I have wireless devices connected to external APs (Netgear WGR614s) and the R7000 considers all of those wireless clients as wired devices (because it learns their MAC addresses via the wired ports). When the problem occurred it took half or more of my network down.
Message 11 of 21
Highlighted
Virtuoso

Re: New R7000 Owner, Stunned by Bugs, Bad Support

static reservations
192.168.0.5 airport express
192.168.0.10 HP Switch


Not sure why you would assign an IP randomly.

I would have design the IP scheme in certain range and not mixed with DHCP and Address Reservation. Bad implantation to me.

My situation has some history that makes it much more convenient to have static IP addresses where they have been for a long time (some lower, some upper) and a range for dynamics in the .100-.199 area.
I have a couple of devices with static IP addresses that are not easy to change: old Windows CE devices, hardware projects
I have a handful of printers that have been at IP addresses for a long time. Their associated printer drivers / ports expect them at those IP addresses. Sure I can change the ports, but I have over 25 clients between physical machines and VMs spread across many operating systems.


It can happen on some legacy items but I'm sure you could split the range of DHCP range and address reservation .

Apple-TV-2, despite being named AppleTV in both the AppleTV network settings and the static reservation



Naming under Address reservation does not take over attach devices name list . Name you place in Address reservation is profile name to identify those added rules you create
VPN Case Study

VPNCASESTUDY.COM

"Our Second To None VPN Related Setup Case Study[/COLOR][/URL]

"One Stop Solution To Your Netgear VPN Connectivity"

*Visit the site for Non-VPN related Doc & Links* [Windows & Mac user/support]





June Mizoguchi-
Message 12 of 21
Highlighted

Re: New R7000 Owner, Stunned by Bugs, Bad Support

Hey Guys,
I've got some feedback for sminar as well.


Fortunately, I am not having the switching issue that htismaqe has experienced, but I'm sure does exists. My wired/wireless items remain where they should under Attached Devices after a reboot and after several days of operation.


sminar,
I have over 20 devices configured to connected to my router. both wired and wirelessly. My DHCP Pool is set for 25 addresses 192.168.1.100/24.


2 of the devices utilize Address Reservation (wired IP Phone, wireless printer). My NAS has a static IP set on the device, not reserved and it is outside of my DHCP pool. If you are only able to get static or reserved addresses to work by setting your DHCP pool to overlap the range of static addresses, something is wrong. Either I have misread your post (very possible) or you've misconfigured something.


LAN
http://i.imgur.com/siMrsW9.jpg


Attached Devices
http://i.imgur.com/s29q9I8.jpg


Access Control
http://i.imgur.com/emkCXDx.jpg
~Comcast 1 Gbps/50 Mbps SB8200 > R8000P
~R8000P FW:1.4.1.64 ~R7000 FW:1.0.9.42
~R6400 FW:1.0.1.52 ~Orbi-AC3000 FW:2.5.1.8
~EX3700 FW:1.0.0.84

Message 13 of 21
Highlighted
Virtuoso

Re: New R7000 Owner, Stunned by Bugs, Bad Support

With dd-wrt, I can give devices static addresses and names, and put their addresses below the DHCP pool. My DHCP pool is 192.168,1.[100-250]. Static addresses are 192.168.1.99 and downwards. The names that I give those devices appear in the router lists and tables, so I can actually read the tables without having to know all the MAC addresses.


Actually Prosafe/Prosecure router can do that in same manner but not with home end router from netgear.

I use combination of assign the IP both in DHCP and outside DHCP and works fine so Prosafe/Prosecure business model can easily do that. Smiley Happy
VPN Case Study

VPNCASESTUDY.COM

"Our Second To None VPN Related Setup Case Study[/COLOR][/URL]

"One Stop Solution To Your Netgear VPN Connectivity"

*Visit the site for Non-VPN related Doc & Links* [Windows & Mac user/support]





June Mizoguchi-
Message 14 of 21
Highlighted
Virtuoso

Re: New R7000 Owner, Stunned by Bugs, Bad Support

htismaqe wrote:
1) Regarding DHCP pools and reservations, my experience with the Netgear and Asus firmwares was the same - DHCP reservations do NOT need to be inside the DHCP scope defined.

For example I could assigned a LAN IP address of 192.168.1.1/24 to the router and then configure DHCP reservations for 192.168.1.5 and 192.168.1.6. Then I could assign a DHCP pool of 192.168.1.20-40 and everything would work fine.

The only GUI I've used recently that was not this way is Linksys Smart Wifi. With that GUI, the DHCP reservations MUST be inside the defined DHCP pool. So in the above example, I would have to define my pool at 192.168.1.5 through .40 in order for the two reservations to work correctly.


Yes, this is exactly my experience with Netgear R7000 and Linksys WRT1900AC firmware DHCP,. I don't care to go and play with the Netgear R7000 stock firmware and figure out where the OP's problems lie at this particular moment. If I ever get back to Netgear stock firmware, I'll check this out, though *smile*. Probably when Netgear fixes the rest of their IPv6 bugs, unless tomato gets there first *smile*.
Message 15 of 21
Highlighted
Tutor

Re: New R7000 Owner, Stunned by Bugs, Bad Support

Thanks everyone for the additional input.

Your feedback and time invested in this thread encouraged me and guilted me into some additional testing of the DHCP setup.

I reinserted the R7000 into my network
set the DHCP range to 192.168.0.100-192.168.0.199
applied
rebooted the router
power cycled several of the devices that had fixed IP addresses outside the new DHCP range (all below the range in this test)

Results were odd.
Most got their reserved IP address (excellent! what I wanted/expected in the first place)
Two did not. They received IP addresses in the .100-.199 range. Surprisingly, the IP's they got were not logically in sequence. Go figure.

On a whim, I pulled the R7000 power, turned the questionable devices off, plugged the R7000 back in, waited until I could access the admin page then powered up the devices and...
Everything appears to be served IP addresses as expected/desired:
Reserved IPs are served regardless of their membership in the DHCP range
Dynamics are served sequentially in the DHCP range

In my case, it appears that a reboot was not enough. A power cycle was required. Doesn't seem right to me, but that's my current experience.

Other tidbits:

I've not done any additional investigation on issues with DNS server IP values being correctly passed to DHCP clients.

My Apple TV device name is now showing up as Apple-TV rather than Apple-TV-2. Not sure why it's fixed. Don't really care at this point. Still have naming issues with other devices.

In the admin, basic, home screen, the Attached Devices area claims Number of Devices is 8. When I click on the Attached Devices pages to see them, the list contains 15 devices. 7 are wired, 7 are 2.4 wireless, 1 is 5GHz wireless. Perhaps the Number of Devices only sums the wireless devices.

On Deck: DD-WRT. Will try to get to the install and setup later today.
Message 16 of 21
Highlighted
Virtuoso

Re: New R7000 Owner, Stunned by Bugs, Bad Support

Be careful with DHCP after a computer has already been previously allocated an address, I believe the option is there in the DHCP request to ask for the last assigned address which may be granted in preference to the reserved address, and so to really start from scratch you might need to reset this at the PC.

This might help (or confuse?), see DHCP discovery;

http://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol
Message 17 of 21
Highlighted
Tutor

Re: New R7000 Owner, Stunned by Bugs, Bad Support

Hi Mars Mug,

Good point. I had thought of that possibility but figured it was unlikely for my current experience. For devices that exhibited the interesting IP situation, the new (I assume it was served by the R7000's DHCP) IP address was not the reserved address, was in the dynamic range but not in sequence and was not the IP address the device had before the setup change/reset efforts. I'm pretty certain the newly served IP addresses had never been given to the device in the past and likely never served by the R7000 until that moment (higher in the dynamic range than my total number of devices). With the ASUS router in place, I've never encountered a cached IP address type of situation that I know of for any of my devices. In other words, if I change the ASUS running Tomato DHCP setup and reboot or power cycle devices, I've always been served / devices end up with new IP addresses consistent with the Tomato setup.

Oh, and just to clarify, there is no other DHCP server that could be confusing things Smiley Happy

Still haven't carved out the time for DD-WRT. Hope I can squeeze it in soon.
Message 18 of 21
Highlighted
Aspirant

Re: New R7000 Owner, Stunned by Bugs, Bad Support

I've been seriously considering replacing my 4 year old Netgear DGN2000 wireless router with the R7000. Part of the reason for stalling is the price, but having just read through the R7000 forum it appears the firmware for this product just isn't ready for the market, so my decision has been made and I will avoid it.

I originally had issues with address reservation on the DGN2000, which were known to Netgear support although they initially denied any such problems. Eventually a firmware upgrade fixed them for good, but it has made me very sceptical of Netgear support - they could have been much better and caused me a lot of wasted time and effort and I certainly don't plan on going through that again with a new router!

It's a shame as I'm a big fan of Netgear, but they appear to be rushing products to the market before they are ready and using customers to perform their QA. This is unacceptable.

I really feel for you guys having problems with this router. It's a lot of money to pay for something that isn't rock solid. The only way Netgear will learn to stop releasing products that aren't fully tested is to vote with your feet, and I for one, am walking away Smiley Happy
Message 19 of 21
Highlighted
Virtuoso

Re: New R7000 Owner, Stunned by Bugs, Bad Support

Milleniumaire wrote:

It's a shame as I'm a big fan of Netgear, but they appear to be rushing products to the market before they are ready and using customers to perform their QA. This is unacceptable.

I really feel for you guys having problems with this router. It's a lot of money to pay for something that isn't rock solid. The only way Netgear will learn to stop releasing products that aren't fully tested is to vote with your feet, and I for one, am walking away Smiley Happy


With these feelings, I would stay away from the entire generation of wireless-AC routers. There isn't one out there that's rock solid. They all have problems, and are expensive. Although, I do find the R7000 with dd-wrt firmware is rock solid for me, not everyone is willing to go there, it seems.

I'm also looking forward to better times with stock firmware. Netgear seems to be working on fixing problems, and has made a lot of progress with IPv6 from Comcast. It's pretty much totally there in their latest debug firmware. It looks like they're trying hard to clean up open issues now.
Message 20 of 21
Highlighted
Retired_Member
Not applicable

Re: New R7000 Owner, Stunned by Bugs, Bad Support

Just to re-iterate what Roger said, there's only a handful of AC1900 routers available and they all have issues.
Message 21 of 21
Top Contributors
Discussion stats
  • 20 replies
  • 12455 views
  • 2 kudos
  • 10 in conversation
Announcements