We’ve just rolled out the latest Control update, with new capabilities and refinements to keep your network running smoothly.
Add support for real-time log analysis.
AP6W: Enable per-port speed selection, loop detection, allowed MACs, upload/download rates, and 802.1X on ports 2 and 3.
System: Add persistent logging options.
WiFi: Resolve issue where minimum RSSI could not be disabled.
Minor UI improvements.
This update is being rolled out now. You can manually initiate the upgrade if you’d like, or it will automatically update overnight. Here is the full running changelog:
If you have any questions let us know, and as usual if you notice anything please feel free to reply here, or create a new topic, including the details of the issue encountered. Thanks!
For those who are currently configured for “touch /cfg/.persistent.log”, should the config be disabled or removed prior to 1.1g upgrade? Any negative interactions we should be aware of?
Pardon my ignorance here, but the logging feature at a glance appears unfinished.
System: Add persistent logging options.
There doesn’t seem to be a slider function to either enable or disable logging on the system menu. Is this automatically enabled by default or is this actually an “option” for users?
If you leave those areas blank the devices will stay at ephemeral logging. If you add values to those areas, the devices will switch to persistent logging that survives reboots, and the logs will grow to the size you specify with the number you enter. For example, if you enter “1” in the Router box, you will be 1MB worth of logs that persist reboots, and they roll over to newest log deletes oldest log once the file reaches 1MB. Does that make sense? It’s early and I haven’t finished my coffee LOL.
On & Off, 1’s and 0’s, Enable & Disable & Apply, its logically simple and universally understood, versus guessing whether the feature is actually on or off, or even functioning based off computed values in entry boxes that show no feedback confirmation what-so-ever.
I will tell you this. When my network went down for the second time recently, I had touch persistent enabled and was unable to gather any logs because I could not access any of the devices, period. No basic console functions, nothing, dead in the water. The only solution was a clean reboot and config.
Another concern are for those who let’s say do not have SSH configured, and are more UI dependent. How are those users supposed to access these logs during events, outages, etc.? Especially in situations where let’s say WAN link/s are affected, but the network is still operationally up, breaking resolution and access to your Alta Control at the local level.
I would generally agree with that. Happy for the feature but it would probably be cleaner to have an enable/disable toggle. Keeping the current implementation in mind, the log size boxes could still be kept but perhaps with some good default values already filled in for when persistent logging is enabled. Then they can be tweaked as needed.
I’ve always wondered if it would be better if the controller (cloud or local) should essentially act as a syslog server to allow logs to be viewed if the equipment is down but the controller is still operational (in theory anyway). Especially now that the controller can basically ingest and display logs.
Getting a little farther afield and what to do when the controller isn’t available, then there’s the thought of being able to use the Bluetooth that’s built into pretty much everything as a console port or out of bound management like mentioned here: Console (serial) port for OOB management - #2 by jack
