This release brings more intelligent traffic control and streamlined deployment with policy-based routing, flexible firewall grouping, and a new site-to-site VPN wizard for faster setup—paired with QoS prioritization, 6 GHz support, and enhanced management options for proxied Control environments.
Route10: Add support for policy-based routing (PBR).
Route10: Add support for host- and domain-name based firewall groups, including use with PBR.
Route10: Add Auto-connect VPN configuration, for easy site-to-site setup.
Switches: Add support for QoS prioritization configuration.
Colors: Add ability to assign colors custom names (on Switch Port config).
SSIDs: Add support for 6 GHz band.
Add option to disable Site Map, and add GMaps API Key option.
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!
Date and time are incorrect even after forcing a manual sync.
root@Control:~# timedatectl status
Local time: Thu 2026-04-02 00:27:14 UTC
Universal time: Thu 2026-04-02 00:27:14 UTC
RTC time: n/a
Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no
root@Control:~#
We’re not seeing any time issues here. How far off is the time for you?
The system will use ntp.ubuntu.com by default. I’ve seen some NTP servers that were incorrect, intermittently. I’d force another sync and get a packet capture to see if the NTP server is somehow inaccurate.
Jeff, this brings about a question for local control users. Why are we not able to set custom NTP servers or our respective time zones within the UI? With Ubuntu defaulting to UTC, this is exactly why the date was showing my appliance ahead of CDT (five hours to be exact) The date/time was showing 4:50 AM Friday 4/3 UTC while my time in CDT was 11:50 PM Thursday 4/2.
sudo timedatectl set-timezone America/Chicago (corrected the time-zone and is now showing a properly aligned local date/time)
##Before:
root@Control:~# timedatectl status Local time: Thu 2026-04-02 00:27:14 UTC
Universal time: Thu 2026-04-02 00:27:14 UTC
RTC time: n/a Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no
##After:
root@Control:~# timedatectl Local time: Thu 2026-04-02 23:46:32 CDT
Universal time: Fri 2026-04-03 04:46:32 UTC
RTC time: n/a Time zone: America/Chicago (CDT, -0500)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no
You can set the timezone with respect to the connected Alta devices and the user interface within the Settings page, as you know. There has not been any need to sync the timezone from the user interface to the controller OS itself, as all time operations are generally handled natively in the front-end or on the Alta network devices themselves (for WiFi scheduling, etc.).
Setting the NTP server on the controller is outside the scope of a network controller user interface, but we do allow full access to the Ubuntu system via SSH where you can edit the NTP server in the /etc/system/timesyncd.conf file (or using the command you gave, as well).
The out of scope excuse is growing old with the Controller Jeff.
What exactly does that time zone function on the UI do when when everything was in UTC. It wasn’t until I manually changed the NTP and zone within the controller that it actually reflected. The logs are now actually accurate with respect to date and time.
Is it just for show? This has been a part of my frustration with this appliance. It’s as if Alta decided to release a half baked product to only cut the features short because cloud was the priority all along. Rip the band-aid off already and just tell the community that the Controller is not the path moving forward so that we can forklift and move to something else. I’m sorry to be blunt, but why is the user expected to make these changes, this should all be accounted for as a part of your releases. Clearly choosing the Chicago/America time zone on your UI does nothing.
Not sure why the animosity when we have been very direct and clear, and quick, on our answers to your questions.
We provide full access to the operating system (many vendors do not), and you have full freedom to change any underlying options that you deem necessary. Setting the time zone as you have done will have no impact on how the controller operates, and would just be a convenience for yourself. Syncing the host OS time zone to that set in the user interface is not necessary for normal functionality.
Timestamps throughout the controller are stored in Unix Epoch UTC in all cases, and only adjusted for local time zones when necessary. That is why it is not critical that the host Controller OS be in sync with the user interface’s time zone.
Setting the time zone in the UI does do something. It ensures that the time zone is set on all of the Alta devices (minus the Control device, of course), specifically for WiFi scheduling, so that APs know when to turn on/off WiFi. The schedule is also displayed in the site’s time zone, instead of the browser/controller’s time zone. When we implement scheduling on switches, the time zone will be used there as well, which infrastructure we have already very intentionally set in place.