NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
I understand that a developing product needs updates. Sometimes these updates require changes to what data is expected for an element of the settings config. As a customer, when a firmware update is incompatible with my settings, it is absolutely unacceptable that I would have to re-build my entire config from scratch after updating firmware. Netgear may not be able to update my settings but you should at least give us a tool to fix it. It is NEVER ok to lose a customer’s hard work, that’s just bad business. Here is how we fix it:
- Give us a tool to download the config in a human-readable format. I don’t care if it is TXT, CSV, XLS, or whatever… Just give us something we can work with.
- With every firmware update, the “release notes” should include details of ANY changes to the settings requirements so we know what to adjust in our human-readable files. (ex: “The [setting] field for [control] on [screen] is now restricted to numeric characters.”) This points us directly to a potential problem. Netgear just needs to track such things and release the info with every update.
- Maintain a “white paper” with a list for the requirements/limitations for every settings value. This goes with number 2 above to allow us to fix problems.
- Along with item 1 above, we need to be able to upload this human-readable settings file back to the device.
- Auto settings debugger: When an attempt is made to upload a human-readable settings file, a check should automatically be performed to see if the file being uploaded conforms to the latest established rules. Any errors should be identified with the specific item and what the fault is. In the event of an error, the user should be prompted to override or abort with “abort” as the default. In the event of success, the config is uploaded with a success confirmation.
This isn’t rocket science here. I get that you need to do things that could break my old config. All we are asking is that you give us the tools to fix it. To reiterate my earlier point, “Start over” is NEVER an ok thing to tell a customer.
This one feature set would also solve several other problems:
- uploading a port forwarding list
- maintaining a block list
- revising routing tables
All of these items would be downloaded/uploaded in one shot with the above suggestions.
As an organizational note: If the human-readable download were actually a ZIP file it could contain multible human-readable files where any setting containing lists could actually be seperate files within the ZIP. Maybe all the settings could be broken out into files containing relevant sections instead of a single long list. If you need to take it in small bites, fine. Dump everything into a single human readable file for now, add the error checker later, break the file into smaller relevant pices when you get the time. I don't much care how you break down the task, just give us a took to fix the things you break and provide it sooner rather than later. We need items 1 & 4 yesterday, the rest will be nice when you can get to it.
Thank you for your consideration.
45 Comments
This is not sapce rocketery those are routers, so when I say simple this is simple in a way that this is only datas to transfer!
A method to export block list would be awesome, along with access to more advanced settings.
The webgui for the R7500 is terrible, cluttered, multiple pages for basic settings even. I miss the original netgear gui from the old days. Fast, efficient and uncluttered.
The R7500 V2 is my first netgear router in over ten years, always read glowing reviews of the nighthawk series, but never wanted to shell out that much for a wifi router.
This idea seems like a no brainer for a supposedly higher end consumer router. I do not think netgear really cares anymore. They have commoditized their brand and their sales are completely dependant upon name recognisition not quality or performance.
Netgear was once a very good router, among the top two or three for sure.
They now know that most consumers know little or nothing about networking or computing in general and this works to their benefit. The few percent of people (like users of this forum) are really not their "target market"
@ michaelkenward
Regarding your 2017-10-22 comment:
"Sadly, we may be in chipset country, where all the people who make network kit use the same chipsets. So the whole industry is stuffed."
I was just re-reading this topic and I recall my concern at this possible roadblock. However, I spent a lot of time writing my own firmware and flashing microcontrollers this past year and have a much clearer understanding of this possibility and the options. Simply put, we are not “stuffed”, as you put it.
Every device already has a built in compiler/de-compiler. Currently, the firmware decompiles the binary code for all of the settings, outputs human readable HTML for the UI, accepts human readable ASCI from the UI and re-compiles the data for storage and processing.
There is no longer any question of ability or even difficulty. All of the base components are already in place. Human readable output/input is in fact a very simple solution to add and already exists via the UI. There can be little doubt, up to this point, NOT providing this tool is a business decision. I suspect, and believe it quite likely, there is concern about the risk of releasing proprietary information by giving us too detailed of an understanding about the settings data. I say “Get over it already!”
Perhaps, the bigger issue here may be change tracking. NetGear has demonstrated, on numerous occasions, as documented throughout the forums, a severe lack of procedure when it comes to documenting and coordinating changes. As we have seen many times, a bug gets fixed in an update and then is broken again in the next update. This suggests that they have different teams working on different solutions using different versions of the code.
Team ‘A’ fixes a bug compiles the code and releases an update.
- No coordination occurs and none (not all anyway) of the other teams receive and/or implement the updated base code.
- Team ‘B’ gets their bug fixed but recompiles the fix without the update from team ‘A’.
- The update from team ‘B’ is released and effectively wipes out the bug fix released by team ‘A’.
*NOTE: For those who don’t write code, the firmware is comprised of many separate files, each containing code. A “compiler” program combines all of the files and translates what the programmers wrote into binary (machine language).
To add insult to injury:
- Team ‘A’ is notified that team ‘B’ fixed their bug.
- Team ‘A’ loads the fix from team ‘B’ but must be careful not to lose their current work on the next bug.
- Rather than take the entire new base code and go to all of the trouble of making their own corrections again in the new code, they take only the files that team ‘B’ changed and add these files to their own version of the base code.
- You find the bug and report it. The fix released by team ‘A’ is broken again.
- What passes for support forwards the issue to team ‘A’ since they worked on that.
- Team ‘A’ can’t duplicate your problem, you must be an idiot.
- Team ‘A’ is working with their own code that didn’t get wiped out by team ‘B’ because they only took a portion of the update team ‘B’ released to us and not the part that wiped out their own previous work.
- It takes 6 months of complaining before someone looks into it further, assuming we don’t all give up before then, and figures out that the change was indeed released but subsequently overwritten.
I don’t personally know anyone at NetGear but I can see what is happening in that company as clearly as if I was looking at a map of their corporate blunders. If you were a board member at NetGear would you want the whole world to have a tool that would expose just how incompetently things are run at your company?
On second thought, short of a major corporate shake-up, you might be right after all. Perhaps we are “stuffed”.
This would be huge. With commercial Cisco devices running IOS configured from the command line, you can just type (I think--I'm a bit rusty) "show config" and it will list the entire configuration, which you can then copy/paste into a plain text file for backup. If you want to restore it, you just copy the contents of the text file, and paste it into the command line (from the appropriate mode), hit enter, then commit the changes, and it's restored. It's super easy. You can modify the config offline, use scripts, etc. I don't know how it handles configurations for deprecated features, but there should be a way to gracefully handle settings that are no longer valid.
michaelkenward "Completely rethink" and "simple" can absolutely go together in a sentence, and conceptually. Consider if a firm is doing things in a very unnecesarily complicated way. If they completely rethink things, they may be able to simplify it. All the settings in the router (Orbi, in my case) render in plain text in the GUI, and they're all displayed in human readable format at the command line when you telnet in, too. Given that the router already has some means to convert the settings between binary and text for both the GUI and CLI, it's not a huge leap to allow the import and export of the settings in plain text, rather than binary.
- What’s really sad is that you can’t even save the MAC to IP assignments so that you can restore them after a factory reset. That is some major league bad planning.
Netgear must take action to help people when they are upgrading their devices. Phones can do it PCs same thing!! It is time to claim this for routeurs in order not to waste time in endless reconfig!!!!
Agreed. This is much much needed. I delay upgrades because manual re-configuration takes so much tme...and my configuration is pretty simple.
Add my vote!
Current: Netgear R7000
- Give us a tool to download the config in a human-readable format. I don’t care if it is TXT, CSV, XLS, or whatever… Just give us something we can work with.
You have this already. Telnet to the router, login, then enter "config show". Dumps out key-value pairs for all config settings.
Along with item 1 above, we need to be able to upload this human-readable settings file back to the device.This can be done also - the command "config set <key>="<value>" can set any of the values.
I have scripts that automatically dump key settings to text files, then my scripts use sed to convert those files into a series of "config set" commands into a new script file. Effectively allows me to backup my DHCP reservations, device names, device models & types, access control settings, WiFi SSIDs, email settings, UPNP settings, and restore them. I am assuming of course that they "key" names will not change between firmware updates, but I think that's a reasonably safe assumption.
I also agree that your other options should be provided as well, and it would certainly be nice to have the settings exported in a format that doesn't need to be massaged to be used to restore the settings.
Finally, something truly helpful. DougB628, After nearly 2-1/2 years you have given me a work-around. I can't thank you enough!
If it took 2-1/2 years to get a work-around, how long do you think it could take before netgear actually takes this serious? I really wish I could take you out and buy you a dang shot or something! :) I haven't used Telnet for decades. That was back when I used it over a 300 bps dial-up to connect to a BBS because the internet didn't exist yet. Talk about bringing back the old days. LOL Honestly, I didn't even know Telnet was still around or that you could connect to network gear buy such a method. You are a life saver! this is an excellent work-around! I'm seeing all sorts of possibilities... :D
ATTN NETGEAR: Don't you dare even consider thinking about calling this resolved. This is a band-aid on your blunder and you actually need to present an appropriate GUI solution. And, don't forget about that white paper that needs to be maintained and distributed.
Here's a couple of my scripts - this first one dumps the settings I want to save:
config show > config.txt
grep reservation[1-999] config.txt > reservations.txt
grep orbi_dev_name[1-999] config.txt > device_names.txt
grep orbi_dev_name_ntgr[1-999] config.txt > device_models_types.txt
grep access_control[1-999] config.txt > access_control.txt
grep -E "^wl_ssid|^wla_ssid|wlg1_ssid|^wla1_ssid" config.txt > othersettings.txt
grep -E "^netbiosname|^wan_hostname|^Device_name" config.txt > othersettings.txt
grep email_ config.txt >> othersettings.txt
grep ^log_ config.txt >> othersettings.txt
grep time_zone config.txt >> othersettings.txt
grep upnp_enable config.txt >> othersettings.txt
Next, the script that uses the text files generated by the above script to create a new script to restore the config:
#!/bin/sh
sed -E -e 's/(.*)=(.*)/config set \1=\"\2\"/' reservations.txt > set_reservations.txt
sed -E -e 's/(.*)=(.*)/config set \1=\"\2\"/' device_names.txt > set_device_names.txt
sed -E -e 's/(.*)=(.*)/config set \1=\"\2\"/' device_models_types.txt > set_device_models_types.txt
sed -E -e 's/(.*)=(.*)/config set \1=\"\2\"/' access_control.txt > set_access_control.txt
sed -E -e 's/(.*)=(.*)/config set \1=\"\2\"/' othersettings.txt > set_othersettings.txt
cat set_othersettings.txt > set_config.sh
cat set_device_names.txt >> set_config.sh
cat set_device_models_types.txt >> set_config.sh
cat set_access_control.txt >> set_config.sh
cat set_reservations.txt >> set_config.sh
chmod +x set_config.sh
I agree with you that there's a ton that could be done from here.
