Oh, yes, so I’m saying if you want it to persist through a reboot you will need to put your commands in /cfg/rc.local (a new file). You could edit /etc/config/https-dns-proxy, save it to /cfg/https-dns-proxy, and then copy that file to /etc/config/https-dns-proxy, and then restart https-dns-proxy as part of this new file, /cfg/rc.local:
cp /cfg/https-dns-proxy /etc/config
/etc/init.d/https-dns-proxy restart
-Jeff
I think I am going to hold off on any more mucking about with these. Once the on-prem controller is mature and things are more settled, I will re-engage, but things are just too questionable at the moment. I have seen a lot of people here who are very happy with both the APs and the Switches, so I won’t go on some long diatribe about how I think things should be done, I am obviously a single voice in the choir. I will lurk around and follow how things progress.
@scatterday I’m curious what you find so questionable. Our top priority is security and reliability, but we also give power-users the ability to customize their installations to their liking.
-Jeff
@Alta-Jeff - Maybe that wasn’t the best word to use, but my meaning was that the platform is very new and needs to work out how they are going to do a few things before I feel like I can use it. Like I said, I am a single voice and there are a lot of people who are happy with how things are, or are willing to work through things. I just don’t have the time to do it currently, so it takes it off the table for me.
I feel like you guys are definitely working through issues with people and I am astounded by your level of engagement in the forums, it is something that other companies could learn a lot from. I also know that the things that I like to see available in a wireless controller/AP/Switch aren’t going to magically appear just because I wish they were there. You guys have to weigh feature requests and choose the ones that make sense as well as meet what your customers are asking for - to a degree. Risk involved with enabling certain features will outweigh the loudest voices if the risk is too high.
I have to say, I very much like the platform, but right now it just isn’t suited to my requirements. The physical design is spot on and given a bit of time, I think the functionality will match.
@scatterday we do appreciate the feedback… and if you happen to give it a shot and notice any issues, we’ve been very responsive at finding the cause and providing an update for them.
We’re constantly improving our feature-set, and rapidly addressing any kind of issues/concerns our end-users notice. 
Cheers,
Matt
It still seems to ping every 30 seconds even with fallback and mesh turned off - perhaps it could be reduced in that scenario?
@CarlH If you are concerned about this, you can disable netd by adding this to /cfg/post-cfg.sh on the AP(s):
killall netd
Hello Alta,
Am running a local controller and each of my 6 Alta AP’s does 1 DNS Query per Second!
This is way to much.
How can this be fixed/reduced/controlled?
That sounds way to much. The stated and experienced frequency earlier in this thread is once every 30 s (at least for the ping towards Alta). Checking myself and getting those pings/requests for ping.alta.inc once every 30 seconds per network device.
Edit: The requests actually come in pairs every 30 seconds.
Sorry but nope.
Measured (tcpdump) to be axactly 1 request per second per AP.
And yes, that is too much.
Agree.
Yes, too frequent, about 30x too frequent.
I checked mine and my devices are doing the normal 1 request/device/30s.
Do you have any packet loss to ping.alta.inc from a computer on the network?
