Never rebuild a configuration from scratch again!

@ 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”.