First, forgive me if this has already been answered, and point me to the link. I have spent 3-hours or so trying to find this. I can't believe I am the only one that has this question.
Where do I find a definition, and valid values for the fields on the Administration -> Sysctl page. (sysctl.asp)
Joined: 31 Jul 2021 Posts: 2139 Location: All over YOUR webs
Posted: Mon Mar 21, 2022 6:04 Post subject:
Generally speaking if you want to know what each value is for, on a regular Linux distro you can open the /etc/sysctl.conf in any text editor and read the comments for each option.
If something is not on that file, just google the string Im sure you will have plenty hits.
Joined: 31 Jul 2021 Posts: 2139 Location: All over YOUR webs
Posted: Mon Apr 04, 2022 8:33 Post subject:
This is not just DD-WRT, Red Hat RHEL 8 doesn't have it (last I checked) and probably many others.
Also definetly recommend a nvram reset after such sweeping changes to nvram values are done.
Without actually following the development of DD-WRT closely, for the general populous twice yearly nvram reset wouldn't be a farfetched bad piece of advice.
What we really need is a way to reconfigure the nvram quickly via command line based on settings / nvram strored variable that are hardly going to change, like static leases and other ACL's, security settings and MAC Filter lists etc.
Joined: 31 Jul 2021 Posts: 2139 Location: All over YOUR webs
Posted: Mon Apr 04, 2022 9:37 Post subject:
Depends, if your specific usage and config you notice or not possible issues because of all the crud left behind. Most people dont notice anything until they try to do something else.
Just look trough reports on build threads, where ppl report no issues and indeed there are, I found severe bugs not long ago 3 builds back and on build reports threads everyone was happy, just may not be immediately obvious due to their config/usage or because in all honesty I doubt anything beyond works/dont work is actually tested.
Doesnt mean those issues were caused by nvram values alone, but there we are.