ubnt@ubnt:~$ show interfaces
Codes: S - State, L - Link, u - Up, D - Down, A - Admin Down
Interface IP Address S/L Description
--------- ---------- --- -----------
br0 10.2.2.1/24 u/u Local Bridge
br0.73 - u/u
br0.75 - u/u
eth0 192.168.99.1/24 u/u Internet
eth1 - u/u Local Bridge
eth2 - u/D Local Bridge
eth3 - u/u eth3-pc1
eth4 - u/u eth4-printer
eth5 - u/u eth5-pc3
eth6 - u/u eth6-rotuer
eth7 - u/u eth7-extra
lo 127.0.0.1/8 u/u
Double tab in session to show more commands
add Add an object to a service
clear Clear system information
configure Enter configure mode
connect Establish a connection
copy Copy data
debug Enable debugging of specified routing protocol
delete Delete a file
disconnect Take down a connection
generate Generate an object
initial-setup Enter initial configuration dialog
no Disable or reset operational variable
ping Send Internet Control Message Protocol (ICMP) echo request
ping6 Send IPv6 Internet Control Message Protocol (ICMP) echo request
reboot Reboot the system
release Release specified variable
rename Re-name something.
renew Renew specified variable
reset Reset a service
restart Restart a service
set Set system or shell options
show Show system information
When applying changes over ssh you’ll need to “write” or “save” the changes. Usually you’ll edit the /tmp/system.cfg config file and then save the changes with one of the following commands.
cfgmtd -f /tmp/system.cfg -w && reboot
rc.softrestart has some advantages. It does not require the radio to reboot when making changes to things like SNMP or the device name.
It does seem to have issues sometimes with certain changes. The following happened when attempting to replace the whole /tmp/system.cfg with a previous backup config.
XM.v6.1.8# XM.v6.1.8# /usr/etc/rc.d/rc.softrestart save
@@ -1,110 +1,256 @@
... more random stuff ...
Fast system script build Success.
Fast syslog script build Success.
Fast users script build Success.
Fast poepass script build Success.
Fast resolv script build Success.
do_radio_fast_script: rname wifi0
Unsuported change in radio.1.dfs.status for fast update
Fast radio script build failed
Fixup Startup_list …Done.
If you have issues applying changes with the softrestart, you can try it with cfgmtd. Downside is the radio does reboot.
cfgmtd -f /tmp/system.cfg -w && reboot
You could potentially take the reboot off the end of the above command, but have had random issues in the past where the only way to fix it was a physical reboot. Having the radio reboot after applying the config seems to resolve the issue
It appears that with one of the latest 8.5 updates that you can no longer change Wireless Security to none from the web interface. Work around is to disable it in a config then apply the config. You can do this from the command line or upload a config under the System tab.
Go to the System tab, backup configuration
open configuration in a text editor and change “aaa.1.status=enabled” to “aaa.1.status=disabled”
Upload Configuration and Apply to device
sed -i '/aaa.1.status=enabled/aaa.1.status=disabled/g' /tmp/system.cfg
The above should be it, or you can manually edit “/tmp/system.cfg” and change the following line
The following is a method to recover from a command that may inadvertenly make a radio go offline.
The idea is to launch a process in the background that sleeps for 5 minutes and then reboots the radio, so any changes not saved will be reverted. If the changes were successful, you’ll just need to log back in and kill the background process to keep the device from rebooting.
This can be helpful if your changing networking settings using ifconfig, trying to change routes, or something went wrong while trying to apply a system.cfg setting.
sleep 300 && reboot &
Execute whatever command you need to. i.e.
If your command worked you can log back into the device and search for the process id of the sleep command and kill it so the radio doesn’t reboot.
ps | grep sleep
2XC.v8.5.12# ps | grep sleep 412 admin 1636 S sleep 500 414 admin 1640 S grep sleep 2XC.v8.5.12#
Had an issue with the Lets Encrypt cert for a UniFi-Video server. When renewing the cert and reimporting it into the UniFi-Video keystore, the certification was showing out of date.
Issue ended up being something with certbot.
When certbot runs it generates a new cert.pem, chain.pem, fullchain.pem and privkey.pem and puts them in the “/etc/letsencrypt/live/unifi.domain.com/” directory.
The privkey.pem and cert.pem are used to create the keys.p12 file which gets imported into the UniFi-Video keystore.
Apparently the .pem files in “/etc/letsencrypt/live/unifi.domain.com/” are symbolic links to files in “/etc/letsencrypt/archive/unifi.domain.com/”
Upon inspection of the archive directory, multiple cert.pem and privkey.pem files were found with the names cert1.pem, cert2.pem, cert3.pem etc. Looking at the creation date of the file revealed the symbolic link was referring to an old “cert1.pem” file.
Work around was to stop the unifi-video service and reimport the cert using the latest .pem files in the archive directory.